A while back I wrote about UserName supporting tokens in WCF and how they can be handy to create light-weight “delegation” scenarios for middle-tiers. I wanted to give the same scenario a try with a Geneva enabled relying party.

First of all – there are no basic configuration changes necessary (specifically the SecurityBindingElement – refer to my original post for details). All you have to do is to configure the Geneva “runtime” and wire it in your service host. This involves:

• Specifying an issuer registry for the client’s certificate.
• Add a UserNameSecurityTokenHandler that can cope with empty passwords (this also gives you the chance to add some custom claims for the user name token).

Refer to this post for details about issuer registries, and this post for UserName security token handlers.

All you then have to do is, to take all these pieces and configure the service host to use Geneva:

ServiceHost host = new ServiceHost(typeof(Service));

// add the supporting token to the binding
host.Description.Endpoints[0].Binding =

    AddUserNameSupportingTokenToBinding(host.Description.Endpoints[0].Binding);

// create security token handlers
var handlers = new SecurityTokenHandlerCollection(
    SecurityTokenHandlerCollection.DefaultHandlers);

// add handler for supporting token (empty password)
handlers.AddOrReplace(new SupportingUserNameSecurityTokenHandler());

// add the issuer name registry (simple for demo purposes)
var registry = new SimpleIssuerNameRegistry();

// configure host to use Geneva plumbing
FederatedServiceCredentials.ConfigureServiceHost(
    host,
    handlers,
    registry,
    new TimeSpan(0, 5, 0));

host.Open();

On incoming requests, Geneva will now create an IClaimsPrincipal that contains two IClaimsIdentity instances. One for the direct caller (certificate) and one for the supporting token (user name). You can now use the standard means to query both identities and their claims. Nice.

SupportingUserNameToken1.zip (39.91 KB)