Service Provider, Relying Party, Identity Provider, Signature, Key-Exchange, Certificate, Token, Claim, Proxy...
Yes, these abstract terms are the lingo to describe the applications and elements involved in Claims Authentication and Authorisation.
Why claims?.. Claims help us reduce the overheads of identity management by providing a central point for user and role administration (Single Sign On). This administration can be shipped to a 3rd party (Facebook, Google and Microsoft) or simplify the centralisation of user provision in the enterprise. Claims is especially important for the web as it enables this process to happen over physical organisational boundaries. This is very relevant, especially as our corporate applications are stretched into the cloud.
To help demystify these terms you need to understand the holistic picture. Claims is, in simple terms an access control mechanism which relies on a 3rd party to provide your application with user access control (authentication) and (potentially) roles (authorisation - claims).
The terms are somewhat obtuse to their use and here is where I attempt to debunk the myths..
Service Provider and Relying Party (Microsoft) are one of the same.. It is *your * 3rd party application. The consumer of the claim (Identity).
Identity Provider (IDP), is where you want to login (authenticate) and receive claims (roles, attributes). This is someone who has a token service (STS) wrapped around the login mechanism.
Tokens?? No, not a buy one get one free. A token is an exchanged set of data in a specific format which occurs from the identity provider and *your* application after authentication. This token may include claims (roles, attributes) and is digitally signed (secure). The most common form of token for federated claims is SAML, a SAML token is the response to an authentication request. SAML is usually wrapped around a protocol such as WS-Trust or WS-Federation.
A claims process starts from one of 2 methods... The first via direct URL browsing to the source site (and subsequent STS redirection), the other to the identity provider proxy address. Once an endpoint is reached, the authentication process starts, this can equate to several browser level redirects (as the IDP is reached) and ultimately a login dialogue from the IDP STS. Once authenticated, the STS will generate a signed token using the public key provided as part of the trusted key-exchange.
Keys - Cryptographic keys are a fundamental part of the claims architecture. In order for applications to secure the process a trust must be established. This is usually achieved by the provision and configuration of cryptographic keys. With these keys exchanged and configured at the STS the digital signature of the token can be reliably validated.
Once you've shared keys, configured endpoints and managed to get the access control mechanism working you should have reliable receipt of claims. So how do you bake this into your application?
There are several online claims based Frameworks and depending on your architectural requirements will depend on choice. Two of the most common in the .NET space are Windows Identity Foundation and DotNetOpenAuth. WIF is more aligned to the MS LDAP ADFS mechanisms and DotNetOpenAuth makes use of OpenID to provide authentication.
Claims is only complex due to the abstract language used to provide a description to terms you've used for years.. The redirection process is somewhat cumbersome and difficult to grasp especially chained trusts, but do not confuse the fact that, at the end of the day your users are receiving authentication and roles from a central place for all applications.
In my next post I will provide a tutorial for configuring ADFS with a WIF enabled application. I will also map custom attributes into the token to ensure backwards compatibility for existing applications moving to an single sign on architecture.