Curt Devlin keynotes 4th Boston Azure User Group meeting

Identity, Claims, Geneva, and Trust in the Cloud

This was Boston Azure meeting #4, Feb 25, 2010

(Curt’s slide deck will be made is now available (PPT 2003 format))

Some notes from Curt’s talk:

• Azure devs need to care about claims-based-identity and federated identity
• Geneva is Microsoft’s solution in this space
• Perfect storm of paradigm shifts
• Caution: Geneva is not a panacea for “Identity in the Cloud”

“The most important thing Microsoft has done in identity since they came out with ActiveDirectory” – and think about how much we rely on AD for enterprise-class apps – “it’s like air”

First two lines of every program (with nod to Kim Cameron):

1. Who are you?
2. What are you allowed to do?

• The answer to the second generally depends on the answer to the first. “Identity” is an input.

Big architectural problem: the ‘net was built w/o any way of knowing who you are connecting to (http has no identity)

• RBAC (role-based access control) is not as flexible or powerful as claims
• Any statement that can be validated can be a claim

Microsoft’s Federated Identity Group very focused on standards. To be serious also about Azure, you need to pay deep attention to the key standards.

Azure is only cloud solution REALLY solving the SSO problem in the cloud – and into your data center. Identity must flow…

Geneva Technology stack:

• Microsoft Federation Gateway (“ADS 2.0 in the sky”)
• Windows Identity Foundation (some .NET namespaces)
• Active Directory Federation Services 2.0
• Windows CardSpace 2.0

Curt will focus for a while in his talk on Windows Identity Foundation…

Consider three parties – Security Token Service, Your App, End User

1. Secure Token Service <=> Your App – Initial handshake uses WS-Federation (metadata, X-509 cert)
2. End User <=> Your App – claims via WS-Policy (which Security Token Service(s) I trust)
3. End User <=> Security Token Service – verify policy
4. End User <=> Security Token Service – WS-Trust
5. End User <=> Your App – lots of interactions – signed tokens, claims

ADF 2.0 – same programming model across web and desktop

RP = relying party – someone that consumes tokens

PingIdentity.com

OpenID cannot help with Man-in-the-middle attacks

“Shred the token” is lingo meaning to decrypt a token.

Coded example showing implementation of Passive Federation.

• Showed the 8 (!) prerequisites
• Create full-trust app (Since runtime not fully baked in Azure yet – and certainly not yet in GAC)
• Add a reference to Microsoft.IdentityModel (which is a stronger programming model than older System.IdentityModel)
• using Microsoft.IdentityModel.Claims;
• using System.Threading;
• Then write like 5 lines of code…
• Subclasses from IIdentity, IClaimsIdentity, IClaimsPrincipal (same ones used in other .NET apps)
• WIF ASP.NET Processing Pipeline does a lot of behind-the-scenes work for us
• IsInRole method is key
• Then in the ASP.NET app, there is some 10 lines of key code for X-509 cert – which contains the URL (or domain, really) of the web site that the cert applies to – a problem with “localhost” and “stage.foo.com” etc. due to mismatch – this goes in Global.asax – plus several other blocks of code…

Now for the STS (which you don’t need if you have ADFS 2.0)

• There is a Token Service for ASP.NET visual studio template with Geneva install
• Many coding steps here (see slides)
• Use FedUtil (which comes with Geneva and VS 2008, VS 2010) to create a trust between your application and your STS
• There is a lab to create your own STS

Claims-based systems externalized the work of AuthZ, AuthN to your STS – not stuck in your code.

Geneva supports delegation – embedding one token within another…

(21 people at the meeting)