Picking the right SSO technology

Authored by: Vinayak Raghuvamshi, AVP, Engineering, Uniken

As you may already know, Single sign-on (SSO) is the facility by which a user can gain access to multiple sites using just a single log in. The simplest mechanism to enable SSO is through cookies but its effectiveness is questionable. The other widely used mechanism of enabling SSO is through Light-weight Directory Access Protocol (LDAP).

Picking the right SSO technology for your enterprise is critical and if done without proper analysis, could create costly vulnerabilities. SSO is becoming very important to enterprises and as per Gartner, “Through 2016, Federated Single Sign-On Will Be the Predominant SSO Technology, Needed by 80 Percent of Enterprises” and as per Forrester, “Password problems and resets constitute 25% to 40% of all support cases”.

Your enterprise stands to benefit with significant, tangible benefits by just the proper implementation of an SSO solution.

At the heart of SSO is the concept of ‘Federated Identity’. The most accepted definition of federated identity is “A federated identity in information technology is the means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems”.

In this article, we will discuss SSO using three Federated Identity standards: OpenID, OAuth, SAML and one proprietary protocol (RMAK).

OpenID

In simple terms, OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords. OpenID is an open authentication standard that is not controlled by any single entity or server. It is supported by a volunteer community of developers who maintain, test and add features to the protocol. Users can choose any OpenID provider (OP) as the service manager of their online identity (the keeper of your keys) and a unique OpenID URL which serves as the identifier of the end-user. OpenID is rapidly gaining adoption on the web, with over one billion OpenID enabled user accounts and over 50,000 websites accepting OpenID for logins. (As quoted on the OpenID website).

Highlights of OpenID:

• Simple and Light weight

• Easy to use and deploy. You can even make your own website into an OpenID provider

• Secure key exchange (using Diffie-Hellman)

• Protocol is Open source and free

Pros of OpenID:

• User ids are globally unique (URLs)

• Ability to share reputation and track usage across sites

Cons of OpenID:

• As it relies on a second site for sign-in, OpenID is open to phishing attacks

• It is not API and Mobile friendly

• Forces us to put a lot of trust in the identity provider

Google has announced that it will stop supporting OpenID based SSO. It instead recommends using OpenID connect.

OpenID Connect (OpenID over OAuth)

OpenID Connect is being termed as ‘the new SSO protocol for the Internet’. It is OpenID 2 over OAuth 2. It is supported by many major vendors including Google, Microsoft, Yahoo, AOL and Salesforce. OpenID Connect provides both, delegated access and federated identity in one protocol and is designed keeping in mind the needs of mobile and other standalone clients in addition to browsers.

Both, OpenID and OpenID Connect try to solve the same problem but in different ways. OpenID Connect uses standard JSON Web Token (JWT) data structures when signatures are required. In contrast, OpenID uses XML. JWT is easier to use for developers and is also much more interoperable with different providers. At its heart, OpenID connect believes in a ‘password less’ authentication and is readily in alignment with FIDO alliance.

OAuth is an access granting protocol (also known as delegation) and is a separate topic in itself. In the context of this article, I would like to mention that OpenID connect uses multiple ‘flows’, a term inherited from OAuth terminology. There are three main flows for OpenID Connect to do the authentication which is decided by looking into the 'response_type' value of the authorization request. The three authentication flows are Authorization Code Flow, Implicit Flow and Hybrid Flow.

Authorization Code Flow

Authorization code flow does not provide any access token to the client. Instead, it gives an authorization code which can be directly exchanged to an ID token and an access token. The authorization server is capable of authorizing the client only after this exchange is complete.

Implicit Flow

In Implicit flow the ID token and access token are directly returned to the client. When using the implicit flow authorization, the server does not perform client authentication. This flow is mainly used by web browser clients such as scripting clients.

Hybrid Flow

When authentication is done using the hybrid flow, some of the authentication tokens are returned from the authorization endpoint and some of them are returned from the token endpoint.

As of today, it is preferable to use Implicit Flow because that has the widest support and acceptance and has a high probability of working right out of the box. Some Microsoft middle wares use the Hybrid flow and we need to work with this flow on a case by case basis.

Highlights of OpenID connect:

• The tokens used are “ID Tokens” of JSON Web Tokens which can be cryptographically signed

• It is capable of performing dynamic registration

• It has full support for JWT

• It provides options for discovery via the OpenID Connect Discovery protocol

• It manages user information endpoints that can be used to retrieve information about the authenticated user

Pros of OpenID connect:

• It is Interoperable
• It is Flexible
• It is Simple and Mobile friendly

Cons of OpenID connect:

• The access tokens can get really long, especially when they are encrypted.

• To enable revocation control, the access tokens need to have short expiration times, resulting in many refresh token requests at the OAuth 2.0 server.

• The server handling the protected resource must have the necessary tools and infrastructure to validate signatures and perform decryption of encrypted access tokens and to manage the required keys. The server needs to be more capable than the ones that handle just plain OpenID.

Security Assertion Markup Language (SAML)

Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content. (Definition taken from Google).

In SAML, instead of passwords, applications that use SAML accept secure tokens which only reveal what is required to access the application.

There are three main players in SAML:

1. Service Provider (Resource Server) - this is the web-server you are trying to access
2. Client / User – typically, a web browser
3. Identity Provider (Authorization Server) - this is the server that owns the user identities and credentials. Users authenticate with the Identity Provider

Pros of SAML:

• There are many advertised advantages of SAML like Platform neutrality and loose coupling of directories. In general, it shares most of the advantages of a good SSO solution

• Apart from this, as SAML has been around for many years, there is a strong support from the open source community. OpenSAML is a good example:

(https://wiki.shibboleth.net/confluence/display/OpenSAML/Home)

Cons of SAML:

• One of the biggest cons of SAML is that it is not mobile friendly.

• SAML requires SSL certificates to provide digital signing and encryption of assertions. So, SAML inherits the vulnerabilities/cons of SSL.

Uniken’s RMAK based SSO:

Uniken provides a custom SSO solution that enables enterprise customers to seamlessly integrate their applications with SSO support. The biggest advantage of Uniken’s SSO is that it does not depend on SSL and all authentication related calls happen through a military grade secure connection (that uses proprietary RMAK protocol).

Conclusion:

In general, such http based mechanisms all share a few common weaknesses, like being vulnerable to phishing attacks, man-in-the-middle, message leakage, and replay attacks. As a mitigation, some of the protocols use SSL/ TLS. But then, both SSL and TLS are already broken.

Here is where a strong and secure protocol like RMAK comes in handy.

After reviewing the various options, the two that seem to be worthy contenders are:

1. If you want SSO across enterprises, OpenID Connect (OpenID over OAuth2) and

2. If you are more concerned about enterprise wide SSO, RMAK wins hands down