Well, here’s the third part of the article on WAAD that I promised. Using the Graph and integrating this with the web is actually quite easy. You should be able to make use the wrapper of I wrote up in the second article here and build a new web principal which can be used to authenticate and authorise your Windows Azure Active Directory users.
We looked here at building a library which could abstract the use of Microsoft’s AAL library and provide the idea of a generic user with a set of properties and methods that can be used in any application. In order to consume this in a web layer though we need to create a web principal which can be used to pull back all of the details of the user through the graph.
The WAAD currently has several limitations when compared to a normal Active Directory. When you think about it this is obvious as the user only needs certain available claims when used in a web context. The problem we have though is that some systems use AD to store metadata about the user which is not then possible in WAAD. WAAD does not have the ability to have extensible metadata additions for the user; it doesn’t actually need to and the point is not to emulate Active Directory since that exists already!
Therefore, any web principal we build will have to implement a hybrid between a database repository of some type and the basic details from the WAAD.
The other problem is the use of roles. In WAAD terminology and for our purposes a security group is a role which means that we have to abstract this within our custom web principal.
In general we’ll need a couple of things. We’ll need to wire up single sign in through ACS which you can read about here. We’ll also need to create a custom principal from a ClaimsPrincipal which is returned through the ASP.NET runtime. I’ve implemented an interface with the custom principal just so that it is testable.
You can see here that the underlying implementation will ensure that the user has a database profile which will be created lazily. This is a great way to create an onboard users and slowly build up web profiles for them despite their affinity to WAAD. The Graph isn’t fully functional currently and this will be a much faster way to do things. You have already ensure that username or UPN is unique so indexing can occur on that. Something to note is the use of differentiation between IsAdministrator and IsSuperAdministrator where a SuperAdministrator can own the application by virtue of security group membership and the Administrator which is a tenant can be a member of an organisational security group and also the Administrator security group so that the set determines the underlying management role.
Note the implementation of IsInRole on the principal just uses the IsInGroup method on the AD user so we’ve done a transposition in terminology. A good way to evolve this is to use security groups as well for metadata. When managing your own AD and creating multi-tenant applications WAAD can be used in a way which will allow identifiers such as corporation names as being synonymous with security group names to supplement the lack of available metadata at source. It’s a good and simple pattern as well.
When we implement the IIdentity interface for our custom identity we can simply use the claims to return information about the user. It’s worth noting that the claims returned for the user are not wired correctly with the ASP.NET runtime. There’s a couple of approaches to this and to avoid a null value for Identity.Name. The first is to do what you see below and pull out the Upn value (Unique Principal Name) from the claims.
The second is to update the web.config. The default implementation is to look for the name. For a web principal the name or email claim will be used as it assumed to be unique. In this case the email isn’t present from our ACS output claims so we have to supplement this or change the name claim that we look for in the web.config which will automatically update the Identity.Name.
Lastly, we need to consider how we create the principal so we’ll focus on the global.asax and the ASP.NET pipeline and create the custom principal from the incoming claims principal.
In order to use this declaratively simply decorate a Controller method like so.
Hopefully you can see from this series that wiring up ClaimsPrincipal authenticated via WAAD to be used in a web application is as easy as RaspberryPi.