I can’t wait to get on my flight to PDC2008 tomorrow.

Looking over the session times I have some conflicting spots, as I’m targeting the Identity, Cloud Services and ASP.NET tracks.

I’m really looking forward to hooking up with the Identity Teams, so I can build some greater inroads into the solutions Microsoft are offering.

I can’t wait to get my hands on the 160GB HDD with all the conference material, too.

It is going to be a whirlwind journey, as I arrive in LA on the Monday morning then go straight to the conference. Four days of mega-geekiness, finishing on Thursday. Then, on Thursday night, back on the plane for a Saturday arrival.

No rest for the wicked!

The Microsoft Code Name "Zermatt" Beta contains many samples, so I’ve decided to do a walkthrough an interesting one: the Simple STS for Active Clients.

Active Clients use WS-Trust to communicate with their services. For most people, your Active Client will be Windows CardSpace.

The Zermatt documentation specifies that the process for implementing an Active STS:

1. Create a class for your STS, inheriting from the SecurityTokenService class
   1. Override GetScope
   2. Override GetOutputSubjects
2. Create a class for your configuration settings, inheriting from SecurityTokenServiceConfiguration.
3. Instantiate your STS configuration class.
4. Instantiate the WSTrustServiceHost, using the configuration class you just instantiated.

Creation of the STS class

The sample defined MySecurityToken service in the SimpleActiveSTS project, which inherits from the SecurityTokenService class.

Lets take a look at the SecurityTokenService class, we are interested in the methods that are indicated:

Overriding the GetScope Method

In the sample code, we can see the GetScope method is overridden:

   1: protected override Scope GetScope( IClaimsPrincipal principal, RequestSecurityToken request )

   2: {

   3:     // Validate the AppliesTo on the incoming request

   4:     ValidateAppliesTo( request.AppliesTo );

   5:  

   6:     // Create the scope using the request AppliesTo address and the STS signing certificate

   7:     Scope scope = new Scope( request, SecurityTokenServiceConfiguration.SigningCredentials );

   8:  

   9:     // In this sample app only a single RP identity is shown, which is localhost, and the certificate of that RP is 

  10:     // populated as encryptingCreds

  11:     // If you have multiple RPs for the STS you would select the certificate that is specific to 

  12:     // the RP that requests the token and then use that for encryptingCreds

  13:     EncryptingCredentials encryptingCreds = new X509EncryptingCredentials(

  14:                                                 CertificateUtil.GetCertificate(

  15:                                                                 StoreName.My,

  16:                                                                 StoreLocation.LocalMachine,

  17:                                                                 encryptingCertificateName ) );

  18:  

  19:     // Set the RP certificate for encryption

  20:     scope.EncryptingCredentials = encryptingCreds;

  21:  

  22:     return scope;

  23: }

However, this is not essential. The Zermatt documentation states “It is strongly recommended that you also override GetScope to process incoming RequestSecurityToken objects to make policy based decisions and determine any EncryptingCredentials used to encrypt the outgoing issued tokens.”

GetScope calls the ValidateAppliesTo method:

   1: void ValidateAppliesTo( EndpointAddress appliesTo )

   2: {

   3:     if ( appliesTo == null )

   4:     {

   5:         throw new InvalidRequestException( "The appliesTo is null." );

   6:     }

   7:  

   8:     if ( !appliesTo.Uri.Equals( new Uri( addressExpected ) ) )

   9:     {

  10:         Console.WriteLine( "The relying party address is not valid. " );

  11:         throw new InvalidRequestException( String.Format( "The relying party address is not valid. Expected value is {0}, the actual value is {1}.", addressExpected, appliesTo.Uri.AbsoluteUri ) );

  12:     }

  13: }

In the above code snippet you can see that the code ensures that the RST request must come from the sample’s client application. We get these details from the RequestSecurityToken class:

If any other relying party makes the request the STS throws an InvalidRequestException, another Zermatt class:

The Zermatt documentation states for the InvalidRequestException: “Throw this exception when the request was invalid or malformed”.

GetScope forms a Scope object that tells Zermatt to encrypt the data specifically for the requesting relying party. The scope object allows for a few other properties to be set. Unfortunately the Zermatt documentation omits details for the scope class, so I’m not going to go into great detail here.

Overriding the GetOutputSubjects Method

MySecurityTokenService overrides the GetOutputSubjects method as specified by the Zermatt documentation: “When implementing a derived class of SecurityTokenService, you must provide an implementation for GetOutputSubjects.”

Here’s the code for the GetOutputSubjects method:

   1: public override ClaimsIdentityCollection GetOutputSubjects( Scope scope, IClaimsPrincipal principal, RequestSecurityToken request )

   2: {

   3:     IClaimsIdentity callerIdentity = (IClaimsIdentity)principal.Identity;

   4:     Console.WriteLine( "\nRequest from: " + callerIdentity.Name + "\n" );

   5:  

   6:     ClaimsIdentityCollection outputClaimCollection = new ClaimsIdentityCollection();

   7:     IClaimsIdentity outputIdentity = new ClaimsIdentity();

   8:  

   9:     // Create a name claim from the incoming identity.

  10:     Claim nameClaim = new Claim( System.IdentityModel.Claims.ClaimTypes.Name, callerIdentity.Name );

  11:  

  12:     // Create an 'Age' claim with a value of 25. In a real scenario, this may likely be looked up from a database.

  13:     Claim ageClaim = new Claim( "http://ZermattSamples/2008/05/AgeClaim", "25", ClaimValueTypes.Integer );

  14:  

  15:     outputIdentity.Claims.Add( nameClaim );

  16:     Console.WriteLine( "ClaimType  : " + nameClaim.ClaimType );

  17:     Console.WriteLine( "ClaimValue : " + nameClaim.Value );

  18:     Console.WriteLine();

  19:  

  20:     Console.WriteLine( "ClaimType  : " + ageClaim.ClaimType );

  21:     Console.WriteLine( "ClaimValue : " + ageClaim.Value );

  22:     Console.WriteLine( "===========================" );

  23:  

  24:     outputIdentity.Claims.Add( ageClaim );

  25:  

  26:     outputClaimCollection.Add( outputIdentity );

  27:  

  28:     return outputClaimCollection;

  29: }

This code obtains the caller’s identity and writes it to the console, showing the identity of the requestor.

The code then constructs a ClaimsIdentity object, where Claim objects are stored and returned to the requestor. The code creates two claims, one for name and one for age. The method then returns the ClaimsIdentityCollection for Zermatt to respond with.

Concluding Part One

Zermatt provides a very simple method of generating RSTR messages by simply inheriting from the SecureTokenService class and overriding the GetOutputSubjects method.

If you require, you can optionally override the GetScope method, where you have the ability to target the RSTR message, or abort the request completely. The request is aborted using the InvalidRequestException.

I must say that having done some prototyping on the sharpSTS platform I find both offerings to be very compelling. Zermatt certainly has a nice method of consumption, and its greater feature set makes it my preferred option.

In Part Two, I’ll walk through the code that hosts the service and then the client.

Please provide me feedback: Too many class diagrams, too much code, not enough text? I’m trying to hit the nuts and bolts level of Zermatt.

As I've been upgrading the CardSpace Authentication Provider for DotNetNuke to use Zermatt as its core I've found that you still need to run your ASP.NET application in full trust.

This is a disadvantage for systems that have a target market of shared hosting providers, as many providers will not grant the elevated privilege. DotNetNuke as a bare platform has been able to run in medium trust environments for some time.

In the CardSpace Authentication Provider for DotNetNuke we use some code to determine whether the application is running in full trust:

   1:          public override bool Enabled

   2:          {

   3:              get 

   4:              {

   5:                  try

   6:                  {

   7:                      // Make sure we are running in full trust.

   8:                      new AspNetHostingPermission(AspNetHostingPermissionLevel.Unrestricted).Demand();

   9:   

  10:                      // Return whether the user has enabled CardSpace.

  11:                      return Config.GetConfig(PortalId).Enabled;

  12:                  }

  13:                  catch (System.Security.SecurityException)

  14:                  {

  15:                      // The app isn't running in full trust so return false to disable CardSpace.

  16:                      return false;

  17:                  }

  18:              }

  19:          }

I've submitted feedback to Vittorio Bertocci about my recommendations, and I hope this is solved in the near future.

(Microsoft, thanks you so much for Zermatt. It'll let us Identity Metasystem freaks move off your sample TokenProcessor classes! woo hoo!)

After being revitalised by Tech.Ed in Sydney, I've decided to revamp my blog and bring down my old DotNetNuke web site. I've just evaluated WordPress and Live Spaces, and Live seems to suit my style a little more.

This isn't a sign that I'm moving away from DotNetNuke, I'm still committed to supporting it in my professional career. The main reason is that I've had my own virtual server in the cloud running my site, and I want to reduce my costs.

Over the next week weeks I'm going to start blogging about my experiences with Zermatt, as I create a secure token server for DotNetNuke. This will also kick off the upgrade of the CardSpace Authentication Provider for DotNetNuke to support managed cards. If I can convince the DotNetNuke core team so publish my STS we may see that all the other DotNetNuke sites gain easy access to the 600 thousand registered users on the DotNetNuke web site.

I have been speaking with the guys on the AJAX Control Toolkit and they have requested that I get the control onto CodePlex.

So, here it is: http://www.codeplex.com/CardSpaceAjax