CardSpace and the Access Control Service

The Geneva Framework is designed to simplify the development of claims-aware applications that want to eternalize the authentication function. I wanted to the the Geneva Framework to help create an ASP.NET application that would enable users to authenticate with either a Windows Live ID or a CardSpace managed information card, and then apply some authorization rules that were defined in the Access Control Service (one of the cloud hosted .NET Services).

My initial working assumptions were:

1. The Windows Live ID authentication would use a passive mechanism (WS-Federation). My ASP.NET application (the Relying Party) would send an HTTP request to an Access Control Service (ACS) endpoint, which would then initiate a sequence of HTTP redirects to authenticate the user at www.live.com, and then deliver a set of authorization rules (claims) from ACS back to my application.

2. The CardSpace authentication would use an active mechanism (WS-Trust). The ASP.NET application would launch the CardSpace UI to enable the user to select a suitable card, which would then be delivered directly to ACS in a SOAP message. ACS would then examine the claims in the card and deliver a set of authorization rules (claims) from ACS back to my application.

Assumption 1 turned out to be valid, and easy to implement as there are plenty of available examples to work from. The only bit which is not perfect here is managing the sign out from Windows Live whilst remaining on a page of my ASP.NET application.

Assumption 2 however turned out to be problematic. The current version of CardSpace (a part of .NET Framework 3.5) will only work with a Security Token Service (STS) that returns at least 1 claim. Unfortunately the endpoint that ACS exposes has an associated policy that does not have any required claims – so CardSpace refuses to talk to it. The Geneva Framework includes a new (beta) version of Windows CardSpace which relaxes this restriction, but I then hit another obstacle: the ACS uses message security, but the new version of CardSpace currently only supports mixed-mode transport bindings. So again CardSpace will not talk to the ACS.

As a work around I reverted to using a passive approach for the CardSpace authentication. My ASP.NET website (the Relying Party) is configured to perform a passive logon to the ACS, but instead of the ACS redirecting to a Windows Live login page, it redirects to a login page on a custom STS (created using a template from the Geneva Framework). This custom STS operates as a proxy, and extracts the claims from the Information Card, before repackaging them as a new set of claims to send to the ACS in an HTTP redirect.

Hopefully, this will all be simplified in future releases of CardSpace and the ACS, when a direct login to the ACS using a managed card will be possible.

For anyone who’s interested I’ve posted some sample code and documentation here: