Drink the red token – debug your claims-aware apps
June 30th, 2009
Another identity development widget brought to you by Vittorio’s team. This time it’s a very tiny control called 
SecurityTokenVisualizer that helps debugging claims-aware web applications. But the thing I like of this control is that it can also be used as a teaching tool, very useful for demos by the way. Last week we “dogfooded” it during the Iteration Review of an identity-related project and the audience made the click when we expanded the red small pentagon that shows the behind the scenes.
Simply drag and drop the control on any page and it will render a collapsible table with
- Issued Identity claims
- Delegated Identity claims
- The raw SAML token (in a textarea)
- The SAML token properties (validfrom, validto, audience, signing certificate, etc.)
- The certificate used for token decryption
As usual, read the details on Vittorio’s blog.
ASP.NET control for claims-aware apps
June 19th, 2009
- Claim Value: set the value of a property with the value of a specified claim type
<cc1:ClaimsDrivenModifierControl ID=”cdmFirstName” runat=”server” ControlToDrive=”txtFirstName” PropertyToModify=”Text”> <Expression Type=”ClaimValue”> <ClaimType>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname</ClaimType> </Expression> </cc1:ClaimsDrivenModifierControl>
- Mapping: it will set the value of a property based on a set of conditions with an output <cc1:ClaimsDrivenModifierControl ID=”cdmMemebershipLevel” runat=”server” ControlToDrive=”imgMembershipLevel” PropertyToModify=”ImageUrl”> <Expression Type=”Mapping”> <cc1:Mapping ClaimType=”http://cloudbuddies.com/2009/06/FrequentFlierLevel” ClaimValue=”silver” Result=”~/img/silver.png” /> <cc1:Mapping ClaimType=”http://cloudbuddies.com/2009/06/FrequentFlierLevel” ClaimValue=”gold” Result=”~/img/gold.png” /> </Expression> </cc1:ClaimsDrivenModifierControl>
And of course you can use the designer to set this all up. I’m not a huge fan of server controls and designers but I know that there are people out there that loves them, so this is something that will bring you closer to developing claims-aware applications.
Download the control from http://code.msdn.microsoft.com/ClaimsDrivenControl/Release/ProjectReleases.aspx?ReleaseId=2861
Identity thoughts #2: Level 2 Authorization
June 17th, 2009
In my last post I talked about an identity roadmap and how we are helping companies to achieve Level 1: Externalizing Authentication. In this first level, we only care about checking the credentials of a user in a Security Token Service and issue a token with a couple of claims. That token will be enough to prove access to the application.
Reaching the Level 1 will make a great difference to the IT department of a given company. By having a central login place they will be able to answer to questions like “when someone logged in to a certain application?”, “which applications someone used in this timeframe?”, etc. In terms of governance, having a single way to implement login will allow the architecture department (if any) to decrease security threats because there is a single well thought piece of infrastructure to perform user authentication across all apps. As a side effect it will also reduce costs of development and maintenance.
Level 2 talks about the authorization process. The authorization decision happens near the application or the service because it knows about the resource (each application has a different domain model).
Geneva Server – Level 1 Authentication
- SSO & Federation – unified login experience and federation with partners
- Centralized Claim Mapping management
- Externalize authentication
- Near the identity provider
- Questions it will answer
- When a subject logged in to an app?
- What claims the subject presented to the app?
Policy Server - Level 2 Authorization
- Policy Enforcement
- Centralized Policy Rules management
- Externalize authorization
- Near the application
- Questions it will answer
- What permissions did the subject requested?
- What permissions where denied?
The following figure shows a very high level architecture of the components and its interactions
Resources
[XACML] http://www.oasis-open.org/committees/xacml/
[Geneva Server] http://connect.microsoft.com/content/content.aspx?ContentID=10106&SiteID=642
[SAML] http://www.oasis-open.org/specs/#samlv2.0
The following table shows an analogy of identity concepts between a single application and a federated application.
The single app has its own identity silo and the federated app relies on an STS (like Geneva Server). I find this analogy useful to explain how things differ from the non-federated non-claim-based world.
