MSDN Magazine - January 2009 - (Page 67)

Figure 5 A Simple Custom STS Implementation public class IdentitySTS : SecurityTokenService { public IdentitySTS(SecurityTokenServiceConfiguration config) : base( config ) { } protected override IClaimsIdentity GetOutputClaimsIdentity( IClaimsPrincipal principal, RequestSecurityToken request, Scope scope) { IClaimsIdentity claimsIdentity = new ClaimsIdentity(); claimsIdentity.Claims.Add(new Claim(ClaimTypes.Name, principal.Identity.Name)); claimsIdentity.Claims.Add(new Claim(ClaimTypes.Role, "Users")); } return claimsIdentity; } return scope; private X509EncryptingCredentials GetCredentialsForAppliesTo(Endpoint Address appliesTo) { if (appliesTo == null || appliesTo.Uri ==null || string.IsNullOrEmpty(appliesTo.Uri.AbsolutePath)) { throw new InvalidRequestException( "AppliesTo must be supplied in the RST."); } X509EncryptingCredentials creds = null; if (appliesTo.Uri.AbsoluteUri.StartsWith( "http://localhost:8000/RelyingPartyService")) { creds = new X509EncryptingCredentials( CertificateUtil.GetCertificate(StoreName.TrustedPeople, StoreLocation.LocalMachine, "CN=RPKey")); } else throw new InvalidRequestException(String.Format( "Invalid relying party address: {0}", appliesTo.Uri.AbsoluteUri)); } return creds; protected override Scope GetScope( Microsoft.IdentityModel.Claims.IClaimsPrincipal principal, RequestSecurityToken request) { Scope scope = new Scope(request); scope.EncryptingCredentials = this.GetCredentialsForAppliesTo( request.AppliesTo); scope.SigningCredentials = new X509SigningCredentials(CertificateUtil.GetCertificate(StoreName.My, StoreLocation.LocalMachine, "CN=IPKey")); } RSTR messages and generating security tokens. A custom STS type inherits this class and provides (at a minimum) the following functionality: • A constructor that accepts a custom SecurityTokenServiceConfiguration instance to configure some basic features of the STS (to be discussed later). • An override for GetScope to validate the target RP for the request and to supply an appropriate encrypting credential for that RP and a signing credential for the security token. • An override for GetOutputClaimsIdentity to supply claims for the resulting security token. Figure 5 shows some code for a simple custom STS implementation with this functionality. Recall the flow of communication for an active STS from Figures 1 and 2. The STS implementation, IdentitySTS, validates the incoming RST when GetScope is called— by verifying that the AppliesTo element of the RST indeed points to a trusted URI. Presumably the STS manages a list of trusted RPs for which tokens can be issued, along with their certificates. GetScope sets the EncryptingCredentials property of the scope to the appropriate certificate if AppliesTo passes validation, in this case “RPKey”. In addition, the SigningCredentials property is set to the appropriate certificate to be used for signing the issued token. This is usually the private key of the STS, in this case “IPKey”. When GetOutputClaimsIdentity is called, a ClaimsPrincipal is passed by the runtime with the authenticated caller’s identity. This identity is typically used to determine the appropriate claims to grant the caller. In Figure 5 the code generates a name claim and a hardcoded role claim for the caller, and it returns this in the form of a ClaimsIdentity. This ClaimsIdentity supplies claims to the runtime for the token to be issued. msdnmagazine.com This STS implementation could also be extended with the following functionality: • GetOutputClaimsIdentity could include code for looking up the user in a custom credential store and look up additional claims. For example, a list of roles, other relevant details about the user such as her e-mail address, or custom claims representing more granular application rights such as create, read, update, or delete. • GetScope could look up the AppliesTo URI in a custom database that lists all trusted RPs with their associated certificates. Hosting and Configuring the STS If you are familiar with WCF, you know that one or more endpoints must be configured in order for clients to send messages to a service. In the case of an STS, the service contract to be used for each endpoint must be based on WS-Trust protocol, which includes four operations: Issue, Validate, Renew, and Cancel. In fact, there are two versions of WS-Trust protocol that could be implemented by an STS: • WS-Trust 1.3: the latest version of the WS-Trust spec. • WS-Trust February 2005: the version of WS-Trust that many industry partners implemented while waiting on the standard to be ratified. You can also provide asynchronous implementations for GetScope(), GetOutputClaimsIdentity()—among other methods—in your SecurityTokenService type. This improves scalability for I/O intensive operations such as accessing certificates or interacting with claims data. When you configure endpoints for your STS, you must select which contract to expose for the endpoint. The Microsoft.IdentityModel.Protocols namespace includes these two January 2009 67 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.