Overview

The M2 milestone of the Stonehenge StockTrader Sample Application introduced a set of implementations that utilized claims-based authorization and federated identity. As a component in the sample, the Passive Security Token Service (STS) provides support for federated identity and claims-based authentication.

Explanation

A classic analogy for claims authorization is how one might use a driver's license for identification. A driver's license is like a token containing a set of claims, signed by the issuing government (which is like a Security Token Service). One such claim would be the license holder's birth date. From this claim one can deduce the license holder's age. Further, from this claim an authorization rule can be evaluated that would determine whether or not the license holder is permitted to consume an alcoholic beverage.

The claim's source (the government in the analogy) must be trusted by the Relying Party (beverage seller) in order for the claim to be considered valid and usable. Additionally the Relying Party has in mind a certain claim or set of claims that are required in order for authorization rules to be evaluated.

Implementation

The Passive STS is a web application relied upon by the StockTrader Client, the Relying Party (RP), to authenticate a user through a common log-in form. Whenever the user accesses the account-specific pages within the StockTrader Client for the first time, (s)he will be redirected to a log-in form presented by the Passive STS. Once the user successfully logs in with a username and password, the Passive STS causes the user's browser to send a POST request containing a Request for Security Token Response (RSTR) message back to the StockTrader Client. This RSTR message contains claims about the user signed by the Passive STS in the form of a SAML 1.1 token.

The StockTrader Client can then evaluate these claims for authorization purposes, or pass on these claims for another service to do the same. In the case of the StockTrader Sample, this token will be passed to the Active STS to be translated into a new claims set expected by the Business Service.

Claims Provided by the .NET Passive STS

Claim Type

Claim Value

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

username@stonehenge.com

http://microsoft/role

staff

http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant

Timestamp in the format yyyy-MM-ddTHH:mm:ss.fffZ

http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod

http://microsoft/geneva

  • No labels