Identity federation is the key to addressing these concerns. A lot of people assume identity federation is the same thing as Single Sign-On (SSO), where a single identity is used to authenticate a user across multiple services, applications and platforms. In fact, SSO is just one piece of the identity federation puzzle, albeit an important one.

Our new white paper, Federated Identity & Single Sign-On Using Layer 7, examines all the key pieces of this puzzle. It takes a detailed overview of the technologies that can be used to merge separate “identity silos” into a centralized, authoritative identity store (SAML, STS, OAuth etc.) It also explains how our products can be used to implement these technologies.

For more information, read Federated Identity & Single Sign-On Using Layer 7

For those of you who haven’t seen my previous OAuth 2.0 tutorials, I should explain that the OAuth Toolkit provides a number of OAuth template implementations that can be imported into our Gateways in order to apply OAuth. This template integrates into existing environments by connecting with identity providers and APIs.

This week, I’m explaining the OAuth 2.0 SAML grant type. This grant type is defined in an OAuth extension specification (draft-ietf-oauth-saml2-bearer-09), which defines another grant type not included in the core OAuth specification. This grant type describes how a client application uses a SAML bearer assertion to obtain an OAuth access token.

Although this specification does not describe how the client application obtains the SAML assertion in the first place, the tutorial does use a test application to provide an example in which the user is forwarded to a SAML identity provider which authenticates the user, issues a SAML assertion and redirects the user back to the application. The application then uses this redirected SAML assertion to obtain an access token from the Layer 7 Gateway’s OAuth authorization server endpoint.

Tutorial 4: The SAML Grant Type