MSDN Magazine - January 2009 - (Page 72)

Joe authentication, Forms authentication, and Windows CardSpace authentication. In the case of Windows authentication, the following configuration is used: Client 4 Delete( ) 3 1 UserName Token RP IP-STS Service Name=Joe Role=Administrators Action=Create Action=Read 2 Action=Update Action=Delete Identity = Joe Name=Joe The user will be authenticated through interactive dialogs prior to reaching the default page of the STS, so a custom login page is not required in this case. Figure 11 illustrates an example whereby Forms authentication is used. The FormsAuthenticationModule redirects unauthenticated calls to the login page where the user can supply credentials. Once authenticated, the login page will redirect to the default STS page where the federation control will proceed to process the original request. The ASP.NET configuration for this would be as follows: Policy Engine Figure 12 Claims Transformation at the IP-STS In the case of Windows CardSpace authentication, the STS site can be configured for Forms authentication, but the login page will include an InformationCard control for Windows CardSpace authentication. Claims Transformation interact with initialization, security token management, sign in, and sign out: ConfigurationLoading, ConfigurationLoaded, SecurityTokenReceived, SecurityTokenValidated, SessionSecurityTokenCreated, SessionSecurityTokenReceived, SignedIn, SigningOut, SignedOut, SignInError, and SignOutError. User Authentication Claims transformation is essential to federated security—and this can happen at a variety of points in the flow of federation. In a simple federation scenario where the IP-STS and RP belong to the same domain, the IP-STS is responsible for transforming claims from the initial set of identity claims that the user presents during authentication, to those that the RP can rely on to authorize calls. Users can present any of the supported credential types to authenticate to the The STS site is responsible for authenticating users Joe according to supported creClient dential types. While an active STS implemented with WCF can easily configure multiple endpoints to support different authentication mechanisms, a passive STS can only 4 support one authentication 5 DeleteOrder( ) mechanism by nature of the ASP.NET Web site configuraRP-STS RP tion. Thus, a different passive STS site must be provided for 7 Action=Delete each supported authentication Identity = Joe Name=Joe mechanism. These sites can all 6 share the same core STS implementation, of course. Policy Passive STS authenticaEngine tion is based on ASP.NET configuration techniques. Typical choices are Windows Figure 13 Claims Transformation at the RP-STS 72 msdn magazine 3 1 UserName Token IP-STS Name=Joe UPN=1000 Identity = Joe Name=Joe 2 Policy Engine 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.