When you build claims-aware applications, the user presents her identity to your application as a set of claims (see Figure 1). One claim could be the user’s name, another might be her email address. The idea here is that an external identity system is configured to give your application everything it needs to know about the user with each request she makes, along with cryptographic assurance that the identity data you receive comes from a trusted source.
Under this model, single sign-on is much easier to achieve, and your application is no longer responsible for:
· Authenticating users
· Storing user accounts and passwords
· Calling to enterprise directories to look up user identity details
· Integrating with identity systems from other platforms or companies
Under this model, your application makes identity-related decisions based on claims supplied by the user. This could be anything from simple application personalization with the user’s first name, to authorizing the user to access higher valued features and resources in your application.
It’s not Just About Federation
The claims-based model of identity has been incubating for awhile now inside Microsoft. The original reason for proposing this model was to enable federation between organizations, but over time it’s become apparent that claims aren’t just for federation. But some of these terms still linger on. For example, when you use Geneva Framework in your ASP.NET application, one way to perform claims processing is to enable an Geneva Framework component called the WS-Federation Authentication Module. Don’t let the word “federation” throw you off. There are clear benefits to building applications that outsource authentication and authorization. Any company that has, or plans to have in the future, more than one web application or web service, can benefit by starting with a claims-based model for identity.
Introduction to Claims-Based Identity
In this section of the paper, I’m going to introduce some terminology and concepts so that you, as a developer, can get your head around this new architecture for identity. Let’s start with some terminology.
Identity
The word “identity” is a very overloaded term. So far I’ve been using it to describe the problem space that includes authentication, authorization, etc. But for the purposes of describing the programming model in Geneva Framework, I will use the term identity to describe a set of attributes (well, claims as you’ll see shortly) that describe a user or some other entity in the system that you care about from a security standpoint.
Claim
You can think of a claim as a bit of identity information such as name, email address, age, membership in the Sales role, and so on. The more claims your application receives, the more you’ll know about your user. You may be wondering why I’m using the word “claim”, instead of the more traditional “attributes”, commonly used in the enterprise directory world. The reason has to do with the delivery method – in this model your application doesn’t look up user attributes in a directory. Instead, the user delivers claims to your application, and you’re going to examine them with a certain measure of doubt.
Each claim is made by an issuer, and you’ll trust the claim only as much as you trust the issuer. You’ll trust a claim made by your company’s domain controller more than you would if it were made by the user herself! As you’ll see shortly, the Claim class in Geneva Framework has an Issuer property that allows you to find out who issued the claim.
Security Token
The user delivers a set of claims to your application piggybacked along with her request. In a web service, these claims are carried in the security header of the SOAP envelope. In a browser-based web application, the claims arrive via an HTTP POST from the user’s browser, and may later be cached in a cookie if a session is desired. Regardless of how they arrive, they must be serialized somehow, and this is where security tokens come in. A security token is a serialized set of claims that is digitally signed by the issuing authority. The signature is important – it gives you assurance that the user didn’t just make up a bunch of claims and send them to you. In low security situations where cryptography isn’t necessary or desired, you can use unsigned tokens, but that’s not a scenario I’m going to focus on in this paper.
One of the core features in Geneva Framework is the ability to create and read security tokens. Geneva Framework and the underlying plumbing in the .NET Framework handles all the cryptographic heavy lifting, and presents your application with a set of claims that you can read.
Issuing Authority
There are lots of different types of issuing authorities, from domain controllers that issue Kerberos tickets, to certificate authorities that issue X.509 certificates, but the specific type of authority I’ll be talking about in this paper issues security tokens that contain claims. The issuing authority I’m speaking of is a web application or web service that knows how to issue security tokens. It must have enough knowledge to be able to issue the proper claims for the target relying party given the user making the request, and may be responsible for interacting with user stores to look up claims and authenticate the users themselves.
Whatever issuing authority you choose to buy or build, it will play a central role in your identity solution. When you factor authentication out of your application by relying on claims, you’re ultimately just passing responsibility to that authority and asking it to authenticate users on your behalf.
Security Token Service (STS)
A security token service (STS) is the plumbing that builds, signs, and issues security tokens according to the interoperable protocols that I’ll discuss in the upcoming section called Standards. There’s a lot of work that goes into implementing these protocols, but Geneva Framework does all of this heavy lifting for you, making it feasible for someone who isn’t an expert in the protocols to get an STS up and running with very little effort.
Geneva Server, one of the products featured in Geneva technologies, is a security token service that you can use instead of building your own STS. You might be wondering what Geneva Server uses for implementing the protocols and building a security token. Yes, you guessed it right, it uses Geneva Framework for all of this heavy lifting.
If you want to build your own STS, Geneva Framework offers all the necessary APIs to make your job easy. It’s up to you to figure out how to implement the logic, or rules that drive it (often referred to as security policy).
Relying Party (RP)
When you build an application that relies on claims, you are building a relying party. Some synonyms that you may have heard are, claims aware application, or claims-based application. Web applications and web services can both be built this way, as you’ll see later in this paper.
Basic Scenario
Now that you’ve learned some basic terminology, here’s an example of a claims-based system in action.
Standards
In order to make all of this interoperable, several WS-* standards are used in the above scenario. Policy is retrieved using HTTP GET and the policy itself is structured according to the WS-Policy specification. The STS exposes endpoints that implement the WS-Trust specification, which describes how to request and receive security tokens. Most STSs today issue SAML tokens (Security Assertion Markup Language). SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way. This adherence to standards means that you can purchase an STS instead of building it yourself. Or, if you end up in a sticky multi-platform situation, this allows you to communicate with an STS on an entirely different platform and achieve single sign-on across all of your applications, regardless of platform. Identity federation also becomes an option, as I’ll explain shortly.
Browser-based Applications
Smart clients aren’t the only ones who can participate in the world of claims-based identity. Browser-based applications (also referred to as passive clients ) can participate as well. Figure 3 shows how this works. The user points her browser at a claims-aware web application (relying party). The web application redirects the browser to the STS so the user can be authenticated.
Identity Federation
When you build claims-aware web applications and services, you decouple yourself from any one user store. All you want to know is that an authority you trust has given you the identity details you need about the user who is using your application. You don’t have to worry about what domain or security realm that user happens to be part of. This makes it a lot easier to federate identity with other platforms or organizations.
Here’s a concrete scenario that will help get your head around this idea. Let’s say a company called Fabrikam is in the business of manufacturing bicycles, and thousands of bike shops around the world carry their bikes. Fabrikam has a website that allows their retailers to get information about bikes, make purchases, and so on.
When a new retailer (Bob) starts a business and wants to sell Fabrikam’s bikes, he contacts Fabrikam, signs some agreements, and tells Fabrikam about his employees: who should be allowed to use Fabrikam’s retailer website, who should be allowed to make purchases, and so on. Fabrikam issues a user name and password for each employee at Bob’s bike shop, and configures its website to grant those users different levels of access depending on their job.
Over time, Bob ends up doing business with lots of other bike manufacturers, each of which has their own proprietary mechanism for purchasing. Some use the web, and some rely on fax and phone calls. It’s easy for Bob to forget about all of these niggling details when he’s doing his best just to sell bikes every day. So when Alice joins as a new employee, it takes Bob awhile to remember that he has to call Fabrikam (and all of the other manufacturers) and let them know that Alice should be allowed to make purchases. Alice’s first few weeks on the job are a bit daunting as she learns all of the passwords she needs to know for the various systems she’ll be using, and she’ll be denied access to Fabrikam’s retailer website until Bob gets around to calling Fabrikam to add Alice as a user. What happens when Alice’s role in Bob’s company changes, or even worse, if she leaves the company entirely? When does Fabrikam find out about this?
What we have here are two companies that have established a trust relationship, a covenant, between one another. Fabrikam relies on Bob to indicate which employees should have access to Fabrikam’s resources, and what level of access each should have. Identity federation is all about automating this covenant. Since Fabrikam already trusts Bob to tell the truth about his employees, it makes sense to let Bob’s system authenticate those employees and automatically give Fabrikam the details about each employee’s current role in the company.
Once Bob is responsible for authenticating his own staff, Fabrikam no longer has to issue user accounts for Bob’s employees. When Alice logs into her computer at Bob’s bike shop, that login can be used to tell Fabrikam who Alice is, and what role she plays in Bob’s organization. If Alice leaves the company, all Bob has to remember to do is disable her user account, and she’ll no longer be able to use Fabrikam’s website, or any other manufacturer’s website that federates with Bob. When Alice changes jobs, and Bob adjusts her group memberships in his directory, Fabrikam discovers that change the next time Alice logs on and uses Fabrikam’s web application. What we have now is single sign-on across organizations, and this is a good thing, not just for developers, but for IT pros, users, and shareholders alike.
Even within a single company, federation can be useful. If you end up with two different implementations, say Java-based and Microsoft .NET-connected, as long as your applications are built to support federated identity, you have a clear path to achieve single sign-on, and all of the benefits it provides.
Identity federation works by introducing a second issuer. Your applications still trust the same STS they used to, and it will continue to issue all of the tokens that your application needs. But now instead of directly authenticating all users directly, your STS will be configured to accept SAML tokens from partner organizations, leaving it to them to authenticate users in their own realm in a way that makes sense.
In Figure 4, the client is in a different security realm over in Bob’s bike shop, while the relying party is still in Fabrikam’s data center. In this case, the client (Alice, say) authenticates with Bob’s STS (1) and gets a security token that she can send to Fabrikam. This token indicates that Alice has been authenticated by Bob’s security infrastructure, and includes claims that specify what roles she plays in Bob’s organization. The client sends this token to Fabrikam’s STS, where it evaluates the claims, decides whether Alice should be allowed to access the relying party in question, and issues a second security token that contains the claims the relying party expects.
The client sends this second token to the relying party(3), which now discovers Alice as a new user, and allows her to access the application according to the claims issued by Fabrikam’s STS.
Note that the relying party didn’t have to concern itself with validating a security token from Bob’s bike shop. Fabrikam’s authority did all of that heavy lifting: making certain to issue security tokens only to trusted partners that have previously established a relationship with Fabrikam. In this example, the relying party will always get tokens from its own STS. If it sees a token from anywhere else, it will reject it outright. This keeps your applications as simple as possible.
Source: Microsoft Geneva Website
http://msdn.microsoft.com/en-us/security/aa570351.aspx
No comments:
Post a Comment