ACS v2 Public in AppFabric Labs
Earlier this afternoon we pushed a new version of the AppFabric Access Control Service into our public “Labs” environment.
If you’d like to find out more about the service, feel free to create an account at http://portal.appfabriclabs.com. You can also check out our CodePlex documentation & samples at http://acs.codeplex.com, watch Justin in his Channel9 IdElement interview, or watch the walkthrough screencast.
V2 of the service is a significant upgrade from V1, we’ve moved beyond the simple OAuth WRAP implementation that was all that V1 had to adding support for WS-Federation, WS-Trust and OpenID and, in particular, we’ve opened up the Web Single Sign-On scenarios such that by simply creating a tenant in ACSv2 and federating your application with it, you can allow users to login from Windows Live ID, Google, Yahoo!, Facebook and AD FS 2.0. Using the OData-based Management Service, you can further configure ACS to allow sign-in from other OpenID identity providers.
Here’s a quick list of the things that we think are the top-level features of the new version:
Integrates with Windows Identity Foundation (WIF) and it’s FedUtil tooling in Visual Studio
One-click support for Windows Live ID, Google, Yahoo!, Facebook plus easy addition of other OpenID providers
Very simple setup for federation with AD FS 2.0
Support for SAML 1.1 and 2.0 and Simple Web Tokens
ACS Hosted and Relying Party Hosted Home Realm Discovery page support with simple customization
OData-based Management Service to configure the service
A Management Portal for configuration that includes the use of federated identities to management the service
Backwards compatibility token issuing endpoint for users of the v1 service
Over the coming weeks, we have more features to add and will steadily work toward taking V2 into Production status.
Identity Provider?
Take care, that’s my view.
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.
Using ACS? Read the WRAP specification
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.