Sharepoint 2013 : Claims-based authentication, federated identities, and OAuth (part 3) - Building a relying party

2.2 Building a relying party

To test the IP/STS, you can add a new ASP.NET website project to the current solution by clicking File | New Project in Visual Studio 2012, and choosing an ASP.NET Empty Web Application project model. Next, you need to configure identity federation using the Identity and Access Tool. Right-click the web project in Visual Studio 2012 to access the menu, then choose Identity And Access (see Figure 3).

Figure 3. The menu extension to configure the Identity and Access Tool for a web project in Visual Studio 2012.

The Identity and Access Tool prompts you to select whether you want to federate your web app with a local development STS, which is provided out of the box by the Identity and Access Tool; with Windows Azure ACS; or with a business IP/STS like the one in the previous section (see Figure 4).

Figure 4. The UI provided by the Identity and Access Tool for federating a web application in Visual Studio 2012.

For the example, select the Use A Business Identity Provider option and provide the URL of the FederationMetadata.xml file published by the custom IP/STS. Click the OK button to configure your web application according to your choices.

Take a closer look at the web.config file after the Identity and Access Tool modifies it. Two new configuration sections, system.identityModel and system.identityModel.services, were defined targeting the WIF 4.5 infrastructure. The standard ASP.NET authentication method was set to None, because authentication events will be intercepted by an HttpModule class of WIF called WSFederationAuthenticationModule, available in the System.IdentityModel.Services namespace. In addition, a module corresponding to the SessionAuthenticationModule class was registered. This last module avoids repeating authentication against the IP/STS for each request, storing the session security token in a cookie stored securely and locally for the current web application. An excerpt of the web.config file related to the WIF 4.5 sections shows the configuration of the system.identityModel and system.identityModel.services sections of the XML configuration file.

<system.identityModel>
  <identityConfiguration>
    <audienceUris>
      <add value="http://localhost:14966/" />
    </audienceUris>
    <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, 
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <trustedIssuers>
        <add thumbprint="A60699901F8483C72034EA165074392D8E4FC08C" 
        name="Issue.aspx" />
      </trustedIssuers>
    </issuerNameRegistry>
  </identityConfiguration>
</system.identityModel>
<system.identityModel.services>
  <federationConfiguration>
    <cookieHandler requireSsl="false" />
    <wsFederation passiveRedirectEnabled="true"
        issuer="https://localhost:44334/Issue.aspx" 
        realm="http://localhost:14966/"
        requireHttps="false" />
  </federationConfiguration>
</system.identityModel.services>

Highlighted in bold, the key points of this listing are:

Now, if you start browsing the site, you will be prompted for logging in to the IP/STS before being able to access the relying-party site. To see the real result, however, you need to add a Default.aspx page to the relying-party web project and define a bunch of code for rendering the claims. A code excerpt of the Page_Load event of the Default.aspx page of the relying-party web project provides a code excerpt of the Page_Load event of the Default.aspx page.

protected void Page_Load(object sender, EventArgs e) {
    if (this.User != null && this.User.Identity != null) {
        ClaimsIdentity ci = this.User.Identity as ClaimsIdentity;
        if (ci != null) {
            var claims = (from c in ci.Claims
                            select new { c.Type, c.Value }).ToArray();
            this.gridClaims.DataSource = claims;
            this.gridClaims.DataBind();
        }
    }
}

As you can see, the code simply defines a LINQ query against the collection of claims of the current ClaimsIdentity instance, corresponding to the currently authenticated user. The result of the LINQ query is bound to a GridView control defined in the ASPX markup of the Default.aspx page. Figure 5 shows the result after authenticating with a sample user (assuming you have properly configured users’ profiles).

Figure 5. The output of the Default.aspx page after authentication with a sample user.