This week, my colleague Ed King presented a webinar with Eve Maler (@xmlgrrl) from Forrester about why organizations should become identity providers. This is an important topic. Organizations are leaking identity. The path of least resistance is for an employee to use a SalesForce.com login, another SaaS service login, or even a Google Apps or Facebook login to log into a third-party site. The third-party site could be a B2B procurement hub, or a corporate travel service. In that case, the SaaS service becomes crucial as the IdP (Identity Provider) which enables the user to log into the service. This is undoubtably good for the SaaS service, which is why so many are becoming IdP by supporting standards such as OAuth 2.0 and SAML. But what about the organization itself? Would it not be better for the organization to to stop the identity leakage and become an IdP itself?

In the webinar, Ed and Ruth talked about why organizations should become IdPs. But the next question is how. The Vordel API Server makes this easy.

OAuth 2.0 and SAML are two key standards used to become an IdP. They enable a token to be issued, based on a user's login. Let's look at OAuth 2.0 first:

The Vordel API Server comes with a prebuilt OAuth 2.0 sample. In this sample, you can see a sample app asking the user to authorize a connection to a third-party service. In the example below, I've setup an organization to use the Vordel API server to act as an IdP by authenticating the user against a corporate Active Directory, and then to prompt the server to allow a third-party site to access their information.This results in user being issued an OAuth 2.0 Access Token, and the third-party site receiving an OAuth 2.0 bearer token.

Here is how I'm authenticating the user against a corporate Active Directory then redirecting them to the OAuth 2.0 services:

You can see an example of the bearer token below in the Vordel API Server traffic monitor:

And here's the policy on the API Server which validates the OAuth 2.0 bearer token:

Now let's look at the SAML use case. SAML is often used, in this content, to issue a signed SAML Authentication assertion for the IdP to assert that the user has been authenticated. The policy below, in the Vordel API Server, allows an organization to act as an IdP by authenticating a user against a corporate Active Directory and then issuing (and signing) a SAML Assertion:

Here is how the Active Directory connection is configured (note the long list of other identity connectors in the Vordel API Server):