This is the fourth post in a series about claims based identity management and the Windows Identity Foundation (WIF).
The first three were:
- Alice in Claims: decentralized identity
- Alice in Claims: the claims model
- Alice in Claims: protocols
The previous post presented the protocols for requesting and exchanging security tokens between identity providers and identity consumers. In this post, we dissect the structure of a commonly used token type: SAML assertions.
A SAML assertion
The following excerpt shows the high-level structure of a SAML 2.0 assertion.
- The top-level element is the Assertion element.
- The Assertion/Issuer element defines the token issuer’s identity, in the form of an URL.
- The Assertion/ds:Signature contains a signature computed over the assertion contents.
- The Assertion/Subject contains information regarding the assertion’s subject, i. e., to whom or what do the contained claims apply. This information is carried in the SubjectConfirmation element, which in this case states that this token is a bearer token: the token subject is anyone in possession of the token.
- The Assertion/Condition define the conditions for token acceptance by a consumer, which in this case are:
- Time period (NotBefore and NotOnOrAfter attributes)
- Consumer identity (AudienceRestriction element). Any consumer that does not match any of the audience restriction URLs should not accept the token.
- Finally, the Assertion/AttributeStatement and Assertion/AuthnStatement contains the issued claims, which will be detailed next.
The following XML excerpt shows the AttributeStatement contents, defining the issued claims:
- One name claim (type = “http://…/name”) with value “Alice”
- Two role claims (type = “http://…/role”) with values “Developer” and “LeadDeveloper”.
Finally, the next XML fragment shows the AuthnStatement element containing the authentication type claim, also called authentication context. In this example, Alice used a password based mechanism to authenticate herself when requesting the claims from the identity provider.
For completeness, the next XML fragment presents the signature contents.
- The Signature/Element defines the signed data, which is this case is the complete SAML Assertion. Note that the URI attribute matches the ID attribute in the Assertion element. Since the signature is inside the signed data, an “enveloped-signature” transform is used.
- The Signature/KeyInfo/X509Data/X509Certificate contains the issuer’s certificate. There are several WIF configuration aspects that relate to this certificate, so its existence should be noted.
This is the third post of a series about claims based identity management and the Windows Identity Foundation (WIF).
The first two were:
The previous post presented the claims model, namely concepts such as identity provider, identity consumer, claims and security tokens. In this one, we will describe some of the protocols available for the communication between providers and consumers, namely for requesting security tokens and exchanging them.
- The protocol begins by Alice’s browser making the initial HTTP request to the web app.
- Since this request does not contain any identity information, the response is a redirect to the IdP. Alice’s browser fulfills this redirect by sending a GET request to the IdP. The redirect target URL contains information contextualizing the request, namely the identity of the requesting web app.
- After this request, typically there is an interaction between the IdP and Alice’s browser with the purpose of authenticating the user. For example, the IdP may respond with an HTML form for username+password authentication, which is followed by a POST containing this information, sent by Alice’s browser. This interaction may also include a step where the IdP and Alice agree on the issued claims, which is useful when Alice wants some control over releasing parts of her identity.
- Finally, the IdP responds with a security token containing the issued claims. This response may be:
- A redirect to the web app, with the token encoded in the target URL, or
- An auto submitting HTML form, containing the token in an hidden field. The form’s target is the web app.
In the active protocols, the user-agent plays an active role in the protocols.
- The protocol starts by the user agent directly requesting a token from the IdP. This request must contain all the information required for the IdP to authenticate the requesting user and determine the claims to issue.
- Next, the IdP responds with the issued token.
- Finally, the user agent sends the request to the Identity Consumer (typically a service), with the token attached.
The WS-Trust is an example of an active protocols based using the SOAP and WS-* specifications.
In the next post we will show some examples of security tokens, namely the SAML assertion format.
This is the second post of a series about claims based identity management and the Windows Identity Foundation (WIF).
The first one presented a scenario with decentralized identity authority. This posts uses this scenario to introduce the claims based model.
The following figure serves two goals:
· It presents the main claims model concepts, and
· Concretizes this concepts in the presented scenario
Claims model concepts
- Identity is represented by a set of claims, where a claim is a declaration made by an entity. In this scenario, Alice, LeadDev, IssueMgr and IssueView are examples of claims that represent’s Alice’s identity.
- An Identity Provider (or Issuer) is an entity that issues identity claims, typically containing information for which it is authoritative. In this scenario, WeDev is the identity provider, and it issues name and role claims (e.g Alice and IssueMgr).
- An Identity Consumer (or Relying Party) is an entity that uses (consumes, relies on) identity claims. In the above example, the consumer is CloudTrack, which uses the consumed claims to make the authorization decisions..
- A Security Token is a set of claims securely packaged for transportation between participants. This packaging ensures properties such as
- Privacy: only the authorized receiver of the token is able to access the contained claims. This typically is obtained by encrypting the token to the authorized receiver.
- Claim integrity and issuer authentication: the token receiver is able to determine the original claims producer. Usually, this property is achieved by the issuer digitally signing the token.
- Subject authentication and proof of possession: the token receiver is able to determine who is the subject of the claims. The two more common proof of possession methods are
- Bearer – any entity who has the token can allege that it is the claims subject. This is similar to bearer checks or bus tickets.
- Holder of key – the claims subject is any entity who proves possession of a related key (e.g. by signing the message where the token is attached).
The “Proposal for a Common Identity Framework: A User-Centric Identity Metasystem” contains an interesting taxonomy of claims
- Claims are divided between primordial and substantive
- Primordial (or primitive) claims are proofs presentable by only one subject
- Substantive claims are claims produced by claims providers, typically after the subject presenting a primordial or other substantive claim.
- Substantive claims are further subdivided in
- Static – properties of the subject (e.g. National Identifier Number; Date-of-Birth)
- Derived – derived from other claims (e.g. Portuguese Citizen; Over-18)
- Membership – role or group membership, relation with other subject (e.g. Administrator; Lead Developer; Purchase Officer)
- Capability – authorization to something (e.g. Can-emit-purchase-order; Can-admin-CI-server)
- Contextual – information about the context (e.g. Authentication method, location and time)
A Claims Transformer is an entity or module that produces claims based on claims that it receives (consumes).
For instance, in above scenario, the WeDev identity provider can also be seen as a claims transformer since it produces the name and role claims (substantive claims) upon receiving and validating Alice’s credentials (primordial claims).
We also can see the CloudTrack’s web app as divided in to two modules:
- The first module is a claims transformer, transforming the input role claims (LeadDev) into application specific roles (IssueMgr) and authorization roles (IssueView).
- The second module is an identity consumer, using the input authorization claims (IssueView) to decide if the access is allowed or not.
Notice that the claims exchange between these two modules doesn’t have to use a token, since no unprotected communication channel is used.
In the next post, we will present some of the protocols that are used for requesting and communicating claims and tokens.