ACS v2 supports a number of protocols (WS-Federation, WS-Trust, OpenId, OAuth 2 / WRAP) and a number of token types (SWT, SAML 1.1/2.0) – see Vittorio’s Infographic here. Some protocols are designed for active client (WS-Trust, OAuth / WRAP) and some are designed for passive clients (WS-Federation, OpenID).

One of the most obvious advantages of ACS is that it allows to transition between various protocols and token types. Once example would be using WS-Federation/SAML between your application and ACS to sign in with a Google account. Google is using OpenId and non-SAML tokens, but ACS transitions into WS-Federation and sends back a SAML token. This way you application only needs to understand a single protocol whereas ACS acts as a protocol bridge (see my ACS2 sample here).

Another example would be transformation of a SAML token to a SWT. This is achieved by using the WRAP endpoint – you send a SAML token (from a registered identity provider) to ACS, and ACS turns it into a SWT token for the requested relying party, e.g. (using the WrapClient from Thinktecture.IdentityModel):

[TestMethod]

public void GetClaimsSamlToSwt()

{

    // get saml
token from idp

    var samlToken
= Helper.GetSamlIdentityTokenForAcs();



    // send to ACS
for SWT converion

    var swtToken
= Helper.GetSimpleWebToken(samlToken);



    var client
= new HttpClient(Constants.BaseUri);

    client.SetAccessToken(swtToken, WebClientTokenSchemes.OAuth);



    // call REST
service with SWT

    var response
= client.Get("wcf/client");

 


    Assert.AreEqual<HttpStatusCode>(HttpStatusCode.OK,
response.StatusCode);

}

There are more protocol transitions possible – but they are not so obvious. A popular example would be how to call a REST/SOAP service using e.g. a LiveId login. In the next post I will show you how to approach that scenario.