Category Archives: Software Development

Writing a WS-Federation based STS using WIF

Even though SAML and WS-* have started to be looked upon as the old guard of security protocols with the popularity of OAuth 2, they are not without their merits. For one, they are inherently more secure than OAuth (in fact, you need to rely on a separate underlying secure transport for OAuth to be considered secure- and if you are someone who believes SSL is broken, then OAuth is practically insecure). It just so happens that their demerits are very visible to someone trying to implement or integrate them. OAuth, by contrast, is much simpler and easier to implement- and for most purposes, secure enough. If you have settled on WS-Federation as your protocol of choice, Windows Identity Foundation (WIF) is most likely going to be your de-facto choice. While powerful, WIF as a library is not what one would call “easy to use”. If it’s cumbersome when you use it as a relying party, the complexity is ten-fold if you try to build a security token service (STS) based on it.

I decided to take on the challenge and embarked on building a central login system (i.e. passive STS) that I could use for all of my applications. I mostly don’t like to maintain my own user database, so the central login system would then provide a hub for the user to login using any of the various identity providers out there such as Google or Facebook. The main advantage would be that the user would need to login once and be able to use all my applications. The initial plan was to make it protocol agnostic – i.e. something that will look at the incoming request, figure out what kind of request it is, and then delegate to an appropriate protocol handler. This way, the application would be able to support WS-Federation, SAML 2, OAuth 2, what-have-you, as needed. However, I saw what a great job IdentityServer has done in terms of providing a library you can easily build an OAuth based STS with – so that made me not want to pursue the OAuth path at all for this instance. My plan is to someday just build the next version of this as an OAuth STS using IdentityServer3.

With that said, if you look at the source code (available here), you will see that there is a protocol-agnostic pattern with a WS-Federation implementation. The application uses Windows Identity Foundation (WIF) as its core component. It acts as a passive STS (Security Token Service) while dividing the role of IP (Identity Provider) between the target application (or “Relying Party“) and one or more third-party providers such as Google or Facebook. The third-party providers are used for authentication, but the responsibility of storing whatever user information is needed by each application is the responsibility of that application (thus my statement that the identity provider role is divided between the Relying Party and the third-party Identity Providers). The entry point of the WS-Federation communication logic is in the WsFedLoginRequestProcessor class, specifically the ProcessSignIn method.

Each Relying Party is registered with the application through configuration – needs to have three settings populated: the realm URI (a unique identifier for the party – an example being urn:ApplicationName), the reply-to URL (the URL that this application will redirect to once the user is authenticated. This is usually the main entry point URL for the Relying Party application) and the “login service URL”. The Relying Party needs to implement a WCF service with a predefined contract (defined in ILoginService – available in the Commons Library. The service is responsible for providing information about the application as well as any given user to the STS, as well as exposing a way to create new users. The Relying Party application then needs to be configured for WIF and with the STS designated as the token issuer. There are methods available in the Commons Library that facilitate this. Communication between the Relying Party and the STS is encrypted and signed using a shared X.509 certificate.

When you navigate to a protected endpoint in the Relying Party, and are not authenticated, you are redirected to the login page hosted by the STS. This redirection request is generated by WIF and follows standard WS-Federation protocol. The STS then uses the realm information passed in the request to look up information about the party. It gets more information from the Relying Party using the ILoginService WCF endpoint. It uses this to display application-specific information in the login page. From the login page, you can use Google (using it’s OAuth API) or Facebook (using its JavaScript API) to authenticate yourself. The STS then communicates with the Relying Party using the ILoginService WCF endpoint to see if a user matching credentials just provided by Google or Facebook exists. If so, it uses this information to instruct WIF to write an encrypted session token cookie, and redirects back to the Relying Party reply-to URL – where it is now authenticated thanks to the encrypted session token cookie.

If a user is not found, the STS prompts you to enter a display name for the user that is going to be newly created. Once you provide the information, the ILoginService WCF endpoint is again used to create a new user record in the Relying Party application, and the rest of the process is same as above. When you logout from the Relying Party application, WIF sends a logout WS-Federation message to the STS which takes care of processing the logout operation.

Git- Rewriter of History

Undoubtedly one of the biggest advantages that Git provides is using rebasing to maintain a clean commit history. I find that I am using it a lot these days- primarily in three modes:

  • As part of pull (i.e. git pull –rebase)
  • Interactive rebase to: 1) keep my own history clean when I am off working on a branch by myself, and 2) clean up a feature branch’s commit history before merging it into the mainstream
  • Rebase my branch against a more mainstream branch before I merge onto it (i.e. git rebase mainstream-branch)

With interactive rebase, usually what I do is- I will have one initial commit that describes in general the feature I am working on. It will then be followed by a whole bunch of commits that are advancements of or adjustments to that – quick and dirty ones with “WIP” (i.e. work in progress) as the message. If, in the middle of this, I switch to some other significant area, then I will add another commit with a more verbose message, and then again it’s “WIP”, “WIP”, and so on. I will add any thing I need to qualify the “WIP” with if necessary (e.g. if the “WIP” is for a different context than the last few WIPs, or if the WIP does indeed add some more information to the initial commit). In any case, after some time, I will end up with a history that looks a bit like this (in chronological order):

hash0 Last "proper" commit.
hash1 Started implementing feature 1. Blaah blaah.
hash2 WIP
hash3 WIP
hash4 WIP
hash5 Started implementing feature 2. Blaah blaah.
hash6 WIP
hash7 WIP
hash8 WIP (feature 1)
hash9 WIP (feature 1)
hash10 WIP (feature 2)

At this point, I will realize that things are getting a bit unwieldy. So I do an interactive rebase, i.e. git rebase -i hash0, which gives me this:

p hash1 Started implementing feature 1. Blaah blaah.
p hash2 WIP
p hash3 WIP
p hash4 WIP
p hash5 Started implementing feature 2. Blaah blaah.
p hash6 WIP
p hash7 WIP
p hash8 WIP (feature 1)
p hash9 WIP (feature 1)
p hash10 WIP (feature 2)

The first thing I will do is reorder the commits so that they are not interleaving back and forth between what they logically represent (i.e. features 1 and 2 in this case). This, of course, assumes, that there is no overlap in terms of code units touched by features 1 and 2.

p hash1 Started implementing feature 1. Blaah blaah.
p hash2 WIP
p hash3 WIP
p hash4 WIP
p hash8 WIP (feature 1)
p hash9 WIP (feature 1)
p hash5 Started implementing feature 2. Blaah blaah.
p hash6 WIP
p hash7 WIP
p hash10 WIP (feature 2)

Next, I mark the main commits as “r” for reword if I need to improve the commit message, or as “e” for edit if I also need to, for some reason, change the commit date (I will usually do this using git commit –amend –date=now so that the history looks nice and chronological). The “WIP” commits- I mark as “f” for fixup– which is a version of squash that skips the step that lets you combine the commit messages, since “WIP” does not have anything worth combining in terms of the commit message.

e hash1 Started implementing feature 1. Blaah blaah.
f hash2 WIP
f hash3 WIP
f hash4 WIP
f hash8 WIP (feature 1)
f hash9 WIP (feature 1)
e hash5 Started implementing feature 2. Blaah blaah.
f hash6 WIP
f hash7 WIP
f hash10 WIP (feature 2)

When all is said and done and the rebase is complete, I have a nice clean history:

hash0 Last "proper" commit.
hash11 Implemented feature 1.
hash12 Implemented feature 2.

I love Git.

Beware of this WCF Serialization Pitfall

Ideally, one should avoid data contracts with complex graphs- especially with repeated references and definitely ones with circular references. Those can make your payload explode on serialization. With repeated references, you may run into an integrity issue on deserialization. With circular references, the serialization will enter a recursive loop and you will probably run into a stack overflow.

Seeing that in certain situations, this becomes unavoidable, WCF has a way that you can tell it to preserve object references during serialization. You do this by setting IsReference to true on the DataContract attribute that you use to decorate the composite type that is your data contract.

So, for example:

[DataContract(IsReference = true)]
public class MyContract
{
   [DataMember]
   public string Member1 { get; set; }
   ...
   ...
}

This solves the problem- however, since WCF achieves this by augmenting the WSDL- beware of this when you are exposing your service to third parties (especially ones that are not using WCF or perhaps not .NET at all) and interoperability is a concern. Without IsReference set to true, the WSDL snippet for the above would look something like:

<xs:complexType name="MyContract">
  <xs:sequence>
    <xs:element minOccurs="0" name="Member1" nillable="true" type="xs:string"/>
    ...
  </xs:sequence>
</xs:complexType>

With IsReference set to true, this is what it looks like:

<xs:complexType name="MyContract">
  <xs:sequence>
    <xs:element minOccurs="0" name="Member1" nillable="true" type="xs:string"/>
    ...
  </xs:sequence>
  <xs:attribute ref="ser:Id"/>
  <xs:attribute ref="ser:Ref"/>
</xs:complexType>

See those two lines that got added (i.e. “Id” and “Ref”)? That could very well cause some other party’s WSDL parser/proxy generator to choke. You have been warned.

Using CSS Media Queries for Responsive UI Design

Using something like Bootstrap for a responsive UI covers most of the bases. But if you need more control, it’s a good idea to get familiar with Media Queries in CSS. It might come in handy some time, plus that is what Bootstrap uses under the hood as well, and it never hurts to learn how the tools you use work. The Mozilla page on media queries goes into just the right amount of detail and gives you a good outline of everything you can do with it.

To be very brief though, here is how you use a media query in CSS:

@media query { normal-css }

This scopes it so that the CSS within the query (i.e. normal-css above) is applied only when the condition dictated by query is true. So, you could use it to say apply this style when the width or height or in a given range, or if we’re using a given type of device, or color setting, and so on.

The following, for example, sets the background color of the body to red only when the view area width is 300 pixels or more (stupid usage scenario, I know, but you get the point as to how this could be used to make your UI responsive in all sorts of ways):

@media (min-width: 300px) { 
   body {
     background-color: red;
   }
}

A powerful tool to have in your chest when building user interfaces.

Diagnosing MEF Composition Errors

For all its goodness, if something goes wrong, problems with MEF are terribly hard to diagnose. Thankfully, there’s an article out there by Daniel Plaisted at Microsoft that goes into great detail into all the things that can go wrong with MEF and how to get to the bottom of each one. I have it bookmarked, and if you work a lot with MEF, you should too. The one area that I find most useful, though, is figuring out composition-time errors using tracing.

With MEF, if you are using the Import attribute and there are errors during composition – either due to a bad Export, a missing DLL, or even an exception in the constructor, the composition itself will not choke. It will simply not load the Export and therefore anything that depends on it into the container. The problem then manifests itself as a missing Export when you try to use it. By then, it’s too late to know what happened.

An easy diagnosis tool from the article I mentioned above is to drop the following snippet into your application configuration file (App.config, Web.config, what-have-you).

<system.diagnostics>
  <sources>
    <source name="System.ComponentModel.Composition" switchValue="All">
      <listeners>
         <add name="fileListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="composition.log" />
      </listeners>
    </source>
  </sources>
  <trace autoflush="true" indentsize="4" />
</system.diagnostics>

After the composition routine runs, check the file configured above (in this example, “composition.log“) for any errors. You will have to sift through a lot of “everything’s okay” type messages, but errors stand out fairly easily. If something is causing the composition to skip certain parts, it will tell you exactly what and why – so you can fix it and move on rather than scratch your head and wonder what’s wrong. Make sure you disable it after you’re done though – the trace is pretty verbose and if you leave it on, that file will grow extremely large before you know it.

Getting on the Domain Driven Design Bandwagon

Domain driven design has been around for quite a while. I believe the definitive book on it by Eric Evans came out first in 2004. For whatever reason, I had not been exposed to it in places I worked. I had been hearing about it for enough time and from enough smart people to give it a try. I researched it online a bit and went through quite a few articles. Especially, the set of articles on DDD by Jimmy Bogard (Los Techies) was quite helpful. Finally, I ended up buying Evans’ book and reading it cover to cover.

I liked what I saw. The whole idea behind keeping your domain logic encapsulated within your domain objects appealed to me. There were questions, obviously, but I figured it was worth trying out. So that is what I am deep into currently. The idea of entities, value objects, aggregates and aggregate roots makes sense, but at the same time, also raises questions – especially with regards to database performance. I am hoping I will arrive at satisfactory answers.

As things get more complex, other concepts such as bounded contexts and domain events enter the picture. While I get them in theory, my idea for now is to stay away from actually getting hands-on with those until I have a good handle on “vanilla” DDD. Another question I have is how this meshes with SOA – whether the two are complimentary or exclusive. I would hate to have to give up SOA to stick with DDD. In any case, it feels exciting – and I can’t believe it has been around for so many years and I never got into it.

For anyone getting into DDD, I strongly recommend reading Evans’ book. In software timescale, it was written aeons ago (when Java was the state-of-the-art, mind you). But all of it still applies, and if you’re working with something like C#, as I am, things become even easier since you have so much more power with these modern languages.

So, for the moment, let’s say I am on the bandwagon. Hopefully I don’t have to get off.

An Easy Service Proxy Executor for WCF

If you have adopted service oriented architecture (SOA) and are using WCF as the hosting/communication mechanism for your internal services, chances are you are doing one of two things: you publish each service like any old WCF service and your other services which are consumers of said published service consume it through its WSDL; or you create shared libraries that include the contract information that both the service and its consumer reference. Both are somewhat cumbersome but can be managed. If all your services are internal, though, going the WSDL route is somewhat of an unnecessary overhead and is just a bit more unmanageable.

Now, if you decide to go the second route, but still stick to the more obvious interface that WCF provides to instantiate and call proxies (ClientBase and the like), that is a bit of a waste – since those classes were built with generated-code proxies in mind. In that case, the better option really is to have a mechanism to obtain a ServiceEndpoint and use that along with the contract information to create your own ChannelFactory – where you can then call CreateChannel to get your proxy. A lot less code and a lot more manageable.

To this end, for my own purposes, I built a bunch of classes that comprise my WCF service executor module. This is part of the Services namespace in the new Commons Library. Here are what a few of the key classes look like – you should be able to surmise how they can be used. The most common usage example would be:

var response = ServiceCallerFactory
   .Create<IMyContract>()
   .Call(x => x.MyOperation(request));

 

IServiceCaller

public interface IServiceCaller<out TChannel>
{
     void Call(Action<TChannel> action);
     TResult Call<TResult>(Func<TChannel, TResult> action);
}

ServiceCaller

public class ServiceCaller<TChannel> : IServiceCaller<TChannel>
{
      private readonly ServiceEndpoint endpoint;
      private readonly EndpointAddress endpointAddress;

      public ServiceCaller() {}

      public ServiceCaller(ServiceEndpoint endpoint)
       {
             this.endpoint = endpoint;
       }

      public ServiceCaller(EndpointAddress endpointAddress)
      {
             this.endpointAddress = endpointAddress;
      }

      public void Call(Action<TChannel> action)
      {
             var channelFactory = this.endpoint != null
                   ? new ChannelFactory<TChannel>(this.endpoint)
                   : new ChannelFactory<TChannel>();

            if (this.endpointAddress != null) channelFactory.Endpoint.Address = endpointAddress;

            var channel = channelFactory.CreateChannel();
             try
             {
                   action(channel);
             }
             catch
             {
                   channelFactory.Abort();
                   throw;
             }
             finally
             {
                   channelFactory.Close();
             }
       }

      public TResult Call<TResult>(Func<TChannel, TResult> action)
      {
             var channelFactory = this.endpoint != null
                   ? new ChannelFactory<TChannel>(this.endpoint)
                   : new ChannelFactory<TChannel>();

            var channel = channelFactory.CreateChannel();
             try
             {
                   return action(channel);
             }
             catch
             {
                   channelFactory.Abort();
                   throw;
             }
             finally
             {
                   channelFactory.Close();
             }
       }
}

ServiceCallerFactory

public static class ServiceCallerFactory
{
       private static readonly object serviceCallerMapLock = new object();

      private static readonly IDictionary<Type, ServiceCaller> serviceCallerMap = new Dictionary<Type, ServiceCaller>();

      public static Func<Type, ServiceEndpoint> ServiceEndpointAccessor { get; set; }

      public static IServiceCaller<TChannel> Create<TChannel>(EndpointAddress endpointAddress = null)
      {
             ServiceCaller caller;
             if (serviceCallerMap.TryGetValue(typeof (TChannel), out caller))
                   return (IServiceCaller<TChannel>) caller;

            lock (serviceCallerMapLock)
            {
                   if (serviceCallerMap.TryGetValue(typeof (TChannel), out caller))
                         return (IServiceCaller<TChannel>) caller;

                   if (ServiceEndpointAccessor != null)
                   {
                         var serviceEndpoint = ServiceEndpointAccessor(typeof (TChannel));
                         if (endpointAddress != null) serviceEndpoint.Address = endpointAddress;
                         caller = new ServiceCaller<TChannel>(serviceEndpoint);
                   }
                   else
                   {
                         caller = endpointAddress == null
                               ? new ServiceCaller<TChannel>()
                               : new ServiceCaller<TChannel>(endpointAddress); 
                   }

                  serviceCallerMap[typeof (TChannel)] = caller;
            }

            return (IServiceCaller<TChannel>) caller;
      }
}