Back in August I tried to capture in a single view all the relevant aspects for token issuing of that LABS release of ACS: preconfigured identity providers, available issuer endpoints, credential types accepted, token types, and so on. Since then I’ve been using that infographic in various sessions, and it served me well to explain some of the hardest scenarios.

As I was revving one deck I stumbled in that slide, and found it outdated; hence I decided to align the content to what the service offers today, and explicitly add some of the elements that I often find myself drawing on top of the schema. So here it is! As usual, if you want to see a bigger version just click on the image.

I already explained in the last post the general structure of the diagram, and I won’t repeat it here as it remains largely unchanged: I just adjusted some labels according to feedback.

Other cumulative changes from the last 6 months:

• The area representing ACS is now subdivided in bands, indicating the functional layers that the claims traverse from input to output: a protocol layer receiving the token, a trust layer verifying it comes from one of the intended sources, the claims transformation core which executes all the rules that apply, again the trust layer to see if the intended RP is configured in the service, which crypto should be used with it, etc; finally, again the protocol layer to dispatch the issued token via the intended protocol
• I added icons for the application types that would typically use the endpoints (ie the WS-Federation endpoint is usually for web applications, WS-Trust for SOAP web services, etc) as the brackets on the left are slightly more generic (ie also include the intended client or usage scenario)
• The WS-Trust endpoint can spit SWT too now
• Certificates were added among the credentials that can be sued as service identities
• OpenID now appears among the possible identity providers (it is not in the portal, but an OpenID issuer can be set up via management service)

I briefly chatted with Caleb about if it was the case to include the protocols that ACS uses for connecting with the various preconfigured IPs (ie OpenID with google and yahoo, Oauth2 with Facebook, etc) but the conclusion was that this is exactly one of the details you can stop worrying about when you outsource trust management to ACS

So there you have it. Don’t take it all the once, but rather use it as a GPS when you feel the need to understand where you are in the service. Happy exploring!