MSDN Magazine - January 2009 - (Page 66)

Windows Client Proxy 3 Authenticate/ Authorize 2 Issue Token 1 Authenticate ken with a subject confirmation of type “bearer” (it is also known as a bearer token). This type of token does not include a proof key and is sometimes called a keyless token. It relies on the transport to securely procure it from the STS and transmit it to the RP. These concepts—WS-Federation, WS-Trust, and SAML tokens— are important background information for the discussion that follows. First, I will describe how to build an active STS using the Geneva Framework. Following that, I’ll discuss building a passive STS, and finally I’ll present some extended scenarios for each. RP Service Trust IP-STS Service Building a Custom Active STS Figure 3 A Simple Federation Scenario with a Single RP and an Active IP-STS ure 3, the following participants are usually present: In a simple active federation scenario, such as that shown in Fig- RP must be able to decrypt the proof key inside the SAML token or reject the message. If the proof key inside the token matches the signature on the message, this proves that the call to the RP was sent by the party that requested the token. Passive federation scenarios are based on a WS-Federation Passive Requestor Profile, which involves browser-based communication. The underlying messaging is still based on WS-Trust; however, the RST is broken into query string parameters on the STS URL, and the RSTR is typically posted to the RP as a form parameter. The passive STS and RP intercept these parameters with federation Web handlers. The passive STS may process WS-Trust requests directly or pass them to an underlying WS-Trust implementation. Figure 2 illustrates how the RST and RSTR are handled in a passive federation scenario. One relevant difference between the active and passive federation scenarios is the type of SAML token issued. Active federation usually relies on a SAML token that uses a subject confirmation of type “holder-of-key,” which means that there is a proof key used as I have described to prove that the client sending the token to authenticate is the subject that requested the token (also known as ActAs behavior). Passive federation scenarios usually involve a SAML toApp.con g • An RP, which is the service called by a client. • A single STS, also implemented as a service, which supports the WS-Trust protocol. This STS authenticates callers and issues a security token with claims identifying the caller, also known as an Identity Provider or IP-STS. • A client, in this case a Windows-based application, that relies on a proxy to authenticate to the STS, to retrieve the resulting issued token, and to send messages to the RP supplying the issued token for authentication and authorization. Figure 4 illustrates the moving parts behind this implementation. Included are a custom SecurityTokenService implementation, the use of a ServiceHost extension (WSTrustServiceHost) to initialize the runtime for federation, configuration of one or more WSTrust endpoints using a derivative of the WSTrustContract type, and other related configuration settings for the identity model runtime. In the sections that are to follow, I will review each one of these elements of a custom STS implementation based on the Geneva Framework. Extending SecurityTokenService The Geneva Framework provides the core functionality to build a custom STS through the SecurityTokenService type from the Microsoft.IdentityModel.SecurityTokenService namespace. This abstract class handles the heavy lifting of processing RST and IWSTrust13SyncContract WSTrustServiceHost IWSTrustFeb2005SyncContract WSTrustContract CustomSTS CustomSecurityToken ServiceCon guration IWSTrust13SyncContract IWSTrustFeb2005SyncContract Issue( ) Validate( ) Renew( ) Cancel( ) SecurityToken ServiceCon guration SecurityTokenService Figure 4 Implementation Architecture for a Custom Active STS and an Active IP-STS 66 msdn magazine Geneva Framework

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.