www.leastprivilege.com

WIF, ASP.NET 4.0 and Request Validation

Your DisplayName here! — Sat, 24 Jul 2010 08:14:36 GMT

Since the response of a WS-Federation sign-in request contains XML, the ASP.NET built-in request validation will trigger an exception. To solve this, request validation needs to be turned off for pages receiving such a response message.

Starting with ASP.NET 4.0 you can plug in your own request validation logic. This allows letting WS-Federation messages through, while applying all standard request validation to all other requests. The WIF SDK (v4) contains a sample validator that does exactly that:

public class WSFedRequestValidator : RequestValidator
{

    protected override bool IsValidRequestString(
      HttpContext context,
      string value,
      RequestValidationSource requestValidationSource,
      string collectionKey,
      out int validationFailureIndex)
    {
        validationFailureIndex = 0;

        if ( requestValidationSource == RequestValidationSource.Form &&
             collectionKey.Equals(
               WSFederationConstants.Parameters.Result,
               StringComparison.Ordinal ) )
        {
            SignInResponseMessage message =
              WSFederationMessage.CreateFromFormPost(context.Request)
               as SignInResponseMessage;

            if (message != null)
            {
                return true;
            }
        }

        return base.IsValidRequestString(
          context,
          value,
          requestValidationSource,
          collectionKey,
          out validationFailureIndex );
    }
}

StarterSTS v1.2

Your DisplayName here! — Thu, 22 Jul 2010 09:23:30 GMT

I just uploaded version 1.2 of StarterSTS. This is simply a conversion of v1.1 to a web application project. Some people have asked for it so here we go.

This version is still compiled against .NET 3.5 SP1 – but this will the last release. All upcoming releases will be .NET 4.0.

Codeplex Site

IIS & RESTful Services #FAIL

Your DisplayName here! — Wed, 21 Jul 2010 20:39:18 GMT

really? when will super duper IIS finally support non-Windows accounts for HTTP authentication?

http://blogs.msdn.com/b/astoriateam/archive/2010/07/21/odata-and-authentication-part-6-custom-basic-authentication.aspx

see here for a complete module including IIS management integration:

http://custombasicauth.codeplex.com

Re-MVP’d 2010

Your DisplayName here! — Tue, 20 Jul 2010 05:33:43 GMT

As always: thank you Microsoft!

Modifying the SL/WIF Integration Bits to support Issued Token Credentials

Your DisplayName here! — Tue, 22 Jun 2010 06:45:17 GMT

The SL/WIF integration code that ships with the Identity Training Kit only supports Windows and UserName credentials to request tokens from an STS. This is fine for simple single STS scenarios (like a single IdP). But the more common pattern for claims/token based systems is to split the STS roles into an IdP and a Resource STS (or whatever you wanna call it).

In this case, the 2nd leg requires to present the issued token from the 1st leg – this is not directly supported by the bits. But they can be easily modified to accomplish this.

The Credential
Fist we need a class that represents an issued token credential. Here we store the RSTR that got returned from the client to IdP request:

public class IssuedTokenCredentials : IRequestCredentials


{

    public string IssuedToken
{ get; set; }

    public RequestSecurityTokenResponse RSTR
{ get; set; }



    public IssuedTokenCredentials(RequestSecurityTokenResponse rstr)

    {

        RSTR = rstr;

        IssuedToken = rstr.RequestedSecurityToken.RawToken;

    }

}

The Binding
Next we need a binding to be used with issued token credential requests. This assumes you have an STS endpoint for mixed mode security with SecureConversation turned off.

public class WSTrustBindingIssuedTokenMixed : WSTrustBinding


{

    public WSTrustBindingIssuedTokenMixed()

    {

        this.Elements.Add( new HttpsTransportBindingElement()
);

    }

}

WSTrustClient
The last step is to make some modifications to WSTrustClient to make it issued token aware. In the constructor you have to check for the credential type, and if it is an issued token, store it away.

private RequestSecurityTokenResponse _rstr;

public WSTrustClient( Binding binding, EndpointAddress remoteAddress, 


IRequestCredentials credentials )

    : base( binding, remoteAddress
)

{

    if ( null ==
credentials )

    {

        throw new ArgumentNullException( "credentials" );

    }



    if (credentials is UsernameCredentials)

    {

        UsernameCredentials usernname
= credentials as UsernameCredentials;

        base.ChannelFactory.Credentials.UserName.UserName
= usernname.Username;

        base.ChannelFactory.Credentials.UserName.Password
= usernname.Password;

    }

    else if (credentials is IssuedTokenCredentials)

    {

        var issuedToken
= credentials as IssuedTokenCredentials;

        _rstr = issuedToken.RSTR;

    }

    else if (credentials is WindowsCredentials)

    { }

    else


    {

        throw new ArgumentOutOfRangeException("credentials", "type
was not expected");

    }

}

Next – when WSTrustClient constructs the RST message to the STS, the issued token header must be embedded when needed:

private Message BuildRequestAsMessage( RequestSecurityToken request
)

{

    var message = Message.CreateMessage( 


base.Endpoint.Binding.MessageVersion ?? MessageVersion.Default,

      IssueAction,

      (BodyWriter) new WSTrustRequestBodyWriter(
request ) );



    if (_rstr != null)

    {

        message.Headers.Add(new IssuedTokenHeader(_rstr));

    }



    return message;

}

HTH

StarterSTS 1.1

Your DisplayName here! — Thu, 10 Jun 2010 08:07:49 GMT

Earlier today I uploaded StarterSTS 1.1 and StarterRP 1.1 to codeplex.

I added identity delegation for internal as well as OpenID accounts and also updated StarterRP to show these features.

I also recorded an updated screencast on delegation since some of the config settings have changed since the CTP.

Video of Moxie Marlinspike’s “More Tricks for Defeating SSL” talk

Your DisplayName here! — Thu, 27 May 2010 10:59:05 GMT

http://www.mefeedia.com/watch/26711228

Updated StarterSTS Documentation & Identity Delegation Screencast

Your DisplayName here! — Wed, 26 May 2010 07:42:59 GMT

I recorded a short screencast describing the identity delegation feature in StarterSTS 1.1. You can watch it here.

I also uploaded an updated version of the documentation here.

StarterSTS 1.1 CTP – ActAs Support

Your DisplayName here! — Mon, 24 May 2010 12:05:19 GMT

Due to popular demand, I added identity delegation (aka ActAs) support to StarterSTS.

To give this feature a try, first download the new bits and add a enableActAs = true to startersts.config. You then have to configure which user account is allowed to delegate, as well as the target realm to delegate to. This is done in usermappings.config, e.g.:

Please use the forum for any feedback. thanks!

A more elegant way of embedding a SOAP security header in Silverlight 4

Your DisplayName here! — Fri, 14 May 2010 05:01:54 GMT

The current situation with Silverlight is, that there is no support for the WCF federation binding. This means that all security token related interactions have to be done manually.

Requesting the token from an STS is not really the bad part, sending it along with outgoing SOAP messages is what’s a little annoying. So far you had to wrap all calls on the channel in an OperationContextScope wrapping an IContextChannel. This “programming model” was a little disruptive (in addition to all the async stuff that you are forced to do).

It seems that starting with SL4 there is more support for traditional WCF extensibility points – especially IEndpointBehavior, IClientMessageInspector. I never read somewhere that these are new features in SL4 – but I am pretty sure they did not exist in SL3.

With the above mentioned interfaces at my disposal, I thought I have another go at embedding a security header – and yeah – I managed to make the code much prettier (and much less bizarre). Here’s the code for the behavior/inspector:

public class IssuedTokenHeaderInspector : IClientMessageInspector
{
    RequestSecurityTokenResponse _rstr;

    public IssuedTokenHeaderInspector(RequestSecurityTokenResponse rstr)
    {
        _rstr = rstr;
    }

    public void AfterReceiveReply(ref Message reply, object correlationState)
    { }

    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        request.Headers.Add(new IssuedTokenHeader(_rstr));

        return null;
    }
}

public class IssuedTokenHeaderBehavior : IEndpointBehavior
{
    RequestSecurityTokenResponse _rstr;

    public IssuedTokenHeaderBehavior(RequestSecurityTokenResponse rstr)
    {
        if (rstr == null)
        {
            throw new ArgumentNullException();
        }

        _rstr = rstr;
    }

    public void ApplyClientBehavior(
      ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        clientRuntime.MessageInspectors.Add(new IssuedTokenHeaderInspector(_rstr));
    }

    // rest omitted
}

This allows to set up a proxy with an issued token header and you don’t have to worry anymore with embedding the header manually with every call:

var client = GetWSTrustClient();

var rst = new RequestSecurityToken(WSTrust13Constants.KeyTypes.Symmetric)
{
    AppliesTo = new EndpointAddress("https://rp/")
};

client.IssueCompleted += (s, args) =>
{
    _proxy = new StarterServiceContractClient();
    _proxy.Endpoint.Behaviors.Add(new IssuedTokenHeaderBehavior(args.Result));

};

client.IssueAsync(rst);

Since SL4 also support the IExtension<T> interface, you can also combine this with Nicholas Allen’s AutoHeaderExtension.

Thinktecture.IdentityModel: WRAP and SWT Support

Your DisplayName here! — Sun, 09 May 2010 20:27:46 GMT

The latest drop of Thinktecture.IdentityModel contains some helpers for the Web Resource Authorization Protocol (WRAP) and Simple Web Tokens (SWT).

WRAP
The WrapClient class is a helper to request SWT tokens via WRAP. It supports issuer/key, SWT and SAML input credentials, e.g.:

var client = new WrapClient(wrapEp);
var swt = client.Issue(issuerName, issuerKey, scope);

All Issue overrides return a SimpleWebToken type, which brings me to the next helper class.

SWT
The SimpleWebToken class wraps a SWT token. It combines a number of features:

conversion between string format and CLR type representation
creation of SWT tokens
validation of SWT token
projection of SWT token as IClaimsIdentity
helpers to embed SWT token in headers and query strings

The following sample code generates a SWT token using the helper class:

private static string CreateSwtToken()
{
    var signingKey = "wA…";
    var audience = "http://websample";
    var issuer = "http://self";

    var token = new SimpleWebToken(
      issuer, audience, Convert.FromBase64String(signingKey));

    token.AddClaim(ClaimTypes.Name, "dominick");
    token.AddClaim(ClaimTypes.Role, "Users");
    token.AddClaim(ClaimTypes.Role, "Administrators");
    token.AddClaim("simple", "test");

    return token.ToString();
}

Thinktecture.IdentityModel: Comparing Strings without leaking Timinig Information

Your DisplayName here! — Sat, 08 May 2010 19:51:07 GMT

Paul Hill commented on a recent post where I was comparing HMACSHA256 signatures. In a nutshell his complaint was that I am leaking timing information while doing so – or in other words, my code returned faster with wrong (or partially wrong) signatures than with the correct signature. This can be potentially used for timing attacks like this one.

I think he got a point here, especially in the era of cloud computing where you can potentially run attack code on the same physical machine as your target to do high resolution timing analysis (see here for an example).

It turns out that it is not that easy to write a time-constant string comparer due to all sort of (unexpected) clever optimization mechanisms in the CLR. With the help and feedback of Paul and Shawn I came up with this:

Structure the code in a way that the CLR will not try to optimize it
In addition turn off optimization (just in case a future version will come up with new optimization methods)
Add a random sleep when the comparison fails (using Shawn’s and Stephen’s nice Random wrapper for RNGCryptoServiceProvider).

You can find the full code in the Thinktecture.IdentityModel download.

[MethodImpl(MethodImplOptions.NoOptimization)]
public static bool IsEqual(string s1, string s2)
{
    if (s1 == null && s2 == null)
    {
        return true;
    }

    if (s1 == null || s2 == null)
    {
        return false;
    }

    if (s1.Length != s2.Length)
    {
        return false;
    }

    var s1chars = s1.ToCharArray();
    var s2chars = s2.ToCharArray();

    int hits = 0;
    for (int i = 0; i < s1.Length; i++)
    {
        if (s1chars[i].Equals(s2chars[i]))
        {
            hits += 2;
        }
        else
        {
            hits += 1;
        }
    }

    bool same = (hits == s1.Length * 2);

    if (!same)
    {
        var rnd = new CryptoRandom();
        Thread.Sleep(rnd.Next(0, 10));
    }

    return same;
}

ADFS 2.0 RTW

Your DisplayName here! — Wed, 05 May 2010 17:40:56 GMT

Finally – the identity story is complete (for now).

Download ADFS 2.0.

Thinktecture.IdentityModel: WIF Support for WCF REST Services and OData

Your DisplayName here! — Wed, 05 May 2010 14:54:51 GMT

The latest drop of Thinktecture.IdentityModel includes plumbing and support for WIF, claims and tokens for WCF REST services and Data Services (aka OData).

Cibrax has an alternative implementation that uses the WCF Rest Starter Kit. His recent post reminded me that I should finally “document” that part of our library.

Features include:

generic plumbing for all WebServiceHost derived WCF services
support for SAML and SWT tokens
support for ClaimsAuthenticationManager and ClaimsAuthorizationManager
based solely on native WCF extensibility points (and WIF)

This post walks you through the setup of an OData / WCF DataServices endpoint with token authentication and claims support. This sample is also included in the codeplex download along a similar sample for plain WCF REST services.

Setting up the Data Service
To prove the point I have created a simple WCF Data Service that renders the claims of the current client as an OData set.

public class ClaimsData
{
    public IQueryable<ViewClaim> Claims
    {
        get { return GetClaims().AsQueryable(); }
    }

    private List<ViewClaim> GetClaims()
    {
        var claims = new List<ViewClaim>();
        var identity = Thread.CurrentPrincipal.Identity as IClaimsIdentity;

        int id = 0;
        identity.Claims.ToList().ForEach(claim =>
            {
                claims.Add(new ViewClaim
                {
                   Id = ++id,
                   ClaimType = claim.ClaimType,
                   Value = claim.Value,
                   Issuer = claim.Issuer
                });
            });

        return claims;
    }
}

…and hooked that up with a read only data service:

public class ClaimsDataService : DataService<ClaimsData>
{
    public static void InitializeService(IDataServiceConfiguration config)
    {
        config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
    }
}

Enabling WIF
Before you enable WIF, you should generate your client proxies. Afterwards the service will only accept requests with an access token – and svcutil does not support that.

All the WIF magic is done in a special service authorization manager called the FederatedWebServiceAuthorizationManager. This code checks incoming calls to see if the Authorization HTTP header (or X-Authorization for environments where you are not allowed to set the authorization header) contains a token. This header must either start with SAML access_token= or WRAP access_token= (for SAML or SWT tokens respectively).

For SAML validation, the plumbing uses the normal WIF configuration. For SWT you can either pass in a SimpleWebTokenRequirement or the SwtIssuer, SwtAudience and SwtSigningKey app settings are checked.If the token can be successfully validated, ClaimsAuthenticationManager and ClaimsAuthorizationManager are invoked and the IClaimsPrincipal gets established.

The service authorization manager gets wired up by the FederatedWebServiceHostFactory:

public class FederatedWebServiceHostFactory : WebServiceHostFactory
{
    protected override ServiceHost CreateServiceHost(
      Type serviceType, Uri[] baseAddresses)
    {
        var host = base.CreateServiceHost(serviceType, baseAddresses);

        host.Authorization.ServiceAuthorizationManager =
          new FederatedWebServiceAuthorizationManager();
        host.Authorization.PrincipalPermissionMode = PrincipalPermissionMode.Custom;

        return host;
    }
}

The last step is to set up the .svc file to use the service host factory (see the sample download).

Calling the Service
To call the service you need to somehow get a token. This is up to you. You can either use WSTrustChannelFactory (for the full CLR), WSTrustClient (Silverlight) or some other way to obtain a token. The sample also includes code to generate SWT tokens for testing – but the whole WRAP/SWT support will be subject of a separate post.

I created some extensions methods for the most common web clients (WebClient, HttpWebRequest, DataServiceContext) that allow easy setting of the token, e.g.:

public static void SetAccessToken(this DataServiceContext context,
string token, string type, string headerName)
{
    context.SendingRequest += (s, e) =>
    {
        e.RequestHeaders[headerName] = GetHeader(token, type);
    };
}

Making a query against the Data Service could look like this:

static void CallService(string token, string type)
{
    var data = new ClaimsData(new Uri("https://server/odata.svc/"));
    data.SetAccessToken(token, type);

    data.Claims.ToList().ForEach(c =>
        Console.WriteLine("{0}\n {1}\n ({2})\n", c.ClaimType, c.Value, c.Issuer));
}

HTH

Thinktecture.IdentityModel: Claims Debugger Visualizer

Your DisplayName here! — Wed, 05 May 2010 12:47:42 GMT

In the latest drop of Thinktecture.IdentityModel you can find a debugger visualizer for IClaimsIdentity and IClaimsPrincipal.

Have fun ;)

PS. Thanks to Mr. UI.

Sod This! – reloaded

Your DisplayName here! — Tue, 27 Apr 2010 10:53:55 GMT

Oliver and Gary fortunately decided to continue with their “Sod This” podcast show. That’s good – because I always found this very entertaining.

The “comeback” show is about security and identity – awesome ;)

Using an Active Endpoint to sign into a Web Application

Your DisplayName here! — Wed, 14 Apr 2010 12:51:50 GMT

This question comes up from time to time, so I thought I’ll document it here.

The scenario is, that you don’t want to do a passive redirect in a web app – but directly talk to an active STS endpoint to authenticate and request a token. The reasons for that could be that you need a local sign-in page in the web app – or that the token service is not publicly reachable.

The following code can be used on a login page:

protected void _btnLogin_Click(object sender, EventArgs e)
{
    // authenticate with WS-Trust endpoint
    var factory = new WSTrustChannelFactory(
        new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential),
        new EndpointAddress("https://sts/endpoint"));

    factory.Credentials.UserName.UserName = _txtUserName.Text;
    factory.Credentials.UserName.Password = _txtPassword.Text;

    var channel = factory.CreateChannel();

    var rst = new RequestSecurityToken
    {
        RequestType = RequestTypes.Issue,
        AppliesTo = new EndpointAddress("https://rp/"),
        KeyType = KeyTypes.Bearer
    };

    var genericToken = channel.Issue(rst) as GenericXmlSecurityToken;

    // parse token
    var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
    var token = handlers.ReadToken(new XmlTextReader(
       new StringReader(genericToken.TokenXml.OuterXml)));
    var identity = handlers.ValidateToken(token).First();

    // create session token
    var sessionToken = new SessionSecurityToken(
       ClaimsPrincipal.CreateFromIdentity(identity));
    FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);

    Response.Redirect("~/users/default.aspx");
}

Taken by Storm

Your DisplayName here! — Tue, 06 Apr 2010 10:18:00 GMT

Any more dodgy puns?

I am happy to announce that my good friend Oliver Sturm has joined thinktecture.

Oliver is a brilliant computer geek in general and a language wonk in particular – good company to hang out in bars – and just generally a nice guy. Looking forward working with you!

Thinktecture StarterSTS 1.0 RTW

Your DisplayName here! — Sun, 04 Apr 2010 06:33:42 GMT

Wow – I can’t tell you how happy and relieved I am to write this post ;)

I started to work with what’s now called WIF approximately two years ago – and built various security token services for customers, demos and internal use. The idea behind StarterSTS was to have a non-trivial security token service sample that demonstrates the typical tasks of an STS (where it turns out that issuing tokens is by far the smallest part) and at the same time is real world enough to be directly used in specialized situations like development STSes.

I checked-in the first public version of StarterSTS at 25th May 2009 and had 1861 download so far. Today I am announcing StarterSTS 1.0 which is feature complete (and hopefully reasonably bug-free) and finally includes documentation as well as nine new screencasts on the various feature areas.

I want to thank all beta-testers and early adopters that gave feedback along the way! Now that 1.0 is done we can think about ways to extend the STS in the future.

Codeplex Site
http://startersts.codeplex.com (main)
http://startersts.codeplex.com/releases/view/43054#DownloadId=115213 (direct)
http://startersts.codeplex.com/thread/list.aspx (forum)

Documentation
http://identity.thinktecture.com/stsce/docs/

Screencasts
Initial setup & configuration
Federating your first web application
Federating with web services
Single-Sign-On & Confirmation screen
Using the REST endpoint
Using the OpenId bridge
Tracing
Using client certificates
Using Information Cards

Using Silverlight to Access WIF secured WCF Services (Part 3)

Your DisplayName here! — Tue, 30 Mar 2010 08:18:07 GMT

In this last part of the series (see here and here) I want to show you how to use the WIF/SL integration ClaimsIdentitySessionManager to request tokens and talk to WIF secured services.

The ClaimsIdentityManager registers as an ApplicationService in SL. Once registered, it can encapsulate the process of requesting a token for a relying party, caching that token as well as setting the SOAP security header for outgoing service requests.

Registration
ClaimsIdentitySessionManager gets registered in app.xaml. Here you can specify the endpoint address of the WS-Trust token services as well as the credential type. In this sample I am using the ADFS2 Windows/Transport endpoint from my last post.

<Application.ApplicationLifetimeObjects>
    <id:ClaimsIdentitySessionManager>
        <id:ClaimsIdentitySessionManager.IdentityProvider>
            <id:WSTrustSecurityTokenService
                   Endpoint="https://server/services/trust/13/windowstransport"
                   CredentialType="DefaultCredential" />
        </id:ClaimsIdentitySessionManager.IdentityProvider>
    </id:ClaimsIdentitySessionManager>
</Application.ApplicationLifetimeObjects>

Calling the Service
All the service interaction is abstracted by the ClaimsIdentitySessionManager. The call to InvokeAsync does a few things:

checks if a token has already been obtained for the service endpoint

if not, requests the token and caches it
if a password is required, invokes a callback to the UI

sets the SOAP security header using the requested token

private void CallService()
{
    var factory = new ChannelFactory<StarterServiceContract>("symmetric");
    var proxy = factory.CreateChannel();
    var channel = proxy as IClientChannel;

    ClaimsIdentitySessionManager.Current.InvokeAsync(() =>
        {
            proxy.BeginGetClaims(result => ShowClaims(proxy, result), null);
        }, channel);
}

Requesting Tokens from ADFS2 using Silverlight and Windows Authentication

Your DisplayName here! — Sun, 28 Mar 2010 15:37:27 GMT

With SL4’s support for NTLM and the WIF integration bits, you can now easily request tokens from ADFS2 (or any other token service that supports Windows authentication) in single-sign-on style. Here’s the quick walk-through…

Enable the right endpoint in ADFS2
You need a WS-Trust endpoint for version 1.3 that supports transport security and Windows authentication. This endpoint needs to be enabled in the ADFS2 MMC (/trust/13/windowstransport).

Configure WSTrustClient and request the Token
Next you have to configure WSTrustClient to use this endpoint, using the Windows binding and Windows credential type:

var client = new WSTrustClient(
    new WSTrustBindingWindows(),
    new EndpointAddress("https://server/adfs/services/trust/13/windowstransport"),
    new WindowsCredentials());

From there on you can include the token to auth against other services.

Using Silverlight to Access WIF secured WCF Services (Part 2)

Your DisplayName here! — Sun, 21 Mar 2010 20:52:58 GMT

This was one of my most popular blog post in the recent time (please read it first to get the necessary background information). I thought I give this another shot with the new SL/WIF integration.

There are other ways to accomplish the below things, e.g. using the SL application service or passive identity providers. I am focusing here purely on the SL initiated active STS/RP communication scenario and the raw APIs.

Requesting Tokens from within Silverlight
In my old post I had to use a custom REST endpoint in StarterSTS to request a bearer token. With the new WSTrustChannel, it is now possible to talk to a standard WS-Trust 1.3 endpoint (like the one in StarterSTS or ADFS2).

var client = new WSTrustClient(
    new WSTrustBindingUsernameMixed(),
    new EndpointAddress("https://.../issue.svc/mixed/username"),
    new UsernameCredentials("username", "password"));

You then have to construct an RST. Basically you specify the key type (bearer or symmetric) and appliesTo value.

var rst = new RequestSecurityToken(WSTrust13Constants.KeyTypes.Symmetric)
{
AppliesTo = new EndpointAddress("https://roadie/StarterRP/")
};

The call to WSTrustClient.Issue returns an RSTR – which in turn contains the requested token and further key material. The identity kit also contains a token cache called TokenCache. You could use this class if you want to to store that token for further use.

client.IssueCompleted += (s, args) =>
{
_cache.AddTokenToCache("myRP", args.Result);
};

client.IssueAsync(rst);

Using a Token to authenticate with a WCF Relying Party
Since Silverlight does not support issued token credentials, we must handcraft the SOAP security header. The identity kit includes the IssuedTokenHeader class for this purpose. The nice thing is, that this class supports symmetric proof keys as well as bearer tokens. But you still have to set this header manually on every call.

The identity kit includes its own wrapper to abstract away the header generation. I am using my own little helper here to make this process less disruptive.

public static class IssuedTokenHeaderExtensions
{
    public static void SendWithIssuedToken(this IContextChannel channel,
      RequestSecurityTokenResponse rstr, Action action)
    {
        using (new OperationContextScope(channel))
        {
            OperationContext.Current.OutgoingMessageHeaders.Add(
              new IssuedTokenHeader(rstr));

            action();
        }
    }
}

This allows calling a WCF service like this:

private void CallService()
{
    var factory = new ChannelFactory<StarterServiceContract>("myRP");
    var proxy = factory.CreateChannel();
    var channel = proxy as IContextChannel;

    channel.SendWithIssuedToken(_cache.GetTokenFromCache("myRP"), () =>
        {
            proxy.BeginGetClaims(result => ShowClaims(proxy, result), null);
        });
}

The trick here again is, that the client stack is configured for no security at all, whereas the WCF service uses a federation binding (with SecureConversation turned off).

I think this is pretty cool and solves some of the problems I had in the past. If Silverlight would only support client certificate credentials….

A first Look at Silverlight and WIF Integration

Your DisplayName here! — Sun, 21 Mar 2010 10:23:59 GMT

At MIX, Caleb did a talk about the new Silverlight/WIF integration classes that “ship” with the latest identity training kit. Since this is a topic that comes up really frequently – I had a first look.

The integration code consists of two projects (client & server side plumbing) and can be divided into several feature areas. I will post more information on the corresponding areas when I have written more code against them.

Same claims programming model as in WIF
The integration code includes (I)ClaimsPrincipal, (I)ClaimsIdentity, Claim, ClaimCollection as well as the standard claim types.

WS-Trust and WS-Security support
This is my favourite feature! The WSTrustClient class allows requesting tokens from WS-Trust 1.3 endpoints. It supports Username/Password and Windows credentials as well as bearer and symmetric token types. The IssuedTokenHeader class makes it easier to embed the requested token in calls to backend services. The TokenCache class allows caching RSTRs to be used with the issued token header.

Bringing claims to a Silverlight UI
Another feature area deals with bringing claims into the SL UI for personalization and authorization purposes. This needs some server side plumbing (the AuthenticationService) and seems to focus on passive scenarios. The current implementation simply mirrors the user claims that are visible in the app/service backend back to the UI.

Silverlight integration
This part of the integration code makes logons and claims access more SLish by providing an SL appplication service and thus data binding access to claims.

HTH

Thinktecture.DataObjectModel

Your DisplayName here! — Tue, 09 Mar 2010 09:45:21 GMT

Our very own Jörg Neumann had this cooking for quite a while. tt.DOM is a library that lets you add features like change tracking, undo, redo, views, transactions and n-tier support to arbitrary types (or lists of types). This makes typical data scenarios in 3-tier applications *much* easier to handle.

Expect more information and documentation soon (of course ;).

In the meanwhile feel free to play around with it and give us feedback via the codeplex forum!

http://dataobjectmodel.codeplex.com

This week: Trooper Heidelberg

Your DisplayName here! — Sun, 07 Mar 2010 17:45:39 GMT

Looking forward to this week’s nice little security conference organized by my old friends at ERNW.

Federated Identity - Opportunities and Risks
The world is moving towards a federated identity model. Public facing websites like Google or Facebook utilize technologies like OpenID, OAuth and WRAP to provide single-sign-on capabilities. Enterprises and ISVs start deploying WS-Federation, WS-Trust and SAML to federate with customers, partners and even internally. The goals are always the same: provide a more meaningful representation of "identity" for authentication, authorization and personalization. This talks sheds light on all these technologies, how they work and how to secure them.

Guide to Claims-based Identity and Access Control

Your DisplayName here! — Fri, 05 Mar 2010 12:36:46 GMT

RTM finally ;)

Book here.
Code here.
More info here.

Enjoy!!!

WIF Workshop

Your DisplayName here! — Fri, 05 Mar 2010 12:28:46 GMT

Mein geschätzter Kollege Vittorio Bertocci führt einen 2-Tägigen Workshop zum Thema Windows Identity Foundation in München durch. Das ist bestimmt eine gute Gelegenheit sich mal abseits vom Projektalltag mit dem Thema genauer zu beschäftigen.

Wenn danach alle (un)Klarheiten beseitigt sind, und Sie weiterführenden Informationen oder Unterstützung zur Implementierung von Claims in der Praxis benötigen – einfach Email an mich (dominick.baier (_at_) thinktecture.com). Ich helfe gerne weiter. Viel Spaß!

Zurück von der BASTA

Your DisplayName here! — Mon, 01 Mar 2010 08:06:39 GMT

So – zurück und (wichtiger) erholt von der BASTA. Muss sagen – es war mal wieder sehr nett – großes Lob an Veranstalter und Teilnehmer. Hat Spaß gemacht!

Am meisten war ich über das große Interesse an WIF überrascht. Ein voller Raum für nen Security Talk – und das direkt nach dem Essen ;)

Hier habe ich eine sehr gute Zusammenfassung des Talks gefunden – die Punkte, die mir am Herzen lagen, scheinen angekommen zu sein! Das freut mich!

Ich habe es schon während des Vortrags erwähnt – WIF ist sowohl ein neuer API als auch ein neues Paradigma. Dafür reichen 75min einfach nicht aus. Wer Fragen dazu hat, oder Unterstützung braucht – einfach Mail an mich.

Bis zum nächsten Mal!

Adding StarterSTS as a Claims Provider for ADFS2

Your DisplayName here! — Mon, 01 Mar 2010 07:30:14 GMT

The v1 beta of StarterSTS has an updated relying party configuration section. This allows to “plugin” the STS into ADFS2 or Sharepoint as a claims provider.

Here’s a quick walkthrough for ADFS2:

Register StarterSTS as claims provider in ADFS
This is really easy. Simply go to the ADFS2 configuration console and add a new claims provider. Then point the wizard to the StarterSTS WS-Federation metadata file (either by URL or using a file path). Afterwards you have to add some claim rules – to get started you could add a pass-through rule for the name claim.

You will also need to export the ADFS2 certificate that is used for token decryption.

Registering ADFS2 as a relying party in StarterSTS
The next step is to register ADFS2 in StarterSTS. This is done by modifying the relyingParty.config file (in the configuration sub folder). You need three things for that – the ADFS issuer URI, the physical address of the ADFS2 sign-in page and the ADFS2 token encryption certificate. The certificate could be either imported into the certificate store or you copy it to ~/App_Data/certificates.

The config entry looks similar to this:

<add realm="http://<adfsname>/adfs/services/trust"
replyTo="https://<adfsname>/adfs/ls/">
<certificate filename="tokendecryption.cer" />
</add>

HTH

WCF, WIF and Load Balancing (and a bit of Azure)

Your DisplayName here! — Fri, 19 Feb 2010 07:36:26 GMT

Pablo wrote a post yesterday giving some background information on how session tokens are protected in WIF – here some additional info for WCF:

The ws* bindings in WCF establish a security session by default (via WS-SecureConversation). This has some implications, e.g.

You end up with a stateful service – or more important – with a stateful programming model. You have all the typical session “problems” like faulted sessions, timeout, retries etc…
By default SecureConversation only transmits a session identifier (like a ASP.NET session cookie) – the actual session is stored in-memory at the server. Not good for load balancing.

When you want to use WCF in a load balanced environment (e.g Azure) – you have to change the default behavior – you basically have two options:

Turn off SecureConversation all together. This has the advantage of being stateless (at least in that part of the communication). But this also means, that the bootstrap (SAML) token will get parsed on every request – this includes invoking the ClaimsAuthenticationManager. This might have performance implications – but depends on your scenario.
Force WCF into “cookie mode”. This means that the complete IClaimsPrincipal (after ClaimsAuthenticationManager has run) gets serialized and round-tripped in the SOAP header.

Turning off SecureConversation
Unfortunately WCF 3.5 does not directly allow that on the standard federation bindings. You would need to create a custom binding that uses an authentication mode of IssuedTokenOverTransport (for mixed mode) or IssuedTokenForCertificate (for message security).

In .NET 4 you can simply set establishSecurityContext to false on the standard ws-fed binding.

Cookie Mode
Forcing WCF into cookie mode requires a custom binding. The “trick” here is to set requireSecurityContextCancellation to false – which is just a fancy name for “serialize the context into the message”. Here’s the binding I am using (mixed mode security):

As Pablo points out in his post, the session cookie must be protected somehow. The standard WIF behavior is to the DPAPI user key. This key cannot be easily shared between nodes in a cluster (unless the nodes are all domain members and roaming profiles are activated). Another more explicit (and practical) option is to use an RSA key. Most typically you would feed your SSL certificate or the certificate used to decrypt incoming tokens into the following session token handler:

public class WebFarmSessionSecurityTokenHandler : SessionSecurityTokenHandler
{
    public WebFarmSessionSecurityTokenHandler(X509Certificate2 protectionCertificate)
        : base(CreateRsaTransforms(protectionCertificate))
    { }

    private static ReadOnlyCollection<CookieTransform> CreateRsaTransforms
      (X509Certificate2 protectionCertificate)
    {
        var transforms = new List<CookieTransform>()
                        {
                            new DeflateCookieTransform(),
                            new RsaEncryptionCookieTransform(protectionCertificate),
                            new RsaSignatureCookieTransform(protectionCertificate),
                        };

        return transforms.AsReadOnly();
    }
}

One way of wiring up the above handler would be a service host factory for the WIF enabled WCF service. If you want to put a little more work in it you can also make the handler configuration friendly (see here).

In general I’d recommend watching Hervey’s excellent talk from PDC09 about WIF in load balanced environments (e.g. Azure).

HTH