Identity providers and their protocols

By | March 21, 2018

Within the enterprise arena it is common to have a Identity provider for the organization. In this post I have a brief look at the industry standard protocols.

The idea behind the identity provider is to provide the users working at the organization with single sign-on capability so that they do not have to sign into every single application that they wish to use, instead their credentials are forwarded and accepted based on the trust between the target application and that of the Identity provider.

Here are some of the enterprise Identity providers that I have encountered.

The other benefit of an Identity provider is that it can speak multiple protocols and translate from one to the other. This allows an organization to save money when it comes to integration between enterprise level applications. The most common protocols in the industry at the moment are Ws-Federation and SAML. Both of these are claims based authentication protocols which means that the authenticated users identity is passed back to the requesting party.

I have covered in some detail how to create your own Identity provider and how to integrate with WS-Federation but have not shown any SAML examples up to this point. .Net does not have any native support for SAML 1 or 2 and so to integrate using SAML requires he use of 3rd party components like that from ComponentSpace.

Ws-Federation is viewed as the more easy to implement between the two while SAML is viewed as the more secure and complex. The two protocols work very similar with very minute differences between them unfortunately their terminology is not the same. Some of the definitions for WS-Federation and SAML can be found here.

OAuth is another that have been trying to break into the market of the enterprise level of the Identity provider but it is still mostly viewed as Social Sign On protocol used by Facebook, Linked-in, Twitter and Google. It is different from the other protocols in that it does not provide the requesting application with the identity of the user using claims instead it is more access control based around a token. Instead of authentication the user authorizes an application to use its information. Each OAuth Identity provider has its own API that must be followed to retrieve the user information so implementing OAuth is not a one fit, fits all approach.  I have covered OAuth in a POC I did here.

Leave a Reply

Your email address will not be published.