SINGLE SIGN ON (SSO)

Single sign-on (SSO) is a high level concept that permits a user to use one set of login credentials (e.g., username and password) to access multiple applications. The service authenticates the end user for all the applications the user has been given rights to and eliminates further prompts when the user switches applications during the same session. On the back end, SSO is helpful for logging user activities as well as monitoring user accounts.

Thus, SSO is an authentication/authorization flow through which a user can log into multiple services using the same credentials.

A single sign-on solution is meant to reduce cost of management,provides better security and an improved user experience.

Important Roles needed in SSO

The Third-Party Application: “Client”

The client is the application that is attempting to get access to the user’s account. It needs to get permission from the user before it can do so.

The API: “Resource Server”

The resource server is the API server used to access the user’s information.

The Authorization Server

This is the server that presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.

The User: “Resource Owner”

The resource owner is the person who is giving access to some portion of their account.

SSO FRAMEWORK

SSO Server uses identity server and open id connect protocol to complete the authentication process.

An Identity Provider is a server that can provide identity information to other servers. For example, Google is an Identity Provider. If you log in to a site using your Google account, then a Google server will send your identity information to that site.

SSO Framework should act as an identity hub that supports many Identity Providers using various protocols (like OpenID Connect, SAML, WS-Federation, and more).

It should sit between your app and the Identity Provider that authenticates your users. This adds a level of abstraction so your app is isolated from any changes to and idiosyncrasies of each provider’s implementation.

The identity servers can be of 4 types:

1. Social like Google, facebook, amazon, basecamp, linkedin etc (using Oauth/openid protocol)
2. Enterprise like Ldap, Sharepoint access, Ping federate, Active dorectory, Ws-federation ec (using SAML protocol)
3. Database like MongoDB, MySQL, Oracle, PostgreSQL, SQL Server, Windows Azure SQL Database etc
4. Password less like touch id, sms, email etc

SSO Services majorly uses two protocol

1. Openid for authetication/ Oauth For access control
2. SAML federated authentication and authorization

Flow of both the protocols is explained below with a diagram

SAML FLOW:

Open Source Oauth/Openid Libraries

Gluu Server 3.1.1

• The Gluu Server is a free open source identity and access management platform for single sign-on, mobile authentication, and API access management that includes a comprehensive implementation of an OpenID Connect Provider and Relying Party
• MitreID (with OpenID Connect)
• Spring Security OAuth
• Apis Authorization Server (v2-31)
• Restlet Framework (draft 30)
• Apache CXF
• Tokens: Java library for conveniently verifying and storing OAuth 2.0 service access tokens.
• Light OAuth2 – The fastest, lightest and cloud native OAuth 2.0 microservices

Open Souce Client Libraries

• Spring Social
• Spring Security OAuth
• Restlet Framework (draft 30)
• ScribeJava
• oauth2-essentials
• Light Java Client
• Google OAuth Java Client

Learn SSO Terminology

The information presented in this topic refers to the self service Learn SSO feature. If you have a custom SSO built by the Oracle Learn Cloud Services team, and you are looking for assistance, please refer to any documentation they have provided.

This topic provides an overview of terminology you will need to understand for the Learn SSO feature.This terminology not new in general. You can find much more information about all of these terms on the Internet. We have provided some URLs pointing to sites that provide deeper documentation on these subjects. This additional reading is purely optional. Your IT (Information Technology) Department will have a good understanding of the concepts presented here.

• SSO – Single Sign-On. Allows Users to sign on in one website or system and automatically be signed on in another website or system. For example, a User could sign on to your internal intranet site and then click a link to access the LearnCenter without having to sign in to LearnCenter as well. See http://en.wikipedia.org/wiki/Single_sign-on for a detailed description of Single Sign-On.
• SAML – Security Assertion Markup Language. In order for an SSO to be secure, the system that receives login requests has to be able to verify the source of those requests to ensure they are valid. For example, the LearnCenter server has to verify that the request really is coming from your intranet server. SAML is a standard data format used for exchanging the data between the two parties in an SSO. If you are unfamiliar with the term SAML, you can find information here: http://en.wikipedia.org/wiki/SAML.
• SAML Metadata – The metadata used to make SAML work. Additional reading can be found here: http://en.wikipedia.org/wiki/SAML_2.0#SAML_2.0_Metadata
• IDP – Identity Provider. An IDP is the mechanism that validates Users trying to access a website using SSO. For example, when Users access LearnCenter from their company’s Intranet site, an IDP verifies whether those Users have valid LearnCenter User accounts before allowing them access to LearnCenter. Additional reading can be found here: http://en.wikipedia.org/wiki/Identity_provider
• SP – Service Provider. A company or entity that provides web services. In the case of Learn, your service provider supplies your LearnCenter URL. Additional information can be found here: http://en.wikipedia.org/wiki/Service_Provider
• IdM – Identity Management. The information system or set of technologies that manages individual identities, their authentication, authorization, roles, and privileges within or across a system or enterprise.
• Additional reading can be found here: http://en.wikipedia.org/wiki/Identity_management
• Deep Linking – Use of a URL to access a searchable or indexed piece of content on a website without having to first access that information from the home page. For example, an email message could contain a URL to a particular page within LearnCenter. Clicking it can take you directly to the page if you have already signed in using SSO. Additional reading can be found here: http://en.wikipedia.org/wiki/Deep_linking

Deep linking is supported with end User and Supervisor information, as well as links within Communication Messages, Notices and Notifications. Deep linking to the Control Panel can be done if you are not using the Management password to control User access to the Control Panel. Oracle Learn Cloud does not officially support Deep Linking into the Control Panel at this time because the Management Password which controls user access into the Control Panel is not supported in the SAML standards. Deep Linking to the Control Panel will currently work if you are not using a Management password for Control Panel access, but be aware that if issues are encountered with an unsupported Control Panel Deep Link, Support will not be able to assist you.

• RelayState – A parameter used to support Deep Linking. When a User attempts to access a LearnCenter page by a deep link to a location other than the default home page, the Learn SSO passes to the identity provider the URL that the User is linking to through the Relay State parameter. The SAML relay state parameter is an optional configuration with most identity management systems, and is required to be implemented on the IDP for deep linking to be supported. In the relay state the URL passed from the LearnCenter (Service Provider) to the IDP must be returned to the LearnCenter in the Relay State parameter in the exact same format as it has been provided. See Deep Linking in the bullet point above for additional information.