MSDN Magazine - January 2009 - (Page 65)

• Facilitating identity delegation Client scenarios where the authenticated user is granted access to downstream services. RST RSTR • Facilitating claims transformation so that relevant claims are RequestType = Issue Lifetime available for authorization at apRequestedProofToken plications and services. AppliesTo = /RelyingParty Any of these scenarios can Proof Key TokenType = SAML1.1 be based on passive federation (browser-based) or active federaRequestedSecurityToken Claims = name, role tion (Windows client-based). Next, SAML1.1 Token WS-Trust/ I will elaborate on these scenarios Signature Issue ( ) while describing how to build relSubject Con rmation evant logic into a custom STS built Active STS with the Geneva Framework. Token Lifetime Before diving into the implementation of an STS, let me first review Attributes (Claims = name, role) some fundamentals. An STS used Proof Key in active federation is an implementation of the WS-Federation Active Requestor Profile (see WS-Federation TC at www.oasis-open.org/com- Figure 1 Token Issuance for an Active Federation Scenario mittees/tc_home.php?wg_abbrev=wsfed) and (primarily) the WS-Trust specification (see WS-Trust 1.3 at docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html). From a high level, WS-Trust describes a contract with four service operations: Issue, Validate, Renew, and Cancel. Respectively, these operations are called by clients to request a security token, to validate a security token, to renew an expired security token, or to cancel a security token that should no longer be used. Each operation is sent messages in the form of Request for Security Token (RST) and return messages in the form of RST Response (RSTR) according to the WS-Trust specification. For this article I am assuming that Browser the issued token is a Security Assertion Markup Language (SAML) 1.1 or SAML 2.0 token. Figure 1 illustrates the core contents of the RST and RSTR RSTR HTTP GET for active token issuance. The RST wa=wsignin1.0 RequestedSecurityToken wctx=[context] message includes necessary inforHTTP POST wreq=[tokentype] SAML1.1 Token wctx=[context] mation to request a security token wresult=RSTR Signature including the type of token to isPassive RP Passive STS sue (SAML for this discussion), the Subject Con rmation claims requested by the relying parToken Lifetime ty (RP) to be included in the issued RST RSTR token, the information about the Attributes (Claims = name, role) RP (AppliesTo) including the URL Active STS and usually the certificate identifying the RP, and optionally (not shown) key material to be used for the proof-of-possession key (proof key) returned with the RSTR. Figure 2 Token Issuance for a Passive Federation Scenario msdnmagazine.com If token issuance is successful, the RSTR will include the issued SAML token and the proof key (assuming the STS decides which proof key to use and thus must return it in the RSTR). The SAML token will include relevant claims for the authenticated party, is signed by the STS to protect the token from being tampered with, contains the proof key encrypted for the RP, and is itself encrypted for the RP so that only the intended recipient can process the token. The client uses the proof key to sign the message to the RP. The January 2009 65 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.