Converting Bootstrap Tokens to SAML Tokens

there comes a point where using an eavesdropping application to catch packets as they fly between Secure Token Services and Relying Parties becomes tiresome.  For me it came when I decided to give up on creating a man-in-the-middle between SSL sessions between ADFS and applications.  Mainly because ADFS doesn’t like that.  At all.

Needless to say I wanted to see the tokens.  Luckily, Windows Identity Foundation has the solution by way of the Bootstrap token.  To understand what it is, consider how this whole process works.  Once you’ve authenticated, the STS will POST a chunk of XML (the SAML Token) back to the RP.  WIF will interpret it as necessary and do it’s magic generating a new principal with the payload.  However, in some instances you need to keep this token intact.  This would be the case if you were creating a web service and needed to forward the token.  What WIF does is generate a bootstrap token from the SAML token, in the event you needed to forward it off to somewhere.

Before taking a look at it, let's add in some useful using statements:

using System;
using System.IdentityModel.Tokens;
using System.Text;
using System.Threading;
using System.Xml;
using Microsoft.IdentityModel.Claims;
using Microsoft.IdentityModel.Tokens;
using Microsoft.IdentityModel.Tokens.Saml11;

The bootstrap token is attached to IClaimsPrincipal identity:

SecurityToken bootstrapToken = ((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0].BootstrapToken;

However if you do this out of the box, BootstrapToken will be null.  By default, WIF will not save the token.  We need to explicitly enable this in the web.config file.  Add this line under <microsoft.IdentityModel><service><securityTokenHandlers>:

<securityTokenHandlerConfiguration saveBootstrapTokens="true" />

Once you’ve done that, WIF will load the token.

The properties are fairly straightforward, but you can’t just get a blob from it:

image

Luckily we have some code to convert from the bootstrap token to a chunk of XML:

SecurityToken bootstrapToken = ((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0].BootstrapToken;

StringBuilder sb = new StringBuilder();

using (var writer = XmlWriter.Create(sb))
{
     new Saml11SecurityTokenHandler(new SamlSecurityTokenRequirement()).WriteToken(writer, bootstrapToken);
}

string theXml = sb.ToString();

We get a proper XML document:

image

That’s all there is to it.

Build your own Directory Federation Service

This is more of a random collection of thoughts because earlier today I came to the conclusion that I need something very similar to Active Directory Federation Services, except for non-domain users.  This is relatively easy to do; all I need is to create a Secure Token Service with a user store for the back end. 

The simplest approach is to use ASP.NET Membership and Roles with SqlProvider’s wrapped up by some WIF special sauce.  Turns out Dominick Baier already did just that with StarterSTS.

The problems I have with this is that it’s a pain to manage when you start getting more than a hundred or so users.  Extending user properties is hard to do too.  So my solution is to use something that is designed for user identities… an LDAP directory.  If it’s good enough for Active Directory, it’ll be plenty useful for this situation.

Reasoning
As an aside, the reason I’m not using Active Directory in the first place is because I need to manage a few thousand well known users without CAL’s.  This would amount to upwards of a couple hundred thousand dollars in licensing costs that just isn’t in the budget.  Further, most of these users probably wouldn’t use any of our systems that use Active Directory for authentication, but nevertheless, we need accounts for them.

Also, it would be a lot easier to manage creation and modification of user accounts because there are loads of processes that have been designed to pull user data out of HR applications into LDAP directories instead of custom SQL queries.

So lets think about what makes up Active Directory Federation Services.  It has roles that provides:

  • Token Services
  • A Windows Authentication end-point
  • An Attribute store-property-to-claim mapper (maps any LDAP properties to any claim types)
  • An application management tool (MMC snap-in and PowerShell cmdlets)
  • Proxy Services (Allows requests to pass NAT’ed zones)

That’s a pretty lightweight product when you compare it to the other services in Microsoft’s Identity stack. 

We can simplify it even further by breaking down the roles we need.

Token Services

This is actually pretty easy to accomplish.  Refer back to the WIF magic sauce.

Authentication end-point

This is just (well, you know what I mean) a web page login control.  We can’t do Windows Authentication without Kerberos (or NTLM), and we can’t do Kerberos without Active Directory (technically it could be done, but you’d be crazy to try).

Attribute store-property-to-claim mapper

ADFS can connect to a bunch of different attribute stores, including custom built stores if you provide assemblies.  We only really need to map to a few LDAP properties, and make it easy to map to other properties in the future.

Application management tool

This would be to manage the mapper and a few STS settings like URI names and certificates.  This, I think, would be a relatively simple application if we designed the configuration database properly.

Proxy Services

Proxies are a pain in the butt.  Useful in general, but we don’t really need to think about this at the moment.

Some Warnings

There are some things that are worth mentioning.  We have to be really careful about what we create because we are developing a serious piece of the security infrastructure.  Yes, it is for a group of employees that won’t have much access to anything dangerous (if they need access, they’d be migrated to Active Directory), but nevertheless we are creating the main ingress point for the majority of our employees.  It also needs to be accessible from the internet.

It may sound like I think it’ll be a synch to develop this system and have it work securely, but in reality there is a lot that will need to go into it to protect the network, the employees, and the data this could possibly interact with.  It is tough to develop applications securely.  It is far harder to develop secure applications whose sole responsibility is security related.

Next Steps

The next step is to design the thing.  I know how it will exist in relation to the systems it will be used to provide identity to, but aside from that, the architecture of the thing is still unknown.  With any luck I can accomplish rough designs tomorrow on the train, on my way to visit family for the holiday.

Better yet, maybe while visiting with family. Winking smile

Working with ADFS 2 via PowerShell

Over the last few years Microsoft has made a push for all of it’s Server Solutions to have the capability of being managed via PowerShell.  Active Directory Federation Services is no different.

When we installed ADFS for the first time, the installer told us it needed PowerShell as a pre-requisite, so we get some cmdlets available to us out of the box.  Before we start playing around with them though we need to register the cmdlets to our PowerShell session. We can do with this command:

Add-PSSnapin Microsoft.Adfs.PowerShell

At this point we can now muck around with all of the available cmdlets.  For a full list of available cmdlets for ADFS check out TechNet.

Let’s take a look at our ADFS Server Properties:

Get-AdfsProperties

AcceptableIdentifiers          : {}
AddProxyAuthorizationRules     : […snip…]
AutoCertificateRollover        : True
CertificateCriticalThreshold   : 2
CertificateDuration            : 365
CertificateGenerationThreshold : 20
CertificatePromotionThreshold  : 5
CertificateRolloverInterval    : 720
CertificateSharingContainer    :
CertificateThresholdMultiplier : 1440
ClientCertRevocationCheck      : None
ContactPerson                  :
DisplayName                    : WEB1.nexus.external.test
ExtendedProtectionTokenCheck   : Allow
FederationPassiveAddress       : /adfs/ls/
HostName                       : WEB1.nexus.external.test
HttpPort                       : 80
HttpsPort                      : 443
Identifier                     : http://web1.nexus.external.test/adfs/services/trust
InstalledLanguage              : en-US
LogLevel                       : {Errors, Information, Verbose, Warnings}
MonitoringInterval             : 1440
NetTcpPort                     : 1501
NtlmOnlySupportedClientAtProxy : False
OrganizationInfo               :
PreventTokenReplays            : True
ProxyTrustId                   : 58cb3f40-0633-4d9e-b3c2-84f9bc8c2ce8
ProxyTrustTokenLifetime        : 21600
ReplayCacheExpirationInterval  : 60
SignedSamlRequestsRequired     : False
SamlMessageDeliveryWindow      : 5
SignSamlAuthnRequests          : False
SsoLifetime                    : 480

Nothing fancy there.  What about updating?

get-help Set-AdfsProperties

Yep, we can do that:

NAME
    Set-ADFSProperties
   
SYNOPSIS
    Sets the properties of the Federation Service.
   
   
SYNTAX 
    […snip…]    
   
DETAILED DESCRIPTION
    The Set-ADFSProperties cmdlet sets the global properties and configuration of the Federation Service.

Updating settings isn’t all that exciting, so what about managing Relying Parties?

Add-ADFSRelyingPartyTrust
Get-ADFSRelyingPartyTrust
Remove-ADFSRelyingPartyTrust
Enable-ADFSRelyingPartyTrust
Disable-ADFSRelyingPartyTrust
Update-ADFSRelyingPartyTrust

You can also manage things like Certificates:

Add-ADFSCertificate
Remove-ADFSCertificate
Update-ADFSCertificate

There are many more things you can do from within PowerShell.  Again, for the full list check out TechNet.

Being able to manage ADFS directly from PowerShell makes things a lot easier.  Not only for those who aren’t too keen on using MMC snap-ins, but also for the developers to automate deployment for testing and development.

Videos on Identity Foundation and ADFS

Some videos from the last PDC…

LOTS of information…

Certificates and ADFS 2.0

One of the problems with pushing all this data back and forth between Token Services and clients and Relying Parties is that some of this information really needs to encrypted.  If someone can eavesdrop on your communications and catch your token authorization they could easily impersonate you.  We don’t want that.  As such, we use certificates in ADFS for EVERYTHING.

The problem with doing things this way is that certificates are a pain in the neck.  With ADFS we need at least three certificates for each server:

  • Service Communication certificate: This certificate is used for SSL communications for web services and connections between proxies.  This is the certificate used by IIS for the Federation Service site.
  • Token Signing certificate: This certificate is used to sign all tokens passed to the client.
  • Token decryption certificate: This certificate is used for decrypting incoming tokens.  This would be the private key for the Service Communication certificate.

Managing these certificates isn’t easy.  Sometimes we can get away with just using our domain CA, other times we need 3rd party CA’s to sign them.  Microsoft has provided lots of guidance in this, but it’s not the easiest to find.  You can access it on TechNet (Certificate Requirements for Federation Servers): http://technet.microsoft.com/en-ca/library/dd807040(WS.10).aspx

Hopefully that helps.

Single Sign-On Between the Cloud and On-Premise using ADFS 2

One of the issues I hear about hosting services in the cloud has to do with managing Identity.  Since the service isn’t local, it’s harder to tie it into services like Active Directory.  What do I mean by this?

I’m kind of particular how certain things work.  I hate having more than one set of credentials across applications.  Theoretically since we can’t join our Azure Servers to our domain, there’s a good chance we will need separate credentials between our internal domain and Cloud Services.  However, it’s possible to make our Cloud Applications use our Active Directory credentials via a Claims Service.

With Federation Services it’s surprisingly easy to do.  Yesterday we talked about installing Active Directory Federation Services and federating an application.  Today we will talk about what it takes to get things talking between Azure and ADFS.

As a recap, yesterday we:

  1. Installed prerequisites
  2. Installed ADFS 2.0 on a domain joined server
  3. Created a relying party
  4. Created claims mappings to data in Active Directory
  5. Created a simple Claims-Aware application

So what do we need to do next?  There really isn’t much we need to do:

  1. Build Azure App
  2. Federate it using FedUtil.exe

Building an Azure application isn’t trivial, but we don’t need to know much to Federate it. 

How do we federate it?  Follow these steps providing the Azure details for the application URI and the Federation Metadata from ADFS. 

One of the gotcha’s with deploying to Azure though is that the Microsoft.IdentityModel assembly is not part of the GAC, and it’s not in Azure builds.  Therefore we need to copy the assembly to the bin folder for deployment.  We do that by going to the Microsoft.IdentityModel reference properties and setting Copy Local to true:

image

That isn’t the only gotcha.  We need to keep in mind how data is transferred between Cloud and intranet.  In most cases, nothing goes on behind the scenes; it passes across the client’s browser through POST calls.  If the client’s browser is on the local intranet, when it hits the cloud app it will redirect to an intranet location.  This works because the client has access to both the cloud app and can access ADFS.  This isn’t necessarily the case with people who work offsite, or are partners with the company.

We need to have the ADFS Server accessible to the public.  This is kind of an ugly situation.  Leaving the politics out of this, we are sticking a domain joined system out in the public that’s sole responsibility is authentication and identity mapping.

One way to mitigate certain risks is to use an ADFS Proxy Service.  This service will sit on a non-domain joined system sitting on an edge network that creates a connection to the ADFS Server sitting inside the corporate network.  External applications would use the Proxy service.

Installing the Proxy service is relatively simple, but a topic for another post.

Installing ADFS 2 and Federating an Application

From Microsoft Marketing, ADFS 2.0 is:

Active Directory Federation Services 2.0 helps IT enable users to collaborate across organizational boundaries and easily access applications on-premises and in the cloud, while maintaining application security. Through a claims-based infrastructure, IT can enable a single sign-on experience for end-users to applications without requiring a separate account or password, whether applications are located in partner organizations or hosted in the cloud.

So, it’s a Token Service plus some.  In a previous post I had said:

In other words it is a method for centralizing user Identity information, very much like how the Windows Live and OpenID systems work.  The system is reasonably simple.  I have a Membership data store that contains user information.  I want (n) number of websites to use that membership store, EXCEPT I don’t want each application to have direct access to membership data such as passwords.  The way around it is through claims.

The membership store in this case being Active Directory.

I thought it would be a good idea to run through how to install ADFS and set up an application to use it.  Since we already discussed how to federate an application using FedUtil.exe, I will let you go through the steps in the previous post.  I will provide information on where to find the Metadata later on in this post.

But First: The Prerequisites

  1. Join the Server to the Domain. (I’ve started the installation of ADFS three times on non-domain joined systems.  Doh!)
  2. Install the latest .NET Framework.  I’m kinda partial to using SmallestDotNet.com created by Scott Hanselman.  It’s easy.
  3. Install IIS.  If you are running Server 2008 R2 you can follow these steps in another post, or just go through the wizards.  FYI: The post installs EVERY feature.  Just remember that when you move to production.  Surface Area and what not…
  4. Install PowerShell.
  5. Install the Windows Identity Foundation: http://www.microsoft.com/downloads/details.aspx?FamilyID=eb9c345f-e830-40b8-a5fe-ae7a864c4d76&displaylang=en
  6. Install SQL Server.  This is NOT required.  You only need to install it if you want to use a SQL Database to get custom Claims data.  You could also use a SQL Server on another server…
  7. Download ADFS 2.0 RTW: http://www.microsoft.com/downloads/details.aspx?familyid=118c3588-9070-426a-b655-6cec0a92c10b&displaylang=en

The Installation

image

Read the terms and accept them.  If you notice, you only have to read half of what you see because the rest is in French.  Maybe the lawyers are listening…these things are getting more readable.

image

Select Federation Server.  A Server Proxy allows you to use ADFS on a web server not joined to the domain.

image

We already installed all of these things.  When you click next it will check for latest hotfixes and ask if you want to open the configuration MMC snap-in.  Start it.

image

We want to start the configuration Wizard and then create a new Federation Service:

image

Next we want to create a Stand-alone federation server:

image

We need to select a certificate for ADFS to use.  By default it uses the SSL certificate of the default site in IIS.  So lets add one.  In the IIS Manager select the server and then select Server Certificates:

image

We have a couple options when it comes to adding a certificate.  For the sake of this post I’ll just create a self-signed certificate, but if you have a domain Certificate Authority you could go that route, or if this is a public facing service create a request and get a certificate from a 3rd party CA.

image

Once we’ve created the certificate we assign it to the web site.  Go to the website and select Bindings…

image

Add a site binding for https:

image

Now that we’ve done that we can go back to the Configuration Wizard:

image

Click next and it will install the service.  It will stop IIS so be aware of that.

image

You may receive this error if you are installing on Server 2008:

image

The fix for this is here: http://www.syfuhs.net/2010/07/23/ADFS20WindowsServiceNotStartingOnServer2008.aspx

You will need to re-run the configuration wizard if you do this.  It may complain about the virtual applications already existing.  You two options: 1) delete the applications in IIS as well as the folder C:\inetpub\adfs; 2) Ignore the warning.

Back to the installation, it will create two new Virtual Applications in IIS:

image

Once the wizard finishes you can go back to the MMC snap-in and fiddle around.  The first thing we need to do is create an entry for a Relying Party.  This will allow us to create a web application to work with it.

image

When creating an RP we have a couple options to provide configuration data.

image

Since we are going to create a web application from scratch we will enter in manual data.  If you already have the application built and have Federation Metadata available for it, by all means just use that.

We need a name:

image

Very original, eh?

Next we need to decide on what profile we will be using.  Since we are building an application from scratch we can take advantage of the 2.0 profile, but if we needed backwards compatibility for a legacy application we should select the 1.0/1.1 profile.

image

Next we specify the certificate to encrypt our claims sent to the application.  We only need the public key of the certificate.  When we run FedUtil.exe we can specify which certificate we want to use to decrypt the incoming tokens.  This will be the private key of the same certificate.  For the sake of this, we’ll skip it.

image

The next step gets a little confusing.  It asks which protocols we want to use if we are federating with a separate STS.  In this case since we aren’t doing anything that crazy we can ignore them and continue:

image

We next need to specify the RP’s identifying URI.

image

Allow anyone and everyone, or deny everyone and add specific users later?  Allow everyone…

image

When we finish we want to edit the claim rules:

image

This dialog will allow us to add mappings between claims and the data within Active Directory:

image

So lets add a rule.  We want to Send LDAP Attributes as Claims

image

First we specify what data in Active Directory we want to provide:

image

Then we specify which claim type to use:

image

And ADFS is configured!  Lets create our Relying Party.  You can follow these steps: Making an ASP.NET Website Claims Aware with the Windows Identity Foundation.  To get the Federation Metadata for ADFS navigate to the URL that the default website is mapped to + /FederationMetadata/2007-06/FederationMetadata.xml.  In my case it’s https://web1.nexus.internal.test/FederationMetadata/2007-06/FederationMetadata.xml.

Once you finish the utility it’s important that we tell ADFS that our new RP has Metadata available.  Double click on the RP to get to the properties.  Select Monitoring:

image

Add the URL for the Metadata and select Monitor relying party.  This will periodically call up the URL and download the metadata in the event that it changes.

At this point we can test.  Hit F5 and we will redirect to the ADFS page.  It will ask for domain credentials and redirect back to our page.  Since I tested it with a domain admin account I got this back:

image

It works!

For more information on ADFS 2.0 check out http://www.microsoft.com/windowsserver2008/en/us/ad-fs-2-overview.aspx or the WIF Blog at http://blogs.msdn.com/b/card/

Happy coding!