Author Archives: Aashish Koirala

About Aashish Koirala

I build software for a living. .NET happens to be my primary platform of choice. I also like to do it just for fun and to put stuff out there. I like to think about architecture, building better software and making the process of building software better. And I also like to write about all of this.

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
   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:element minOccurs="0" name="Member1" nillable="true" type="xs:string"/>

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

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

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).

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

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.

Two Types of Domain Events

You can find a good primer on domain events in this post by Udi Dahan. There are some issues with his approach, though that Jimmy Bogard raises and addresses in his post. However, I was left with two questions:

  1. Shouldn’t the domain event be dispatched/handled only when the transaction or the unit-of-work commits? Because whatever changes have been made to the state of the domain isn’t really permanent until that happens.
  2. There may be cases when domain events need to trigger changes to other domain objects in the same bounded context – and all of that needs to be persisted transactionally. In other words, in this scenario – it makes sense to have the event be dispatched just before the transaction commits. However, in this case, whatever ends up handling that event also needs access to the current transaction or unit-of-work that is in play – so that all the changes make it to persistence in one fell swoop of a commit.

That leads me to conclude that there are really two types of domain events that need to be handled differently. The first type as listed above would either be infrastructure-y things like sending out e-mails and such, or sending messages to other bounded contexts or external systems. The second type would be within the same bounded context but maintain certain kinds of relations within the domain that could not be modeled within the same aggregate (simply put, they take the place of database triggers in the DDD metaphor).

At this point, I have no further design level ideas on how they would be modeled. More on that later, hopefully. I do know that the thing raising the event should not need to know what kind of domain event it is going to raise. If I am a Foo and my Bar changes, all I care about is I need to raise a BarChanged event. I do not need to know what kind of domain event BarChanged is. I will let this percolate a bit.

DDD, meet SOA

There is a lot of discussion online around whether DDD and SOA can co-exist, and if so, what that looks like. I am of the opinion that they can co-exist and have arrived at a model that seems to work for me. Consider a complex DDD system with several bounded contexts and contrast it to an SOA system – and I am including the flavor of SOA that I describe in this post.

So, how do the two come together? As I have mentioned before, one problem I have with straight-up SOA is that there is no identifiable “core” of the system where the “meat” is. This “meat” is in fact – the domain logic. Now, add to this the fact that the domain is the only thing that deals directly with the database (technically, it’s the infrastructure layer that handles persistence – but you get the idea – it is the domain constructs that are involved in persistence to/from a data store via repositories).

What if we modeled the entire domain as a service? It does not need to be strictly hosted – think of it as a service that is consumed by other services as a library. The repositories combined with the domain objects themselves can replace the accessor/persistor class of services. This makes sense in terms of volatility as well – since the domain really needs to be the part that is least volatile. You can then think of the application layer and the infrastructure layer as being made up of all the other services – and these would still follow the whole utility / computational service / use case handler hierarchy. You would not allow the domain layer to call utility services though – but that is something you would handle through domain events and the like. The presentation layer is still the presentation layer – and is where the UI lives, or the external hosting interface to your services.

The mode of communication between bounded contexts does not change. You can now think of each bounded context as its own SOA subsystem. Communication within bounded contexts would still happen through queues, messages and subscriptions. The application and infrastructure layer would also have “domain event handler” services that handle domain events – I guess you could argue that is just one type of a use case handler. The communication between bounded contexts, as mentioned earlier, stays the same.