Identity-Based Decisions

I thought I'd follow-up on my post from this weekend and add some additional context around the need for strong proofing across the Internet as a precursor to an AzaaS model.   There is a very valid question that we all must ask - who do you think you are?  Without some form of strong identity proofing, your reputation is what defines you.  Unless there is a trusted 3rd party to vouch for you, then your identity is self-asserted.  Back in the day, the "my word is my bond" technique for trust was acceptable, but not so much today.

So what? For low value transactions, this is just fine.  At the end of the day, it doesn't matter if your Facebook profile is a real person. For higher value transactions, however, this is extremely important.  This is particularly true for the enterprise, where relationships with businesses, organizations, and consumers is the lifeblood of the organization. After all, the Service Providers need to make decisions based on the identities using the service. And if the identity is inaccurate, it's going to be a poor decision. When my supplier accesses my invoicing system, I really want to make sure that the person logging in is from the supplier.  If I'm buying a car and completing a title transfer online, I want to make certain that the person I'm giving my money to really owns the car.  This applies to virtually every area of online services - businesses, government, health care, etc...

Wouldn't it be interesting to imagine an online world where every identity is proofed to some level, and the level of that proofing follows the identity from place to place?  Would Service Providers make different decisions?  I think they would.  If you proved your digital identity in-person at, say, your local DMV and they gave you a strong credential to assert this proof, I'd be much more comfortable buying your car online. 

Authorization decisions are just another type of decision that a Service Provider must make about how someone uses their service. In order for us to starting thinking about a Trust Framework model to authorization across the Internet, the proofing problem needs to be solved. And there are, unfortunately, more questions than there are answers.  There are some consumer-based solutions out there now (the Symantec/Experian solution, for example), but we've got to break out of the bounds of the enterprise and make identity proofing available to the general public in wide-spread form.  NSTIC is laying these foundations, and I believe a hybrid public/private approach is the right approach - as long as the privacy-enhacing technology is in place as an identity mediator.

Authorization as a Service (AzaaS)

The other day, I stumbled upon a ZDNet blog post from 2006 - called "Identity Management as a Service".  Back then, and even now, we all had the "as a Service" bug - turning everything we can into a web service of some sort and tacking an "aaS" at the end.  The idea of IdMaaS is being thoughfully pursued, with folks such as our own Kim Cameron getting involved in the discussion.

The author of the aforementioned blog, Eric Norin, asserts that SalesForce.com may be a potential IdMaaS provider. Back in 2006, this would have made sense - identity was very much trust-driven model and organizations only wanted to deal with trusted entities.  While there is a great need for trusted identities, I think a lot of folks have realized that untrusted identities are still valuable, up to a certain extent. Rather than seeing SalesForce.com come to the table as a trusted identity provider, we've seen providers like Facebook and Twitter crop up and offer "less trusted" identities. "Social Identity Providers" have become the norm, and people just inherently understand and accept the fact that there's a chance the person sitting behind the keyboard is not who they claim to be.

To overcome this, the consumers of these identities (the Service Providers) have to put their own identity proofing mechanisms in place.  You can log into a web site with your Facebook account and the Service Provider doesn't really care if your identity has been proofed. However, when it comes time to pay for something, then the SP cares a lot because their business model is dependent on valid, legal transactions. The higher value the transaction, the more important the proofing. With initiatives like NSTIC calling for safe and private identity usage online, it's vitally important that we solve this high assurance identity problem. By the way, did you notice that Microsoft is involved in one of the NSTIC pilots? :)

So while social identity providers are great for providing identities with a low level of assurance, I don't think we'll see truly effective IdMaaS until providers adopt strong proofing mechanisms and we have a well-adopted, trusted exchange for "high assurance" identities.

However, hidden among all of this is an even greater need.  I've felt for quite some time that we all spend too much time talking about "Identity" Management and not enough time talking about "Access" Management.  After all, identity is a 4-legged stool (Administration, Authentication, Authorization, and Auditing), and we focus a lot on the first two legs (Administration and Authentication). We can have the most thoughtful and well-adopted IdMaaS service in place, but unless we get to a universally accepted authorization model, we're missing a large part of the identity puzzle. So I'm going to join in on the "aaS" fad and suggest that we start thinking about "Authorization as a Service" now before we get to the point where we wish we had thought about it sooner.

Kerberos in Multi-Tier Applications - Part 1 - Properly Configuring SPNs

Understanding how to correctly configure Kerberos in multi-tier applications, such as FIM, seems to be an elusive skill in not only identity folks, but even in well-seasoned IT people.  Even the most well-known and respected people get it wrong. It’s a very confusing topic. When I explain this to someone, it sometimes takes multiple conversations with the same person to help them understand it. Nothing to do with the person’s technical skills – it’s just a really complex topic if you’re not used to working with it.  To make this a little more digestible, I’m going to split this discussion into two posts.

In this first post, I’m going to explain why a Service Principal Name (SPN) is important and how to properly set one.

A Little Background on Kerberos

Before we can look at what an SPN is, you first have to have a decent understand of the basics of Kerberos.  In a nutshell, this is how it works – when a client (a user on a Windows 7 workstation, for example) wants to authenticate and use a resource on the network (such as a file share on a file server), the client gives the server a Kerberos ticket, which provides proof of the client’s identity.

To get a ticket, the client goes to a Key Distribution Center (such as a Domain Controller) and asks for one. The KDC will create a ticket and put some information inside. Here is some of the information in the ticket:

• Principal of the user
• Principal of the service hosting the resource
• Timestamp indicating the date and time that the ticket becomes valid
• Lifetime of the ticket
• Session key that the client and server can use to establish an encrypted connection with

This ticket is encrypted with a shared secret that only the KDC and the Server hosting the resource knows. The KDC gives the ticket to the user, along with a copy of a session key, which both the user and the Server will know.  The user, in turn, gives the ticket to the Server and also sends the Server some data along with it (the user principal and timestamp – also known as the Authenticator), which is encrypted with the session key.

The Server decrypts the ticket with its copy of the secret (the one that is known only by the Server and the KDC) and it extracts the session key (the same one that the user got a copy of from the KDC) from the ticket. The Server can then use that session key to decrypt the Authenticator that the user sent over to it. If the Server can successfully decrypt the Authenticator, it knows that the user’s identity was verified by the KDC.

So, let’s recap on what happened in english, using the example of a user accessing a file share on a Windows Server:

1. The user decides that he wants to connect to the file share
2. The user goes to the Domain Controller (KDC) and says – “Hey, Mr. DC, I need a Kerberos ticket for this here file share so I can prove my identity to it”
3. The DC says – “Sure, let me build a session key for you guys to talk securely with”
4. The DC then looks in its database (Active Directory) and looks up the account that the file server is running under (the computer account of the server)
5. The DC uses the secret in the computer account to encrypt the ticket it creates
6. The DC sends the ticket and the session key back to the client
7. The client sends the ticket and the encrypted Authenticator to the file server and says “Here you go – here’s proof of my identity and here’s the ticket to verify it”
8. The file server decrypts the ticket, extracts the session key, and uses it to decrypt the Authenticator
9. The file server says “OK, you’re good to go – here’s the data you want”

Where’s the SPN Used?

So now you might be asking – “what does this have to do with SPNs?”  A lot, actually. The key piece that SPNs are needed for are in step #4 of what I described above. In order for the DC to give a client a session ticket, it needs to know who the ticket is for and what secret to encrypt it with. And that’s where the SPN comes into play.

The SPN is all about helping the DC figure out which account to encrypt the session ticket for. Let’s look at it another way… let’s say that the situation is a user connecting to a SharePoint web site with Internet Explorer and trying to authenticate with Kerberos. In this case, the user goes to the DC and says – “Hey, Mr. DC, I need a Kerberos ticket for sharepoint.contoso.com.”   This should start making more sense about now…

You see, the web browser can’t ask for a Kerberos ticket for the server named CONTOSO-SHR01 because it has no idea what the name of the server is. The only thing the client knows to tell the DC is – “give me a ticket for sharepoint.contoso.com”. The DC has to figure out which account sharepoint.contoso.com is running under.  And the way it does this is by looking in Active Directory and finding the account that has the servicePrincipalName (SPN) attribute that matches sharepoint.contoso.com. Once the DC finds the account that the sharepoint.contoso.com web site is running under, it knows what secret to use to encrypt the session ticket.

Now you should also understand why duplicate SPNs are a problem. If more than one account has the same SPN, then the Domain Controller gets confused because it doesn’t know which account to encrypt the Kerberos ticket for.

What Does an SPN Look Like

As I just mentioned, SPNs are configured on the servicePrincipalName attribute of security principals in Active Directory – this applies to both user accounts and computer accounts. The servicePrincipalName attribute is a multi-valued attribute, because a security principal can have multiple SPNs. This makes sense, as a single account might host more than one service.

The actual SPN itself is presented in the format of: Service/Hostname

This is important because it adheres to the Kerberos v5 standards for service principals. Here are a couple of examples:

Service	Host Name	SPN
Web Site	www.contoso.com	HTTP/www.contoso.com
SQL	sqlserver1.fabrikam.com	MSSQLSvc/sqlserver1.fabrikam.com
File Share	fileserver03	HOST/fileserver03

You may have noticed that in the “File Share” example, the SPN uses HOST as the Service portion of the name. The HOST service is a generic representation of any service that runs under the context of the server’s security principal. In general, these are services that are provided by the Operating System. The computer account in Active Directory owns the HOST SPN. In the following screen shot, you’ll notice that this particular server (CONTOSO-WEB1) owns the SPNs for both the NetBIOS name and the FQDN, since a client could potentially use either SPN when getting a Kerberos ticket for the server – it entirely depends on how the client application that is requesting the Kerberos ticket works.

Setting a Proper SPN

So to recap – here are the rules to follow if you want to properly set an SPN.

• The SPN must be in the format of Service/Hostname
• The SPN for a service can only be attached to one account
• The account that has the SPN has to be the account that receives the Kerberos ticket – this may be either a dedicated user account (also known as a Service Account)  or the computer account that belongs to the server
• An account can have as many SPNs as you want
• Use the HOST SPN for services that are running under the principal of the server’s computer account in Active Directory

So if you’re running SharePoint under a dedicated service account named CONTOSO\svc-sharepoint then the svc-sharepoint account in Active Directory needs to have the following entry in the servicePrincipalName attribute: HTTP/sharepoint.contoso.com.  It needs this so the Domain Controller knows which account to get the Kerberos ticket for when a user tries to connect to the SharePoint site.

SSO with SharePoint & Office Integration

Now,  I'm not a SharePoint person, but as an identity guy I've been forced to learn as much as SharePoint authentication as possible over the past several months.  I've been having one discussion in particular a LOT. This discussion revolves around why Single Sign On doesn't work well between SharePoint and Office integration. So I'm going to take some time, here, and explain what's happening.

The issue revolves around the Office client using a different cookie store than 3rd party web browsers use.  There are two ways to achieve SSO between SharePoint and Office – using either cookies or automated 401 response (integrated authentication)

Cookies for Authentication

The issue with the cookie-based approach really has more to do with Office than anything else. Office on Windows uses the wininet cookie jar. So when Office contacts a SharePoint site to open a document, it looks in wininet to find the cookie to use for SSO.  Internet Explorer also uses wininet. So if the user logs into the SharePoint site with IE, IE will put the SSO cookie into wininet. Then, when the user opens Office, Office uses that cookie that IE already put there.

Other web browser, however, use their own cookie jars. So if a user browses to SharePoint with, say Firefox, then Firefox will not put a cookie in the wininet cookie jar. When that same user opens Office, Office will see that there is no cookie for that SharePoint site there, and will undergo the typical authentication sequence in SharePoint (described in the next paragraph).  This is a similar experience for people who use Mac. Office on Mac doesn’t see the SSO cookie and undergoes the typical SharePoint authentication sequence.

Authentication without Cookies

When there’s no cookie, typical SharePoint authentication occurs. Depending on how SharePoint is configured for authentication, it will either respond with a 302 redirect (when configured with Forms Authentication) or a direct 401 response (when configured with Integrated Authentication).  If SharePoint is configured with Forms Authentication, SharePoint issues the 302 response back to the browser, which redirects the browser (or Office) to the logon page. Once this happens, the logon page UI is sent to the client over a 200 response. Therefore, the only way to achieve SSO with Forms Authentication is through the use of a cookie.  If, however, SharePoint is configured with Integrated Authentication, it will respond to the user’s request with a 401. One of two things will happen in the browser (or in Office):

1. If the browser is configured to auto-respond to the 401 with a Kerberos ticket or NTLM token then the browser will send back the credentials and the user will have a Single Sign On experience

2. If the browser cannot automatically respond to the 401, it will prompt the user with the typical, non-descriptive 401 dialog, asking the user for credentials

SSO Regardless of Cookies

Office uses the same API as Internet Explorer. So if all of the following conditions are met, the user will experience SSO regardless of the cookie situation, because Office will auto-respond to the 401 from SharePoint:

• Integrated Authentication is enabled in Internet Explorer
• The URL of SharePoint is added to the Intranet zone in IE

• The user is logged into a domain-joined computer with their domain credentials

Sample Scenario

So let’s look at a scenario – how about a user logged into a domain-joined Windows computer and using Firefox.  Assuming that the above conditions are met for SSO –

• When the user browses to SharePoint in Firefox, SP will issue a 401. Firefox will not be able to respond to the 401 automatically (unless you are using a plug-in that does it for you), so the user will be prompted with that familiar 401 dialog.
• When the user opens up an Office document, Office will not send SharePoint a cookie (because Firefox can’t put a cookie in the wininet cookie jar), so SharePoint will respond to the request with another 401. But since the SSO conditions in the previous paragraph are met, Office will auto-respond to the 401 with either a Kerberos ticket or an NTLM credential and the user will experience SSO to Office.

Clarifying the Relationship Between SharePoint 2010 and AD FS 2.0

I was teaching an AD FS class internally here at Microsoft a few weeks ago, and during the class I covered SharePoint  2010 integration with AD FS. While there are lots of great materials out there that talk about the technical aspects of  how to set up the trust and send claims, there isn't much that really clarifies the concepts. So I just want to take a few  minutes and describe what happens conceptually, as it impacts your deployment and configuration of claims-based  SharePoint.

When a trust is established between AD FS and a typical (if there is such a thing) claims based application, the  application will accept the token from AD FS, verify it's signature, extract the claims, and use them.  A typical trust looks  something like this:

But the trust between AD FS and SharePoint, really looks something more like this:

Here, we have 2 different web apps in SharePoint, and therefore there are two different trusts from the perspective of the AD FS server. AD FS is going to create a unique token for each web app with different claims in each. However, the web apps themselves don't trust the tokens that AD FS sends to them. Instead, the SharePoint STS is what trusts the tokens that AD FS sends. Or to rephrase it another way, AD FS thinks that it is sending tokens to 2 different applications, but in reality it's not sending the tokens to either - it's sending them to the SharePoint STS.

The 3rd trust (the one that points from the SharePoint STS to the AD FS server) is the SPTrustedIdentityTokenIssuer object that you create in SharePoint. This type of design has some interesting side-effects. First, SharePoint can only have one SPTrustedIdentityTokenIssuer object for an AD FS server. Therefore, if you want different claims for each web app, you need to define the aggregate set of those claims on the SPTrustedIdentityTokenIssuer. To clarify, let's say that I want an "EmailAddress" claim in WebApp1 and an "Role" claim in WebApp2. The SPTrustedIdentityTokenIssuer object has to be configured with at least 2 claim mappings - one for "EmailAddress" and another for "Role". However, neither application is using both of them.

One of the interesting outcomes of this model is that from the application's viewpoint, there is a "pool of claims available" from the AD FS STS. Every application sees the same "pool of claims". However, if AD FS doesn't send that claim over for that particular web app, then the web app won't receive it even if it's expecting it. To visual this - imagine that I'm a user in WebApp1 and I'm defining a permission on a document library. As shown in the following image, I have 3 claims available. These are the same claims that every application sees, because it's "pool of claims" defined as "Claim Mappings" on the SPTrustedIdentityTokenIssuer object in SharePoint.

However, my Relying Party trusts in AD FS may not be configured to send all three claims for every application. So even though the end user may think that all of these claims are available for them to use, they may not be. This can be very confusing to the user - and is one of the reasons why you need to use a custom claims provider in almost every claims-based SharePoint 2010 deployment.

The FedAuth cookie box on the right of second diagam is another interesting quirk of how this trust works. In SharePoint, the STS does not send a SAML token to the web app. Instead, the STS creates the FedAuth cookie (a standard cookie used in WIF for the identity session state) which has an encrypted copy of the SessionSecurityToken object. This is the .NET object that is created by WIF after the SAML token is received, verified, and the claims are pulled out of it. So after the token is POSTed from AD FS back to the SharePoint STS, the SharePoint STS creates the FedAuth cookie and then issues a 302 redirect back to the user, which redirects the user to the original web app with their FedAuth cookie in hand. The SharePoint web app receives the cookie when the user request comes back to it and it uses WIF to extract the SessionSecurityToken object from the cookie and goes through the process of converting the identity into something that SharePoint can use internally.

So the relationship between AD FS and SharePoint is quite a bit different than other applications. If you can understand how this works, it will help you make better decisions about how to design your claims architecture in SharePoint.