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.
