Just another technology enthusiast

Archive for the ‘Identity & Access Management’ Category


Quick View: New Azure AD AuthN Feature in Visual Studio 2015

This video provides a quick overview of Azure Active Directory from a developer’s standpoint and gives a glimpse of the new identity features in Visual Studio 2015 that make it easy to secure applications with Azure AD.

Click here for the video: http://azure.microsoft.com/en-in/documentation/videos/azure-active-directory-overview

Identity concepts for non technical folks

Note / Disclaimer: This content is from The Open Group blogs titled Understanding the Importance of Identity


In May 2011, the Jericho Forum, a forum of The Open Group, published its Identity, Entitlement & Access (IdEA) commandments, which specified 14 design principles that are essential for identity management solutions to assure globally interoperable trusted identities in cyberspace.

These IdEA commandments are aimed at IT architects and designers of both Identity Management and Access Management systems, but the importance of “identity” extends to everyone – eBusiness managers, eCommerce operations, and individual eConsumers.

The Jericho Forum has created a series of five “Identity Key Concepts” videos to explain the key concepts that we should all understand on the topics of identity, entitlement, and access management in cartoon-style plain language.


Video 1: Identity First Principles
This video, entitled “Identity First Principles,” describes fundamental identity management concepts, including core identity, identity attributes, personas, root identity, trust, attribute aggregation and privacy. These can be complex concepts for non-identity experts. However, these videos were produced in an easy-to-understand manner, regardless of your expertise.


Video 2: Operating with Personas
In the second video explains how creating a digital core identifier from your (real-world) core identity must involve a trusted process that is immutable, enduring and unchangeable.


Video 3: Trust And Privacy
The third video explains how trust and persona interact to provide a trusted privacy-enhanced identity ecosystem.


Video 4: Entities and Entitlement
“Entities and Entitlement,” explores the bigger picture of identity management and how the concepts of a core identifier and an identity ecosystem can be expanded to include all entities that require identity in the digital world.


Video 5: Building a Global Identity Ecosystem
Using the concepts addressed in the previous four videos, this fifth and final video of the Identity Management series presented by the Jericho Forum, “Building a Global Identity Ecosystem,” highlights what needs to happen in order build a viable identity ecosystem.

Download MIM CTP

For all those FIM experts out there who have been waiting to get their hands dirty on the new Microsoft Identity Manager (MIM), the wait is finally over. You can download the CTP from the Microsoft Connect website here.

Microsoft Identity Manager 2015 Preview (CTP) Released

More details here: http://windowsitpro.com/identity-management/microsoft-identity-manager-2015-released-public-preview

Download here: https://connect.microsoft.com/site433

Forefront Identity Manager (FIM) 2010 R2 SP1 Released

FIM 2010 R2 SP1 now supports (among other things) the following so that the customers can now run FIM on the latest and greatest Microsoft platform

  1. Windows Server 2012
  2. SQL Server 2012
  3. Visual Studio 2012
  4. SharePoint Foundation 2013
  5. Exchange 2013
  6. Internet Explorer 10
  7. Windows 8
  8. Outlook 2013

For more details check this out: http://technet.microsoft.com/en-us/library/jj863246(WS.10).aspx

Sliding Window Session for your Relying Party

Here is a quick code that you need to include in your relying party’s global.asax file to setup a sliding window session for your federated / claims aware application.

        void SessionAuthenticationModule_SessionSecurityTokenReceived(object sender, SessionSecurityTokenReceivedEventArgs e)


           DateTime now = DateTime.UtcNow;

           SessionAuthenticationModule sam = sender as SessionAuthenticationModule;

           e.SessionToken = sam.CreateSessionSecurityToken(e.SessionToken.ClaimsPrincipal, e.SessionToken.Context, now, now.AddMinutes(1), e.SessionToken.IsPersistent);

           e.ReissueCookie = true;


The above code sets the sliding window to 1 minute.

Retrieving the original RP context (wctx) at the IdP, after passing through ADFS as the FP / R-STS

In some cases, you may need to retrieve the context of the RP at the IdP end after passing through the FP.

For example, your IdP may want to know the name of the RP for which the token is being sought (although this may not a good design). In such cases it is possible to retrieve the context of the RP if you are using ADFS as the federation provider.

By default, the ADFS server encodes all the original context information about the relying party within a cookie when redirecting the user to the IdP. However, if you go the web.config file of ADFS and change the following context element to false, you will see now that the url when accessing the IdP contains a huge queryString  (about half a page long).

<context hidden=true />

What has happened is, ADFS instead of putting the original RP context into a cookie has stored it on the URL itself, but the original query sting is nested within another queryString, so if you are using a custom STS as your identity provider, you can use the following code to retrieve the original context.

string wctx = Request.QueryString[“wctx”];

string baseUrl = System.Web.HttpUtility.ParseQueryString(wctx).Get(“BaseUrl”);

Uri uri = new Uri(baseUrl.Replace(“\”, “?”));

string wtRealm = System.Web.HttpUtility.ParseQueryString(uri.Query).Get(“wtrealm”);

Automating Home Realm Discovery (HRD)

In most common Identity Federation scenarios, there are multiple external Identity Providers (IdP), but the relying party (RP / claims aware app) depends and trusts only one STS (Security Token Service) to provide the claims.

This STS is known as the Federation Provider (FP) or R-STS (Relying Party STS). So when you access the relying party application, it will redirect you to the R-STS (the only STS it knows) to get authenticated, now since (typically) R-STS / FP is not an Identity Provider (IdP), it will (typically) provide you a list of trusted identity providers so that you can choose the one you wanted to get authenticated with.

But in some cases, especially if you are using the application frequently and you know which IdP you wanted to get authenticated with, you would like to avoid that annoying extra step / screen where you need to choose the IdP and wish the system knew it instead of asking every time.

Well there are multiple ways of achieving the same, below are some of the options:

 1.       The (default) cookie based approach

The default behaviour is that, the first time you select the Identity Provider and get successfully authenticated, a persistent cookie is created that is valid for 30 days. This means you don’t need to worry about selecting the identity provider for the next 30 days, however this can have the following issues:

a.        Every time you clean up / clear the cookies, you will need to set it up again

b.       If you want to change to another Identity Provider, you will need to clear the cookies or for temporary purposes use an “In Private” browser session

This default behaviour can be modified, in ADFS’s web.config located (default) at C:inetpubadfsls

 <persistIdentityProviderInformation enabled=true lifetimeInDays=30 />

You can either modify the lifetime of the cookie or make it a non-persistent cookie in which case, it will ask you for home realm discovery on every new browser session (not what we want)


2.       Using the WHR parameter within the queryString / URL

Another approach is to use the WHR parameter in the URL / queryString when accessing the relying party as shown below:


ADFS by default understands the WHR parameter, however, you need a paste a little code in your global.asax of the relying party for WIF to go the magic. Here is the code that will do the trick:

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(object sender, RedirectingToIdentityProviderEventArgs e)


            string strWhr = HttpContext.Current.Request.QueryString[“whr”];

            if (strWhr != null)


                   e.SignInRequestMessage.HomeRealm = strWhr;




What you are doing here is basically hooking up your code to the event WIF raises just before it calls out / redirects to the FP. In the code snippet above you are checking to see if the URL contains a querystring with a WHR parameter, if so you assign the value of that parameter to the HomeRealm property of the SignInRequestMessage.


3.      Hardcode the IdP’s endpoint within RP’s web.config

I would like mention here that the last two approaches we saw are useful for the end-user or the client browser to customise the behaviour, where each end user might want to choose a different identity provider for the same relying party. However, if you have a scenario where the users of your relying party can be authenticated by a particular identity provider, then you may have to resort to the technique mentioned in this section.

You might ask…, “…well, if the RP can be authenticated by one identity provider only, then why are we even providing a HRD page and choice of multiple Identity Provider?…”. Well you should be conscious of the fact that in a real production environment the Federation Provider may not be dedicated to your relying party alone, maybe it is an Org-wide FP and multiple RPs are using it to federate with various identity providers, but your scenario might demands that the FP redirects the user to a particular IdP only and not provide an option to choose from.

You can configure your relying party to automatically pass through the FP and get redirected to the designated IdP by assigning the IdP endpoint using the HomeRealm attribute of the <wsFederation> node in the <federationConfiguration> of the web.config as shown below:



      <cookieHandler requireSsl=true />

      <wsFederation homeRealm=https://ppp.qqq.com/adfs/ls/





passiveRedirectEnabled=true />




4.      Customise the HRD page.

Finally (for ultimate flexibility) you can modify the HomeRealmDiscovery.aspx file and the associated HomeRealmDiscovery.aspx.cs file and provide your own custom logic.

Or you can leave them intact as is, and provide your own custom HRD page and point to it from the ADFS web.config by modifying the element shown below.

<homeRealmDiscovery page=HomeRealmDiscovery.aspx />


A SignInResponse message may only redirect within the current web application

If you have developed  a claims aware federated application (relying party) using Windows Identity Foundation (WIF), you may have noticed that when you type the URL of your application, you get redirected to the configured STS, get authenticated and all that token dance and when finally everything is working and you the redirect you get back to the relying party application boom!… you get the following error…

ID3206: A SignInResponse message may only redirect within the current web
application: ‘/xxxxx’ is not allowed.

Turns out (after wasting enough time figuring out what happened and searching for answers on the internet if you are a newbie), you missed the trailing slash ‘/’ at the end of the URL to your relying party…

Frustrating isn’t it? There are multiple ways to fix this problem… here is a quick way to solve this…

You can check for the trailing slash ‘/’ and redirect in the Application_BeginRequest method of global.asax as shown below

    private void Application_BeginRequest(object sender, EventArgs e)


        if (String.Compare(Request.Path, Request.ApplicationPath, StringComparison.InvariantCultureIgnoreCase) == 0 && !(Request.Path.EndsWith(“/”)))
Response.Redirect(Request.Path + “/”);


Intro On AppFabric on EndPoint.tv (Steve & Danny)

Here is a nice intro to Windows Server Appfabric by a good friend and colleague Steve and Danny. Cutting through all the hype and misunderstandings especially between AppFabric in the Cloud vs. Windows Server AppFabric. Also on when to position BizTalk versus Windows Server AppFabric.