[MS Techdays 2009] Summary “Identity & Cloud Services” Vittorio Bertocci

Cloud Services
The cloud is about capabilities, “Someone is providing It” and not about the hardware, “The means through what it is provided”.

The way we are moving to services is comparable to the evolution of manufactories. In the early ages every factory had its own power plant and part of manufacturing was providing in your own power to operate the machinery. Nowadays manufactories are just connected to the electricity grid providing this power service to their clients.

Cloud Identity
The manufactory example is applicable to identities.

Every company has its own directory system for storing usernames and passwords. The challenge is how to connect all the different protocols, providers and platforms to get identities into the cloud going beyond the company’s network boundaries.

What if identity management could move to the cloud and be consumed as service i.e. outsourcing or externalizing authentication and authorization? In other words leveraging trust relationships.

Introduction to Claims Based Identity
Definitions:

• Claims = statements about an entity (subject) made by an entity (issuer)
• Tokens = signed XML fragments which transport credentials and claims about a subject
• Security Token Service (STS) = web service that issues security tokens

Simplified model for Subject “Identity Provider ” Relying Party:

1. There is trust relationship between Identity Provider and Relying Party based on certificates
2. Subject identifies against Identity Provider and request token for accessing Relying Party.
3. Identity Provider (operates as STS) issues the token and sends it to Subject.
4. Subject sends token to Relying Party.
5. Relying party returns ticket that Subject can use to set up an connection with Relying Party.

In an elaborate model the Relying Party can be a Subject of in another Claim Based Access network creating as such a trust relationship between two networks.

This latest model is ideal to move identities to the cloud. In the cloud a trusted third party Identity Provider can bridge identities between two company networks. In fact this is what .NET Access Control Service part of the new Azure platform is all about.

.NET Access Control Service .NET Access Control Service (ACS) encapsulates the following:

1. A Security Token Service allowing the previously described delegated access:
   • token issuer
   • claims transformation rules for access requests from the cloud
   • trust management
2. A portal where you manage access control rules
3. An API to programmatically manage access control rules

A SDK for .NET Access Control Service can be downloaded from:
http://go.microsoft.com/fwlink/?LinkID=129448

The ACS STS brings to .NET solutions three STS’s: one for the solution itself, one for Workflow services and one for ServiceBus services.

For the moment several identity types are supported but a convergence to SAML tokens is announced that would replace .Net identities, X509 identification, …

Scopes and Rules
By means of scopes and rules the access from the cloud is regulated.

Scopes allow you to associate a set of rules with a set of assets accessible through ACS. It contains an URI, a certificate and a list of identities.

Rules perform the claim transformation. One or more claims delivered by the Subject trying to access from the cloud are transformed into one claim for the delegated STS.

Conclusion
Identity management will not escape the shift to the cloud and will become nothing more than a service, consumed like any other service. It will make complex inter-company network identity management more transparent.