SSO login in Java

1.    Introduction

This document describes an approach to implement the Single Sing On to Product Suite.

2.    Intended Audiences

This document is indended for the developers, designers and architects who would like to understand the approach to implement the Single Sign On to a Kewill product using WSO2 Identity server and SAML 2.0 Protocol.

3.    Prerequisites

Jdk 1.5 or above

OpenSAML libraries

WSO2 Identity Server

Please note that the WSO2 IS version 5.0.0 and below does not support JAVA 8, download latest version 5.1.0 as of 13 June 2016, if you are working with JAVA 8.

4.    SSO Solutions

There are two different kind of single-sign-on solutions: delegated and federated.

4.1  Delegated Authentication

A delegated solution means that one site is simply outsourcing its authentication needs to another pre-selected site. If your site uses Facebook Connect, you are delegating your authentication facilities to Facebook. Visitors to your site cannot use any other accounts, only accounts from the vendors you have pre-selected.

4.2  Faderated Authentication

A federated solution means that visitors to your site can use any account they have, as long as it is compatible. It makes no difference to the site which account is being used, as long as it can interoperate. At its core, OpenID is a federated solution because its most important feature is the ability to use any OpenID account with any OpenID-enabled service

Delegated authentication has a few drawbacks with respect to federated authentication, Delegated authentication is inherently less secure than federated authentication.Delegated authentication requires more work for the company implementing it

5.    SSO Protocols

There are many protocols in the market to implement SSO like SAML, OpenId, Oauth, Higgins, Windows Cardspace, MicroId and Liberty Allowance.

There are three major protocols for federated identity: OpenID, SAML, and OAuth.

5.1  OpenID

OpenID is an open standard sponsored by Facebook, Microsoft, Google, PayPal, Ping Identity, Symantec, and Yahoo. OpenID allows user to be authenticated using a third-party services called identity providers. Users can choose to use their preferred OpenID providers to log in to websites that accept the OpenID authentication scheme

The OpenID specification defines three roles:

·         The end user or the entity that is looking to verify its identity

·         The relying party (RP), which is the entity looking to verify the identity of the end user

·         The OpenID provider (OP), which is the entity that registers the OpenID URL and can verify the end user’s identity

The following diagram explains a use case for an OpenID scenario:

Security Considerations

OpenID had a few interesting vulnerabilities in the past, for example:

1.    Phishing Attacks: Since the relying party controls the authentication process (if necessary) to the OpenID provider, it is possible for a rogue relying party to forward the user to a bogus OpenID provider and collects the user’s credentials for the legal OpenID provider.

2.    Authentication Flaws: In March 2012, three researchers presented a paper that highlighted two vulnerabilities in OpenID. Both vulnerabilities allow an attacker to impersonate any user to a website if the website doesn’t properly check whether the response from the OpenID provider contains a properly signed email address.

5.2  SAML

Security Assertion Markup Language (SAML) is a product of the OASIS Security Services Technical Committee. Dating from 2001, SAML is an XML-based open standard for exchanging authentication and authorization data between parties.

The SAML specification defines three roles:

·         The principal, which is typically the user looking to verify his or her identity

·         The identity provider (idP), which is the entity  that is capable of verifying the identity of the end user

·         The service provider (SP), which is the entity looking to use the identity provider to verify the identity of the end user

The following diagram explains a use case for a SAML scenario:

Security Considerations

1.    A group of researchers presented a paper in 2011 where they used an XML Signature Wrapping vulnerability to impersonate any user

5.3  Oauth2

OAuth is another open standard. Dating back to 2006, OAuth is different than OpenID and SAML in being exclusively for authorization purposes and not for authentication purposes.

The OAuth specifications define the following roles:

·         The end user or the entity that owns the resource in question

·         The resource server (OAuth Provider), which is the entity hosting the resource

·         The client (OAuth Consumer), which is the entity that is looking to consume the resource after getting authorization from the client

The following diagram explains a user case for an OAuth scenario

Security Considerations

1.    A session fixation vulnerability flaw was found in OAuth 1.0. An attacker can fix a token for the victim that gets authorized. The attacker then uses the fixated token.

2.    OAuth 2.0 was described as an inherently insecure protocol since it does not support signature, encryption, channel binding, or client verification. The protocol relies entirely on the underlying transport layer security (for example, SSL/TLS) to provide confidentiality and integrity.

5.4  Other Protocols

There is a growing number of other federated identity options. Here are a few examples. 

Higgins: Higgins is a new open source protocol that allows users to control which identity information is released to an enterprise.

Windows CardSpace: CardSpace is Microsoft new identity metasystem that provides interoperability between identity providers and relying parties with the user in control. This protocol is retired though and Microsoft is working on a replacement called U-Prove.

MicroID: MicroID is a new identity layer to the web and microformats that allow anyone to simply claim verifiable ownership over their own pages and content hosted anywhere.

Liberty Alliance: Liberty Alliance is a large commercially oriented protocol providing inter-enterprise identity trust. It is the largest existing identity trust protocol deployed around the world

5.5  Difference between OpenId, SAML and Oauth

The table below explains the major differences between the three protocols:

	OpenID	OAuth	SAML
Dates from	2005	2006	2001
Current version	OpenID 2.0	OAuth 2.0	SAML 2.0
Main purpose	Single sign-on for consumers	API authorization between applications	Single sign-on for enterprise users
Protocols used	XRDS, HTTP	JSON, HTTP	SAM, XML, HTTP, SOAP
No. of related CVEs	24	3	17

6.    SSO Implementations

There are many SSO implementation frameworks available in the market like OpenAM, CAS, JOSSO, CloudSeal and WSO2 Identity Server. Based on the Kewill’s requirement analysis to implement SSO to Kewill Product Suite we have chose the WSO2 identity server, below are the features of it.

·         API for integrating identity management to any application

·         Multi-factor authentication

·         Single Sign-On (SSO) via OpenID, SAML2, and Kerberos KDC

·         SSO bridging between on-premise systems and cloud apps

·         Credential mapping across different protocols

·         Auditing via XDAS

·         Delegation via OAuth 1.0a, OAuth 2.0, and WS-Trust

·         Federation via OpenID, SAML2, and WS-Trust STS

·         Integration with Microsoft SharePoint with Passive STS support

·         Implement REST security with OAuth 2.0 and XACML

·         XKMS for key storage and distribution

·         Implement REST security with OpenID Connect

·         Trusted SAML2 Identity Providers per tenant

·         Out-of-the-box integration with Google Apps and Salesforce

·         Customizable login pages for OpenID, OAuth, OpenID Connect, SAML2, and Passive STS

More information can be found here http://wso2.com/products/identity-server/ .