STSeverin's blog

Just a simple integration test for AAL and the JWT Handler

2013-03-26T13:00:00Z

Here I’ll do my best to create a simple integration test involving the Windows Azure Authentication Library Beta on the client side and the JWT Handler (or if you prefer the full name, JSON Web Token Handler For the Microsoft .Net Framework 4.5, Developer Preview) on the service side. While I could’ve mocked the communication with Windows Azure Active Directory Preview , I decided not to do it in this post as it gives a bit of meat to the story. Rather than explaining all the bits and pieces, which is being done extensively as I write, for example here on Windows Azure Active Directory, here on JWT Handler and here about Windows Azure Authentication Library, I’ll go straight to work with a step-by-step tutorial. Bare in mind that this is neither a post on how to write effective integration tests, nor is it about TDD. Also be aware that it is based on preview libraries.

The idea here is that the integration test client mimics some sort of a server-side client application that consumes a REST API, both registered as Service Principals within the same AAD tenant. Let’s say for example that the client application is a long-running server-side process that are polling an API for changes, as described in this example (which inspired me to write this post). The API only allows access to requests that can present an OAuth2 bearer token that can be properly validated. So before the client can successfully make an API call it needs to aquire an access token from ACS, which it does by utilizing the AAL. The client then adds the aquired token to the HTTP request’s authorization header before making the call. The functionality under test here is the token validation part, or rather how we enable the token validation taking place.

So here it goes:

Create a Windows Azure AD tenant: here Get the Powershell CmdLets that we’ll need:
64-bit: http://go.microsoft.com/fwlink/p/?linkid=236297
32-bit: http://go.microsoft.com/fwlink/p/?linkid=236298

Start Visual Studio 2012 and create a new unit test project, targeting .NET Framework 4.5. In this tutorial I chose to use MS-Test.
You may call the solution and project whatever you like.

Add Nuget packages for
Microsoft.IdentityModel.Tokens.JWT
Microsoft.WindowsAzure.ActiveDirectory.Authentication

Add a reference to
System.IdentityModel
System.Net.Http
System.Web.Http
System.Windows.Forms (needed because we’ll make use of the AssertionCredential class (part of Windows.Azure.ActiveDirectory.Authentication)

Add an app.config file to the project and replace with the following content. Notice all the placeholder values that we will fill on the way:

 <?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="Audiences" value="service/localhost@PLACEHOLDER_FOR_TENANT_ID"/>
    <add key="Issuers" value="00000001-0000-0000-c000-000000000000@PLACEHOLDER_FOR_TENANT_ID,https://sts.windows.net/PLACEHOLDER_FOR_TENANT_ID"/>
    <add key="ClientSymmetricKey" value="PLACEHOLDER_FOR_CLIENT_SYMMETRIC_KEY"/>
    <add key="ServiceSymmetricKey" value="PLACEHOLDER_FOR_SERVICE_SYMMETRIC_KEY"/>
    <add key="Tenant" value="https://accounts.accesscontrol.windows.net/PLACEHOLDER_FOR_TENANT_ID"/>
    <add key="ServiceRealm" value="service/localhost@PLACEHOLDER_FOR_TENANT_ID"/>
    <add key="Resource" value="IntegrationTestClient/localhost@PLACEHOLDER_FOR_TENANT_ID"/>
  </appSettings>
</configuration>
 

Save and compile the project!

Switch over to Powershell or Powershell ISE, and run

 Import-Module msonline -Force 
Import-Module msonlineextended -Force
#When prompted for credentials, login with the same account you used when creating the tenant
Connect-MsolService
 

If you successfully signed in with the tenant administrator credentials, you will have full access to your tenant from within the Powershell host.

Provision the REST service; i.e. register it as a Service Principal within your tenant.

    
New-MsolServicePrincipal -ServicePrincipalNames @("service/localhost") DisplayName "Service" -Usage Sign

In the App.config file, replace PLACEHOLDER_FOR_SERVICE_SYMMETRIC_KEY with the symmetric key that was returned.

Provision the integration test client

New-MsolServicePrincipal -ServicePrincipalNames @("IntegrationTestClient/localhost") -DisplayName "Integration test client" Usage Verify

In the app.config file, replace PLACEHOLDER_FOR_CLIENT_SYMMETRIC_KEY with the symmetric key that was returned.

That’s it, we’re done with Powershell, so you may close it down.

It is time to look up your Tenant Id. All you need to accomplish this is to point your browser to the URL of your Tenant’s federation metadata; https://accounts.accesscontrol.windows.net/placeholder_for_your_tenant/FederationMetadata/2007-06/FederationMetadata.xml
where placeholder_for_your_tenant usually goes something like your_tenant_name.onmicrosoft.com. Now from the page returned, copy the GUID-value inside the entityID. then jump over to the App.config file in Visual Studio and replace all six occurences of PLACEHOLDER_FOR_TENANT_ID with the copied value.

From now on we turn all our attention to the project in Visual Studio.

Without further ado, here are the raw code as it is. No effort has been made on refactoring whatsoever as I leave that to the reader.

The integration test class

 using System;
using System.Configuration;
using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Web.Http;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.WindowsAzure.ActiveDirectory.Authentication;
 
namespace IntegrationTests
{
    [TestClass]
    public class When_calling_the_service
    {
        private HttpConfiguration config;
        private HttpServer server;
        private HttpClient client;
        private AssertionCredential assertionCredential;
        private AuthenticationContext authContext;
 
        [TestInitialize]
        public void With_a_valid_token()
        {
            config = new HttpConfiguration();
            config.Routes.MapHttpRoute(name: "Default",
                                       routeTemplate: "api/{controller}/{action}/{id}",
                                       defaults: new { id = RouteParameter.Optional });
 
            config.MessageHandlers.Add(new JWTMessageHandler());
            config.MessageHandlers.Add(new JustReturnsOkMessageHandler());
            server = new HttpServer(config);
            client = new HttpClient(server);
            var token = AcquireToken();
            client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token.Assertion);
        }
 
        [TestMethod]
        public void It_should_return_http_status_code_200()
        {
            //Always use SSL with bearer tokens!
            var task = client.GetAsync("https://doesntmatterwhatgoesherereally");
            task.Wait();
            var response = task.Result;
            Assert.AreEqual(response.StatusCode, HttpStatusCode.OK);
        }
 
        [TestCleanup]
        public void CleanUp()
        {
            server.Dispose();
            client.Dispose();
        }
 
        private AssertionCredential AcquireToken()
        {
            string serviceRealm = ConfigurationManager.AppSettings["ServiceRealm"];
            string resource = ConfigurationManager.AppSettings["Resource"];
            string symmetricKey = ConfigurationManager.AppSettings["ClientSymmetricKey"];
 
            var credential = new SymmetricKeyCredential(resource, Convert.FromBase64String(symmetricKey));
            authContext = new AuthenticationContext(ConfigurationManager.AppSettings["Tenant"]);
            assertionCredential = authContext.AcquireToken(serviceRealm, credential);
            return assertionCredential;
        }
    }
}
 

JWTMessageHandler, added to the HttpConfiguration MessageHandler collection above

 using System.Collections.Generic;
using System.Configuration;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
 
namespace IntegrationTests
{
    public class JWTMessageHandler : DelegatingHandler
    {
        public JWTMessageHandler()
        {
        }
 
        public JWTMessageHandler(HttpMessageHandler innerHandler)
            : base(innerHandler)
        {
        }
 
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
        {
            var jwtHandler = new CustomJWTHandler();
            string token;
            if (!request.TryGetToken(out token))
            {
                HttpStatusCode statusCode = HttpStatusCode.Unauthorized;
                return Task<HttpResponseMessage>.Factory.StartNew(() => new HttpResponseMessage(statusCode));
            }
            try
            {
                System.Threading.Thread.CurrentPrincipal = jwtHandler.ValidateToken(token);
            }
            catch (System.Exception)
            {
                HttpStatusCode statusCode = HttpStatusCode.BadRequest;
                var httpResponseMessage = new HttpResponseMessage(statusCode);
                httpResponseMessage.ReasonPhrase = "Something went wrong validating the token!";
                return Task<HttpResponseMessage>.Factory.StartNew(() => httpResponseMessage);
            }
            return base.SendAsync(request, cancellationToken);
        }
    }
}
 

As a precaution I would also add a message handler for making sure the call is made over HTTPS, as we are dealing with bearer tokens here.

HttpRequestMethodExtensions, just for the convenience when trying to extract the token above.

 using System.Collections.Generic;
using System.Net.Http;
using System.Linq;
 
namespace IntegrationTests
{
    public static class HttpRequestMessageExtensions
    {
        public static bool TryGetToken(this HttpRequestMessage @this, out string token)
        {
            token = null;
            IEnumerable<string> authorizationHeaders;
            if (!@this.Headers.TryGetValues("Authorization", out authorizationHeaders) || authorizationHeaders.Count() > 1)
            {
                return false;
            }
            string bearer = authorizationHeaders.ElementAt(0);
            token = bearer.ToLower().StartsWith("bearer ") ? bearer.Substring(7) : bearer;
            return true;
        }
    }
}
 

CustomJWTHandler, wraps the call to the JWTSecurityTokenHandler, that valildates the token on line 27.

 using System.Collections.Generic;
using System.Configuration;
using Microsoft.IdentityModel.Tokens.JWT;
using System.ServiceModel.Security.Tokens;
 
namespace IntegrationTests
{
    public class CustomJWTHandler 
    {
        public System.Security.Claims.ClaimsPrincipal ValidateToken(string jwt)
        {
            var issuers = new List<string>();
            var audiences = new List<string>();
            issuers.AddRange(ConfigurationManager.AppSettings["Issuers"].Split(new[] { ',' }));
            audiences.AddRange(ConfigurationManager.AppSettings["Audiences"].Split(new[] { ',' }));
 
            var tokenValidationParameters = new TokenValidationParameters
                {
                    AllowedAudiences = audiences,
                    ValidIssuers = issuers,
                    SigningToken = new BinarySecretSecurityToken(System.Convert.FromBase64String(ConfigurationManager.AppSettings["ServiceSymmetricKey"])),
                    ValidateIssuer = true,
                    ValidateNotBefore = true,
                    ValidateExpiration = true,
                    ValidateSignature = true
                };
            return new JWTSecurityTokenHandler().ValidateToken(jwt, tokenValidationParameters);
        }
    }
}
 

JustReturnsOkMessageHandler below is just a dummy message handler that returns OK. As we aren’t actually hosting a real Web Api REST service in this test scenario, we would have gotten a 404 NotFound in response whenever the CustomJwtSecurityTokenHandler class succeeds to validate the JWT token. So we add this to the MessageHandler collection as well.

 using System.Net;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;
 
namespace IntegrationTests
{
    public class JustReturnsOkMessageHandler : DelegatingHandler
    {
        public JustReturnsOkMessageHandler()
        {
        }
 
        public JustReturnsOkMessageHandler(HttpMessageHandler innerHandler)
            : base(innerHandler)
        {
        }
 
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,
                                                               CancellationToken cancellationToken)
        {
            return base.SendAsync(request, cancellationToken).ContinueWith<HttpResponseMessage>((responseTask) =>
                {
                    HttpResponseMessage response = responseTask.Result;
                    response.StatusCode = HttpStatusCode.OK;
                    return response;
                });
        }
    }
}
 

Now when all the code is in place it’s time to compile and run the integration test. All you need is an Internet connection!

Get started with Windows Azure AD Developer Preview today!

2013-02-18T09:46:00Z

Here comes my own favorite (nonexhaustive) list of links and resources which helped me getting my head around Windows Azure Active Directory Developer Preview.

Sign up for a Windows Azure AD Dev Preview Tenant. You'll definitely need this to get yourself started!
http://g.microsoftonline.com/0AX00sv/5

Vittorio Bertocci's MSDN blog. In-depth blog posts, tutorials, announcements, and much more.
All delivered with a personal and unmistakable touch. What Vittorio doesn't know on these subjects is not worth mentioning!
http://blogs.msdn.com/b/vbertocci

The Windows Azure Team Blog. Great Place for interesting blogs, videos, announcements, and more!
http://blogs.msdn.com/b/windowsazure/

Windows Azure AD Graph. All about what you can do with this new cool REST API!
http://msdn.microsoft.com/en-us/library/hh974476.aspx

Windows Azure Authentication Library. Library for client application developers
for authenticating users and aquiring access tokens etc. Downloadable as a Nuget package!
http://msdn.microsoft.com/en-us/library/jj573266

Microsoft Token Validation Extension for Microsoft .Net Framework 4.5. Takes care of the JWT handling.
Easy to use both with and without WIF!
https://nuget.org/packages/System.IdentityModel.Tokens.ValidatingIssuerNameRegistry/4.5.0

SSO how-to guide.
https://www.windowsazure.com/en-us/develop/net/how-to-guides/web-sso/

Integrate! App developer Resources.
https://activedirectory.windowsazure.com/Develop/

Integrating Multi-Tenant Cloud Applications!
Tutorial & sample application.
http://www.windowsazure.com/en-us/develop/net/tutorials/multitenant-apps-for-active-directory/

Developer Code Samples. Just enter windows + azure + active + directory and hit the Search button!
http://code.msdn.microsoft.com/

Fabrikam Expense Tracking Application. An online demo app with links to code on GitHub.
https://aadexpensedemo.cloudapp.net/

Windows Azure AD community forum. Get social with this!
http://social.msdn.microsoft.com/Forums/en-us/WindowsAzureAD/threads

Exploring AD FS on Windows Server 2012, Part 3

2013-01-15T11:41:00Z

In part two, we downloaded a sample ASP.NET MVC 4 application to be used as an internal RP and established a trust relationship with the federation server which in this lab plays the role of an IdP STS. In this post we will make the final changes to the AD FS configuration and the RP so that it will retrieve the claims that it relies on, when authenticated users request the application.

Let's continue from where we left off in part two.

Step 1: Run the application from within the IDE or point a IE browser to https://rp.contoso.com/mvcapplication/. The Admin page requires the user to be authenticated.

1.1 On the first page click on the Admin link and then the Login button.
1.2 You should now be prompted to log on with a domain user. (Create a domain user account in the AD, if you haven't done so already. Don't forget to set Display name, Department, and Email address for the user).
1.3 The browser should display an error stating that fs.contoso.com is unreachable.
This is expected behavior as we haven't yet set up the relying party trust on the IdP STS side. Verify this issue by opening up the event viewer on ContosoServer and look for an error under Application and Services log --> AD FS --> Admin, saying something like "The requested relying party trust 'https://rp.contoso.com/mvcapplication/' is unspecified or unsupported".

Step 2: Create a Relying Party Trust in AD FS: Over at ContosoServer, there are two ways to accomplish this. Either we do it manually with the Add Relying Party Trust wizard in the AD FS Management UI or by using the Powershell cmdlet Add-ADFSRelyingPartyTrust, as I am showing here:

001	Add-ADFSRelyingPartyTrust -Name rp.contoso.com -MetadataUrl https://rp.contoso.com/mvcapplication/federationmetadata/2007-06/federationmetadata.xml MonitoringEnabled $true -AutoUpdateEnabled $true

If you get an error saying: "The underlying Connection was closed: Could not establish trust relationship for the SSL/TLS secure channel." you need to install the SSL cert that we configured on ContosoClient into the Trusted Root Certification Authorities store on ContosoServer.
If it still fails, check that Static Content is enabled on ContosoClient: Add Remove Programs --> Turn Windows Features on or off --> Internet Information Services --> World Wide Web Services --> Common HTTP Features --> Static Content

Another way of generating the Relying Party Trust is to use the -MetadataFile parameter and point to the FederationMetadata.xml file on disk on ContosoClient, such as \\ContosoClient\[Shared_folder]\MvcApplication\FederationMetadata\2007-06\FederationMetadata.xml. The problem with this approach is that the Relying Party Trust can't be automatically updated by monitoring any changes in the RP's federation metadata.

If you try to log on again, it still won't work. In the event log on ContosoServer you would see an access denied exception. We explicitly need to permit users to access the RP.

Step 3: Create a Claims rule set (issuance authorization rule) and assign it to the relying party: The same goes with this one. You can either do this manually or use AD FS cmdlets. In this case New-ADFSClaimRuleSet and Set-ADFSRelyingPartyTrust.

001
002

$claimRuleSet = New-ADFSClaimRuleSet -ClaimRule ' => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");'
Set-ADFSRelyingPartyTrust -TargetName rp.contoso.com -IssuanceAuthorizationRules $claimRuleSet.ClaimRulesString

By applying the above rule to the Relying Party Trust we permit all users to access our RP application.

The expected behavior when trying to log on now is that the authentication process will succeed, but the security token will not contain the claims that the RP relies on.

Step 4: Transform the LDAP attributes that the relying party requires from Active Directory into claims. We need to transform the user account attributes that we retrieve from the attribute store Active Directory. Run these two cmdlets in Powershell ISE 3.0 on ContosoServer to add a new claims rule set (issuance transform rule) relying party trust configuration.

001
002

$claimRuleSet = New-ADFSClaimRuleSet -ClaimRule 'c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = ";mail,displayName,department;{0}", param = c.Value);'
Set-ADFSRelyingPartyTrust -TargetName rp.contoso.com -IssuanceTransformRules $claimRuleSet.ClaimRulesString

Step 5: Update the RP application on ContosoClient: Modify the AdminController.cs, AccountModel.cs and the Index.cshtml (under Views-->Admin) so that the retrieved claims are displayed. One way of authorizing access to protected resources within the RP is to derive from ClaimsAuthorizationManager and override the CheckAccess method where we would and write our access control rules, not shown here. This customized class can then be added to the processing pipeline before the requests ever reach the RP internal logic, either declaratively or programmatically as described on the ClaimsAuthorizationManager page.

Ok, now finally when we run the application we should be able to reach the Admin page!

This concludes this series on how to set up an internal claims-based solution lab with ADFS on Windows Server 2012 with a claims-aware ASP.NET MVC 4.0 application as the RP. The purpose of these blog posts is just to illustrate one specific lab(!) scenario and we merely scratched the surface of the claims-based identity problem domain.

Exploring AD FS on Windows Server 2012, part 2

2013-01-14T15:14:00Z

In part 1 the focus was on the initial setup of an AD FS lab/test Environment on Windows Server 2012, using Powershell 3.0 scripts. In this post, part 2, we'll continue by introducing an application that will rely on claims being issued by this federation server. The federation server is going to play the role of an IdP STS within the Contoso domain, so that we can enable internal Web SSO. The final claims-based solution will be tied together in part 3 in this series.

For the purpose of illustration, we need to connect an RP with the STS. When I say “connect”, in this particular example, I mean to have the IWA authentication process externalized from the RP to the IdP STS. Under the hood, this will be done by utilizing WIF, now a first-class citizen in .NET framework 4.5, and which abstracts away the WS-Federation specification.

Just to make it a bit more challenging, the RP, which in this case will be a simple ASP.NET MVC 4 web application, will be hosted in IIS 8 on another VM within the same domain. The VM is also going to be a Windows 8 dev box.
I used Client Hyper-V on my physical machine with Windows 8 Pro to bring the virtualization part together. There are plenty of tutorials on this subject out there. These blog posts by Jeff Hicks helped me along the way.
The goal is also to make use of Powershell 3.0 as much as possible.

We still have plenty of things to walk through until we have a working claims-based solution, so let's get started. But just to summarize what we have so for:
- A VM with a fresh install of Windows Server 2012, and with the machine, named ContosoServer, configured as a DC for the domain contoso.com.
- An AD FS farm currently with only one federation server, fs.contoso.com
- A service account, SVC-ADFS, which the AD FS windows service runs under.
- The AD FS configuration stored locally in two SQL Server 2012 databases.
- Three self-signed certificates; one for service communications, another for token-decryption and the third for token-signing.

Note: As already mentioned in the first part, this slimlined setup might be convenient for a small lab or PoC, but is not by any means to be concidered best practice for production scenarios.

Prerequisities for the new VM machine which will host the RP application:
Windows 8 pro installed
Computer renamed to ContosoClient
Added as a computer in the domain contoso.com
IIS 8
Powershell 3.0 ISE
Visual Studio 2012
Identity and Access Tool

Step 1: Create DNS recourse records, host (A), for fs.contoso.com and rp.contoso.com: In order to translate the domain and host names to IP addresses (forward resolution), we need to create A records in the DNS. Run the following powershell cmdlets on the ContosoServer and verify that they where indeed created.

001
002
003
004

Add-DnsServerResourceRecordA -IPv4Address [The IP address to ContosoServer] -Name "fs" -ZoneName contoso.com
Add-DnsServerResourceRecordA -IPv4Address [The IP address to ContosoClient] -Name "rp" -ZoneName contoso.com
#Verify
Get-DnsServerResourceRecord -ZoneName contoso.com | Where-Object {$_.RecordType -eq "A"}

Step 2: Create self-signed SSL certificate for rp.contoso.com. Run this on ContosoClient:

001	New-SelfSignedCertificate -DnsName rp.contoso.com -CertStoreLocation Cert:\LocalMachine\My

Make note of the thumbprint!

Step 3: Assign the SSL certificate to Default Web Site: Run this in Powershell 3.0 ISE on ContosoClient:

001
002
003
004
005

#Run this if https for the default web site has not been enabled already
New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https

cd iis:
get-item cert:\LocalMachine\MY\[the thumbprint from above] | new-item 0.0.0.0!443

Step 4: Download and modify the ASP.NET MVC 4 sample:

Let's imagine a web application that relies on the following three claims being issued by the STS. The STS will gather the claims from its attribute store Active Directory.
- The user's name, for greeting the user (corresponding LDAP attribute: [Display Name])
- A role, used for access control decisions (for simplicity this will mapped to the LDAP attribute [Department]
- An email address [-->LDAP: EmailAddresses] for personalization of the site and sending out newsletters by mail

4.1 To save some time and effort, let's download the ClaimsAwareMvcApplication from the WIF Code Sample Index. Be sure to read through the description about the sample.
4.2 Open up Visual Studio 2012 with administrator rights and open the solution from within the IDE.
4.3 Open up the Project properties window and change to the "Web" tab.
4.4 Select "Use local IIS Web server" and unselect "Use IIS Express"
4.5 Change the "Project Url" to https://localhost/mvcapplication and click Create Virtual Directory.
4.6 Now select the "Use Custom Web Server" and enter https://rp.contoso.com/mvcapplication into the textbox. This way we don't get a warning in IE when we run the application from within the IDE as the SSL certificate's common name will be the same (rp.contoso.com).
4.7 Save these settings and close the properties window.

Now let's pause here a bit and consider the fact that we are using self-signed SSL certificates in this lab. What we need to do in order to successfully establish the trust between the RP and the STS, is to install the SSL cert that we configured on ContosoServer into the Trusted Root Certification Authorities store on ContosoClient. See Export a server certificate and Import a server certificate for examples on how to do this.

Step 5: Establish the trust relationship (on the RP side)

5.1 Write-click on the project node in the Solution Explorer window and select "Identity and Access...". If you can't find it, install the Identity and Access Tool, then retry.
5.2 Select "Use a business identity provider (e.g. ADFS2)"
5.3 Enter the path to the STS: https://fs.contoso.com/federationmetadata/2007-06/federationmetadata.xml
5.4 Enter the realm for the RP: https://rp.contoso.com/mvcapplication/
5.5 Select the Configuration tab. Enter https://rp.contoso.com/mvcapplication/ into the realm and audience text boxes, and select the "Generate a controller". Press Ok to save and Close.
5.6 If you see a popup window that is displayed saying "Conflicting code...", select the "Use the existing authentication code" alternative and save by clicking Ok. Ignore the warning.

Also I needed to do the following changes, some of them probably because we started out from an already configured claims-aware application:

5.9 Open Web.Config and verify that only https://rp.contoso.com/mvcapplication/ is present under the AudienceUris tag, also check that trustedIssuers only have one trusted issuer: http://fs.contoso.com/adfs/services/trust. Save and Close.
5.10 Update the FederationMetadata.xml file. Select "Show all files" in the Solution Explorer window, open the FederationMetadata.xml file (under FederationMetadata/2007-06) and remove any EndpointReference that doesn't have the address https://rp.contoso.com/mvcapplication/.
5.11 Save and close the file. Rebuild solution.

Great, you made it this far! In part 3, we'll tie the whole claims-based solution together and make this lab scenario work by performing the necessary changes to the AD FS configuration and the RP.

Exploring AD FS on Windows Server 2012, part 1

2012-12-29T21:09:00Z

As we apparently are in the age of DevOps, where automation of repetitive administrative tasks seem to be in the vogue, I would like to join in with a series of posts about how to streamline the deployment and administration of AD FS on Windows Server 2012.

My twist to the story is that I would like to deploy an AD FS farm in a test/lab environment with the AD FS configuration stored in a SQL Server database. Initially the one and only AD FS instance will serve as an IdP STS to enable internal Web SSO, and so only be used for authentication of internal users accessing internal applications (see part two).

I will make use of Powershell 3.0 to write scripts that I might be able to reuse in other environments later.

Luckily for me, I already have a fresh install of Windows Server 2012 on a VM and the machine has been promoted to be the domain controller on a fictional domain called Contoso.com. On top of that I have installed an instance of SQL Server 2012.

In this post the focus will be on setting the scene for later adventures with AD FS. So be prepared for some initial AD FS deployment stuff, presented in a step-by-step manner.

First a disclaimer: This lab worked on my machine (VM) and is here for conceptual illustration only. It is not intended to be used in a production environment. Also, it might just not work on your machine! For the full disclaimer, see my blog's About page.

Step 1: Log on to the server with appropriate administration rights.
Step 2: Start the Powershell ISE 3.0 tool, run as Administrator .
Step 3: Adjust the execution policy for Powershell 3.0, if needed.
Step 4: Create some order in the AD: This script creates two OUs right under Contoso [Adfs Administration -->Service Accounts].

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016

$domain = "dc=contoso,dc=com";
$ouAdmin = "ou=Adfs Administration";
$ouServiceAccounts = "ou=Service Accounts";

$ldapConnection = [ADSI] "LDAP://$domain";

$newAdminOu = $ldapConnection.Create("OrganizationalUnit", $ouAdmin);
$newAdminOu.SetInfo();

Set-ADOrganizationalUnit "$ouAdmin,$domain" -ProtectedFromAccidentalDeletion $True;

$ouAdminPath = [ADSI]($newAdminOu.path)
$newAccountOu = $ouAdminPath.Create("OrganizationalUnit", $ouServiceAccounts);
$newAccountOu.SetInfo();

Set-ADOrganizationalUnit "$ouServiceAccounts,$ouAdmin,$domain" -ProtectedFromAccidentalDeletion $True;

Step 5: Create the service account for the AD FS farm. When running this script, it will ask you to come up with a password for the service account called SVC-ADFS. Don't worry about the account's rights for now. It will automatically be assigned when installing the ADFS farm.

001
002
003
004
005
006

$dnsRoot = (Get-ADDomain).dnsroot
$pwd = read-host "Enter strong password" -AsSecureString
$upn = "SVC-ADFS" + "@" + $dnsRoot
New-ADUser –Name "SVC-ADFS" –SamAccountName SVC-ADFS –DisplayName SVC-ADFS -Description "Service account for ADFS farm" -userprincipalname $upn `
-Path "OU=Service Accounts,OU=ADFS Administration,DC=contoso,DC=com" –Enabled $true –ChangePasswordAtLogon $False -PasswordNeverExpires $true `
-AccountPassword $pwd

Step 6: Configure the Service Principal Name, SPN, for AD FS service account. The following one-liner does just this, after verifying no duplicates already exist.

001	setspn -S host/contososerver.contoso.com contoso\svc-adfs

Step 7: Ok so now, let's add AD FS, which now is a role in Windows Server 2012.

001	Install-WindowsFeature AD-Federation-Services

That's all there is to that. It will automatically add the web server role with IIS 8, for you.

Step 8: Create a self-signed SSL cert. Among the improved set of PowerShell commandlets that are being shipped with Windows Server 2012 we find one called New-SelfSignedCertificate. Its purpose is to create self-signed certificates for testing purposes. Note that Life is made simplier now that we are able to set the common name right. Let's make use of it.

001	New-SelfSignedCertificate -DnsName fs.contoso.com -CertStoreLocation Cert:\LocalMachine\My

Make note of the thumbprint that was written out to the host, because we will need it in the upcoming steps.

Step 9: Associate the self-signed cert with port 443 for Default Web Site.

001
002
003
004
005

#Run this if https for the default web site has not been enabled already
New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https

#Associate the cert with the SSL port 443 of the default web site
get-item cert:\LocalMachine\MY\[The cert thumbprint from previous step] | new-item 0.0.0.0!443

Step 10: Finally, we are ready to create the farm and its first federation server node. When asked credentials, supply the credentials for CONTOSO\SVC-ADFS.

001
002
003
004
005

$serviceAccountCredentials = Get-Credential
Install-AdfsFarm -CertificateThumbprint [The certificate thumbnail from the previous step] `
-FederationServiceName fs.contoso.com `
-ServiceAccountCredential $serviceAccountCredentials `
-SQLConnectionString "Data Source=.;Integrated Security=True"

You should now be able to see

Two newly created databases in SQL Server: AdfsArtifactStore and AdfsConfiguration
The service account CONTOSO\SVC-ADFS has been assigned approriate SQL Server rights
A new web app under default web site: adfs/ls
A new Windows service: AD FS Windows Service which runs under the account CONTOSO\SVC-ADFS.

That's it for this time folks. I'll be back with more posts on AD FS on Windows Server 2012. Until then: Happy New Year!

--> Part 2