You can find the WRAP specification here. When you’ve gone through it, remember that ACS today only implements the Client Account and Assertion profiles – 5.1 and 5.2 – and, importantly, that a “Client” in the WRAP specification isn’t the same thing as an end-user, something that I obliquely refer to here. In the absence of the three profiles that deal with end-users but armed with the knowledge that we’re working to fill out the WRAP implementation and add more protocols (including the usual suspects), you should be able to plan your use of ACS more effectively.

The Developers Guide whitepaper is also good overview material.

ACS can accept identities using several mechanisms – a SAML security token signed by an X.509 Certificate, a Simple Web Token signed with a shared secret, and a form of name/password. The last one causes the confusion, especially since you can authenticate using a name/password or build a Simple Web Token using the same name/password. They’re interchangeable. But ACS wasn’t built to be an Identity Provider in the complete sense of that term.

For example, if the name/passwords really represented users, a real Identity Provider would provide mechanisms that would allow users to create accounts, add claims, choose and reset their passwords and so on. It would also support one of the browser-based logon protocols so that web sites could easily make use of the identities stored at ACS. None of these are features of ACS. Instead, the closest you can get to per-user claims is for an administrator of the ACS solution to edit the rules to generate claims unique to a users identity. And this model doesn’t scale well in terms of manageability – it leaves the administrator to provide the end-user management capabilities and you have to edit the rule set to make it work.

When is an “issuer” an authority giving out tokens and when is it an individual entity, be that a Service or an end-user? I believe that the distinction between these cases is important, it affects how we trust those entities in the system and that affects the security of the system. ACS stores the name/password values in one table and they can be validated directly as either name/password or name/key for Simple Web Tokens, the distinction is left to the administrator to decide for their usage of the service.

This is all great, you have some flexibility to decide for yourself. However, as we move forward with the architecture and design for ACS2 the distinction becomes more important if we’re reach our goals for the next version. Unfortunately I can’t give out details of ACS2 yet – we’re still planning and firming up our ideas – but one theme is starting to emerge and that theme means that ACS may need to more clearly recognize the distinction between authorities and users. With everything stored in a single table today that’s going to make migration tricky, especially if you’ve stored thousands of name/passwords representing your users in ACS and even you can’t distinguish them from authorities handing out identities.

As I said, take care.

The biggest issue with the current samples is that we’re loading Certificates with private keys out of web.config while we wait and hope for additional certificate support from Azure. We don’t consider this a safe practice for a production site but it is a reasonable compromise to enable you to start prototyping and experimentation with WIF in Azure now.

The next sample will be a simple STS using WCF and WIF together in Azure and we hope to post that as soon as possible after Vittorio gets back from a well deserved vacation.