Infographic: IPs, Protocols & Token Flavours in the August Labs release of ACS

The newest lab release of ACS shows some serious protocol muscle, covering (to my knowledge) more ground than anything else to date. ACS also does an excellent job in simplifying many scenarios that would traditionally require much more thinking & effort: as a result, it is very tempting to just think that any scenario falling in the Cartesian product of possible IPs, protocols, token types and application types can be easily tackled. Although that is true in principle, in reality there are uses and scenarios that are more natural and easier to implement. Discussions about this, in a form or another, are blossoming all over the place both internally and externally: as a visual person I think that a visual summary of the current situation can help to scope the problem and use the service more effectively. Here there’s my first attempt (click for bigger version).

I am fairly confident that this should be correct, I discussed it with Hervey, Todd and Erin, but there’s always the possibility that I misunderstood something.
There’s quite a lot of stuff in there, let me walk you through the various parts of the diagram.

The diagram is partitioned in 3 vertical disjointed regions: on the left there are all the identity providers you can use with ACS, on the right the applications that can trust ACS; and between them, there is ACS itself. On the borderline between ACS and your applications there are the three issuing endpoints offered by ACS: the WS-Federation endpoint, the WS-Trust endpoint and the OAuth WRAP one. Here I didn’t draw any of the ACS machinery, from the claim transformation engine to the list of RP endpoints; it’s enough to know that something happens to the claims in their journey from the IP to the ACS issuers.

The diagram is also subdivided in 3 horizontal regions, which represent the kind of apps that are best implemented using a given set of identity providers and/or protocols. The WS-Federation issuer is best suited for applications which are meant to be consumed via web browser; WS-Trust, and the OAuth WRAP profiles that ACS implements, are ideal for server to server communications; finally, WS-Trust is also suitable for cases in which the user is taking advantage of rich clients. This classification is one of the areas of maximum confusion, and likely source of controversy. Of course you can use WS-Federation without a browser (that’s what I do in SelfSTS), of course you can embed WS-Federation in a rich client and use a browser control to obtain tokens; however those require writing custom code, a very good grasp of what you are doing and the will to stretch things beyond intended usage, hence I am not covering those here.

Let’s backtrack through the diagram starting from the ACS issuer endpoints.

The WS-Federation endpoint is probably the one you are most familiar with; it’s the one you take advantage of in order to sign in your application by leveraging multiple identity providers. It’s also the one which allow you a no-code experience for the most common cases, thanks to the WIF SDK’s Add STS Reference wizard.
You can configure that endpoint to issue SAML1.1, SAML2 and SWT tokens. The latter can be useful for protocol transition scenarios, however remember that there’s no OOB support for the format.
The sources here are the ones you can see on the portal, and the ones that the ACS-generated home realm discovery page will offer you (if you opted in). Every IP will use its own protocol for authentication (Google and Yahoo use OpenID, Facebook uses Facebook Connect, ADFS2 uses whatever authentication system is active) but in the end your application will get a WS-Federation wresult with a transformed token. It should be noted that “ADFS2” does not strictly indicates an ADFS2 instance, anything that can do WS-Federation should be able to be used here.

The WS-Trust endpoint will issue tokens when presented with a token from a WS-Trust identity provider, that is to say an ADFS2 instance (or equivalent, per the earlier discussion). It will also issue tokens when invoked with username and password associated to a service identity, static credentials maintained directly in ACS.

The OAuth WRAP endpoint will issue SWT tokens when invoked with a service identity credential; it will also accept SAML assertions from a trusted WS-Trust IP, pretty much the ADFS2 integration scenario from V1. Note that the profiles supported by ACS are server to server: the username & password of a service identity are not user credentials, but the means through which a service authenticates with another (including cases in which the user does not even have a session in place).

That’s it, that should give you a feeling of the scope of what you can do with this release. I’ll probably add to this as things more forward. Have fun!