Authentication

As I mentioned in the purpose of this group, it’s to provide insight for people looking to implement an Identity Provider (IdP) or Identity Access Management (IAM). I’ll start with what I consider the highest priority is compliance of the IdP vendor to standard and their support of Single Sign On (SSO).

IdP/IAM and Service Provider (SP) Model

Security Assertion Markup Language (SAML) and Open ID Connect (OIDC) protocols enable the safe exchange of identity data between unaffiliated websites, are based on an IdP and SP model. A SP is an application which requires authentication from the IdP/IAM. When a user accesses a SP (cloud-based service), they are redirected to the trusted IdP or IAM for authentication. The IdP or IAM verifies the user’s authentication data (e.g. user’s cookie, device, network, OTP) and produces an “accept” or “reject” response which is then sent to the SP. The SP then authorizes access to the provided service. 

SAML

SAML, is an XML-based open standard for exchanging authentication data between unaffiliated websites, a capability also called identity federation or federated authentication. Identity federation means the ability to extend users’ current enterprise identities to the cloud, enabling them to log in to their cloud applications with their current enterprise identity. Federated authentication to cloud apps with SAML allows users to log in to all their cloud applications with their current enterprise identity, so that instead of maintaining 5 or 25 username-and-password sets, they can maintain just one. The sequence diagram for SAML is shown below.

The current SAML Specification is v 2.0 and can be found at saml.xml.org.

OIDC

OIDC, like SAML, OpenID Connect is an open standard identity federation protocol that uses an Identity Provider model. However, unlike SAML, which works using a cookie and therefore only works with applications that open in a browser (‘browser-based applications’), OpenID Connect provides a single-sign on framework that enables the implementation of single sign-on across browser-based applications, native mobile apps and desktop clients (such as rich clients and some VPNs). So while most single sign-on implementations today support only cloud and browser-based apps, as more identity providers adopt OpenID Connect, we’ll be able to authenticate just once in order to concurrently gain access to all our resources - be they desktop clients, browser-based applications or native mobile apps. The OIDC workflow is shown below.

The current OIDC Specification replaces OpenID 2.0 and can be found at Openid.net

Why are these important?

In today’s world of rapidly evolving technologies companies can not afford to bring in technologies that, once they are implemented, are impossible to replace. It has been my experience over the last 18 months that if an IdP/IAM conforms to either SAML or OIDC it can easily be removed and replaced by another IdP/IAM. There are several reasons a company may consider switching the IdP/IAM solution:

• Needing integration to applications that are not in the IdP/IAM’s App store
• Saving incurred when changing IdP/IAMs
• Performance of IdP’s support and facilities’ security

My next article with discuss provisioning users into the SP from the IdP/IAM. See Authentication vs. Authorization for the differentiation of what the IdP/IAM service does vs that of the SP.