What makes Claims Based Authentication Secure?

Update: I should have mentioned this when I first posted, but some of these thoughts are the result of me reading Programming Windows Identity Foundation.  While I hope I haven’t copied the ideas outright, I believe the interpretation is unique-ish. Smile

One of the main reasons we as developers shy away from new technologies is because we are afraid of it.  As we learned in elementary school, the reason we are afraid usually boils down to not having enough information about the topic.  I’ve found this especially true with anything security related.  So, lets think about something for a minute.

I’m not entirely sure how valid a method this is for measure, but I like to think that as developers we measure our understanding of something by how much we abstract away the problems it creates.  Now let me ask you this question:

How much of an abstraction layer do we create for identity?

Arguably very little because in most cases we half-ass it.

I say this knowing full well I’m extremely guilty of it.  Sure, I’d create a User class and populate with application specific data, but to populate the object I would call Active Directory or SQL directly.  That created a tightly coupled dependency between the application and the user store.  That works perfectly up until you need to migrate those users in a SQL database to Active Directory.  Oops.

So why do we do this?

My reason for doing this is pretty simple.  I didn’t know any better.  The reason I didn’t know better was also pretty simple.  Of the available options to abstract away the identity I didn’t understand how the technology worked, or more likely, I didn’t trust it.  Claims based authentication is a perfect example of this.  I thought to myself when I first came across this: “are you nuts?  You want me to hand over authentication to someone else and then I have to trust them that what they give me is valid?  I don’t think so.”

Well, yes actually.

Authentication, identification, and authorization are simply processes in the grand scheme of an application lifecycle.  They are privileged, but that just means we need to be careful about it.  Fear, as it turns out, is the number one reason why we don’t abstract this part out.*

With that, I thought it would be a perfect opportunity to take a look at a few of the reasons why Claims based authentication is reasonably secure.  I would also like to take this time to compare some of these reasons to why our current methods of user authentication are usually done wrong.


First and foremost we trust the source.  Obviously a bank isn’t going to accept a handwritten piece of paper with my name on it as proof that I am me.  It stands to reason that you aren’t going to accept an identity from some random 3rd party provider for important proof of identity.

Encryption + SSL

The connection between RP and STS is over SSL.  Therefore no man in the middle attacks.  Then you encrypt the token.  Much like the SSL connection, the STS encrypts the payload with the RP’s public key, which only the RP can decrypt with its private key.  If you don’t use SSL anyone eavesdropping on the connection still can’t read the payload.  Also, the STS usually keeps a local copy of the certificate for token encryption.

How many of us encrypt our SQL connections when verifying  the user’s password?  How many of us use secured LDAP queries to Active Directory?  How many of us encrypt our web services?  I usually forget to.

Audience whitelist

Most commercial STS applications require that each request come from an approved Relying Party.  Moreover, most of those applications require that the endpoint that it responds to also be on an approved list.  You could probably fake it through DNS poisoning, but the certificates used for encryption and SSL would prevent you from doing anything meaningful since you couldn’t decrypt the token.

Do we verify the identity of the application requesting information from the SQL database?  Not usually the application.  However, we could do it via Kerberos impersonation.  E.g. lock down the specific data to the currently logged in/impersonated user.

Expiration and Duplication Prevention

All tokens have authentication timestamps.  They also normally have expiration timestamps.  Therefore they have a window of time that defines how long they are valid.  It is up to the application accepting the token to make sure the window is still acceptable, but it is still an opportunity for verification.  This also gives us the opportunity to prevent replay attacks.  All we have to do is keep track of all incoming tokens within the valid time window and see if the tokens repeat.  If so, we reject them.

There isn’t much we can do in a traditional setting to prevent this from happening.  If someone eavesdrops on the connection and grabs the username/password between the browser and your application, game over.  They don’t need to spoof anything.  They have the credentials.  SSL can fix this problem pretty easily though.


Once the token has been created by the STS, it will be signed by the STS’s private key.  If the token is modified in any way the signature wont match.  Since it is being signed by the private key of the STS, only the STS can resign it, however anyone can verify the signature through the STS’s public key.  And since it’s a certificate for the STS, we can use it as strong proof that the STS is who they say they are.  For a good primer on public key/private key stuff check out Wikipedia.

It's pretty tricky to modify payloads between SQL and an application, but it is certainly possible.  Since we don’t usually encrypt the connections (I am guilty of this daily – It’s something I need to work on Winking smile), intercepting packets and modifying them on the fly is possible.  There isn’t really a way to verify if the payload has been tampered with.

Sure, there is a level of trust between the data source and the application if they are both within the same datacenter, but what if it’s being hosted offsite by a 3rd party?  There is always going to be a situation where integrity can become an issue.  The question at that point then is: how much do you trust the source, as well as the connection to the source?

Authentication Level

Finally, if we are willing to accept that each item above increases the security and validity of the identity, there is really only one thing left to make sure is acceptable.  How was the user authenticated?  Username/password, Kerberos, smart card/certificates, etc.  If we aren’t happy with how they were authenticated, we don’t accept the token.

So now that we have a pretty strong basis for what makes the tokens containing claims as well as the relationship between the RP’s and STS’s secure, we don’t really need to fear the Claims model.

Now we just need to figure out how to replace our old code with the identity abstraction. Smile

* Strictly anecdotal evidence, mind you.

Managing Identity in SharePoint

Yet another presentation on the docket!  I submitted an abstract to SharePoint Summit 2011 and they accepted!  I will be presenting on SharePoint and how it manages Identity.  More specifically, how SharePoint 2010 uses WIF to handle Claims based authentication and Federation.

Here are the details

Event: SharePoint Summit 2011, January 31st 2011 – February 2nd, 2011

When: 11:30 a.m. - 12:45 p.m. February 1st, 2011

Where: Four Seasons Hotel, Toronto

Abstract: Managing identities within an organization is relatively easy. However, as business changes, we need to be able to adapt quickly. Identity is something that often gets overlooked in adaptation. In this session we will discuss the Windows Identity Foundation and how SharePoint uses it to adapt easily to change.

Link: http://www.sharepointsummit2011.com/Toronto/conference_day2.htm#session_7_3

Changing the Identity Game with the Windows Identity Foundation

Similar to the TVBUG presentation, I will be presenting on the Windows Identity Foundation to the Metro Toronto .NET User Group.

Here are the details:

When: November 10th, 2010

Where: KPMG, 333 Bay Street, 10th Floor, Toronto

Abstract: Identity is a tricky thing to manage. These days every application requires some knowledge of the user, which inevitably requires users to log in and out of the applications to prove they are who they are as well as requiring the application to keep record of the accounts. With the Windows Identity Foundation, built on top of a Claims-based architecture, there is a fundamental shift in the way we manage these users and their accounts. In this presentation we will take a look at the why's and dig into the how's of the Windows Identity Foundation by building an Identity aware application from scratch.

Presenting a TechDays Local Flavours Track Session!

Earlier this morning I got an email from John Bristowe congratulating me on being selected to present a session for the local flavours track at TechDays in Toronto!  This bumps up my count to 2.  Needless to say I am REALLY excited.

I was a little disappointed to find out there weren’t any sessions on the Windows Identity Foundation, so that just meant I had to submit my own to the local flavours track…and they accepted it!  Here are the details:

October 27, 3:40 PM to 4:45 PM

Breakout | LFT330: Windows Identity Foundation Simplified: All the Scary Things Made Un-Scary

The Windows Identity Foundation helps simplify user access for developers by externalizing user access from applications via claims and reducing development effort with pre-built security logic and integrated .NET tools. This presentation is an intimate discussion on the basics of the Windows Identity Foundation and its claims model. In this session, you’ll learn how to refactor an existing sample set of applications to use WIF, to connect identities to the Cloud, and to remove the burden of managing multiple disparate user stores.

Location: Metro Toronto Convention Centre - South Building (255 Front Street West, Toronto)

Room: TBA


Using Claims Based Identities with SharePoint 2010

When SharePoint 2010 was developed, Microsoft took extra care to include support for a claims-based identity model.  There are quite a few benefits to doing it this way, one of which is that it simplifies managing identities across organizational structures.  So lets take a look at adding a Secure Token Service as an Authentication Provider to SharePoint 2010.

First, Some Prerequisites

  • You have to use PowerShell for most of this.  You wouldn’t/shouldn’t be adding too many Providers to SharePoint all that often so there isn’t a GUI for this.
  • The claims that SharePoint will know about must be known during setup.  This isn’t that big a deal, but…

Telling SharePoint about the STS

Once you’ve collected all the information you need, open up PowerShell as an Administrator and add the SharePoint snap-in on the server.

Add-PSSnapin Microsoft.SharePoint.PowerShell

Next we need to create the certificate and claim mapping objects:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("d:\path\to\adfsCert.cer")

$claim1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming

$claim2 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming

There should be three lines.  They will be word-wrapped.

The certificate is pretty straightforward.  It is the public key of the STS.  The claims are also pretty straightforward.  There are two claims: the roles of the identity, and the email address of the identity.  You can add as many as the STS will support.

Next is to define the realm of the Relying Party; i.e. the SharePoint server.

$realm = "urn:" + $env:ComputerName + ":adfs"

By using a URN value you can mitigate future changes to addresses.  This becomes especially useful in an intranet/extranet scenario.

Then we define the sign-in URL for the STS.  In this case, we are using ADFS:

$signinurl = https://[myAdfsServer.fullyqualified.domainname]/adfs/ls/

Mind the SSL.

And finally we put it all together:

New-SPTrustedIdentityTokenIssuer -Name "MyDomainADFS2" -Description "ADFS 2 Federated Server for MyDomain" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $claim1,$claim2 -SignInUrl $signinurl -IdentifierClaim $claim2.InputClaimType

This should be a single line, word wrapped.  If you wanted to you could just call New-SPTrustedIdentityTokenIssuer and then fill in the values one at a time.  This might be useful for debugging.

At this point SharePoint now knows about the STS but none of the sites are set up to use it.

Authenticating SharePoint sites using the STS

For a good measure restart SharePoint/IIS.  Go into SharePoint Administration and create a new website and select Claims Based Authentication at the top:


Fill out the rest of the details and then when you get to Claims Authentication Types select Trusted Identity Provider and then select your STS.  In this case it is my ADFS Server:


Save the site and you are done.  Try navigating to the site and it should redirect you to your STS.  You can then manage users as you would normally with Active Directory accounts.

Converting Claims to Windows Tokens and User Impersonation

In a domain environment it is really useful to switch user contexts in a web application.  This could be if you are needing to log in with credentials that have elevated permissions (or vice-versa) or just needing to log in as another user.

It’s pretty easy to do this with Windows Identity Foundation and Claims Authentication.  When the WIF framework is installed, a service is installed (that is off by default) that can translate Claims to Windows Tokens.  This is called (not surprisingly) the Claims to Windows Token Service or (c2WTS).

Following the deploy-with-least-amount-of-attack-surface methodology, this service does not work out of the box.  You need to turn it on and enable which user’s are allowed to impersonate via token translation.  Now, this doesn’t mean which users can switch, it means which users running the process are allowed to switch.  E.g. the process running the IIS application pools local service/network service/local system/etc (preferably a named service user other than system users).

To allow users to do this go to C:\Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config and add in the service users to <allowedCallers>:

      By default no callers are allowed to use the Windows Identity Foundation Claims To NT Token Service.
      Add the identities you wish to allow below.
    <!-- <add value="NT AUTHORITY\Network Service" /> -->
    <!-- <add value="NT AUTHORITY\Local Service" /> –>
    <!-- <add value="nt authority\system" /> –>
    <!-- <add value="NT AUTHORITY\Authenticated Users" /> -->

You should notice that by default, all users are not allowed.  Once you’ve done that you can start up the service.  It is called Claims to Windows Token Service in the Services MMC snap-in.

That takes care of the administrative side of things.  Lets write some code.  But first, some usings:

using System;
using System.Linq;
using System.Security.Principal;
using System.Threading;
using Microsoft.IdentityModel.Claims;
using Microsoft.IdentityModel.WindowsTokenService;

The next step is to actually generate the token.  From an architectural perspective, we want to use the UPN claims type as that’s what the service wants to see.  To get the claim, we do some simple LINQ:

IClaimsIdentity identity = (ClaimsIdentity)Thread.CurrentPrincipal.Identity;
string upn = identity.Claims.Where(c => c.ClaimType == ClaimTypes.Upn).First().Value;

if (String.IsNullOrEmpty(upn))
    throw new Exception("No UPN claim found");

Following that we do the impersonation:

WindowsIdentity windowsIdentity = S4UClient.UpnLogon(upn);

using (WindowsImpersonationContext ctxt = windowsIdentity.Impersonate())

    ctxt.Undo(); // redundant with using { } statement

To release the token we call the Undo() method, but if you are within a using { } statement the Undo() method is called when the object is disposed.

One thing to keep in mind though.  If you do not have permission to impersonate a user a System.ServiceModel.Security.SecurityAccessDeniedException will be thrown.

That’s all there is to it.

Implementation Details

In my opinion, these types of calls really shouldn’t be made all that often.  Realistically you need to take a look at how impersonation fits into the application and then go from there.  Impersonation is pretty weighty topic for discussion, and frankly, I’m not an expert.

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:


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:


That’s all there is to it.

Vulnerabilities in Twitter’s OAuth Implementation

Earlier this week Twitter disabled Basic Authentication for clients, and switched over to their new OAuth implementation.  It turns out though that OAuth is fairly weak in a few areas, as it hasn’t really become a mature standard.  While this isn’t the end of the world, it does leave each implementer to their own devices to cover the weak points.

This is just a quick overview of the one of the WTF’s that is Twitter OAuth, but Ars Technica has a great article on this in detail.

One key point that Twitter seemed to miss entirely is how they handle client verification.  I.e. proving that the client in question is really who they say they are.  For instance, I use Sobees quite a bit, and have been playing around with MetroTwit lately too.  Twitter want’s each instance of Sobees to prove that it is Sobees.  The client application does this by getting a public/private key and passing them to the authentication mechanism.

This seems odd.  How does the application store the private key?  Most implementations will probably stick it in a config file while others might encrypt it.  Suffice to say, all applications need this private key.  It is very easy to extract text from binary structures, let alone config files, so what happens if I get another client’s private key?

Since this private key is used for identification, I could very easily stick that key into my application and pretend that I am that application.  This wouldn’t really lead to user PII being compromised, but it can easily cause harm.  Twitter’s goal for this is to reduce spam, because if they track too much spam coming from certain private keys they will revoke the key preventing the application from being able to sign the user in.

Who see’s the problem here?  What happens if my competitor steals my key and starts spamming people?  My key gets revoked, and I need to replace it.  If it’s a client application, that means updating it, testing it, deploying it, and hope that the mass downtime across every instance doesn’t lose too many customers for you.  Worse yet for those that have written iPhone apps, because that could mean weeks of delays while Apple twiddles their thumbs.

I suspect that they won’t revoke any keys once they come to their senses.  Or more likely, will revoke a key for something like TweetDeck and hear the outcry from the large user base.  After they can sign back in again, of course.

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


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.


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


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.


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


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


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:


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.


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


Add a site binding for https:


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


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


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


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:


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.


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


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:


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.


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.


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:


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


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


When we finish we want to edit the claim rules:


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


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


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


Then we specify which claim type to use:


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:


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:


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!

Making an ASP.NET MVC Application Claims Aware with Windows Identity Foundation

A couple posts back I had discussed how you would make an ASP.NET webforms application claims aware. It was reasonably detailed an hopefully it was clear.  I say that because to make an MVC application Claims aware, you follow the exact same procedure.

The only difference is the small little chunk of code to see what claims were returned.  Just drop this little snipped into a view and you can muck about:

    var claimsIdentity 
        = (System.Threading.Thread.CurrentPrincipal 
	   as Microsoft.IdentityModel.Claims.IClaimsPrincipal)
    foreach (var claim in claimsIdentity.Claims)
       <%: claim.ClaimType %>
    <%: claim.Value %>
    <% } %>