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.
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 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 resource server is the API server used to access the user’s information.
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 resource owner is the person who is giving access to some portion of their account.
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:
SSO Services majorly uses two protocol
Flow of both the protocols is explained below with a diagram
Open Source Oauth/Openid Libraries
Open Souce Client Libraries
|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.
|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.|