Single Sign-on (Part 1: Basics)
With each passing day we use more systems in our everyday lives, and memorising the complex passwords for each of those systems is a challenge many users face every day. Single Sign On (SSO) may be the solution to this issue.
What is Single Sign On(SSO)?
Single Sign On, also known as SSO, allows users to have access to multiple applications by signing in using only one account to different systems and resources. This is highly convenient for users, since, by identifying themselves just once, it is possible to maintain a valid session for the rest of the applications which use SSO.
Using the Single Sign On identification system, it is possible to have multiple accesses with a single account; for example, by signing in to Gmail we will have access to its various web applications, such as Google Docs, Google Maps, Google Books, etc. There are different types of implementations for SSO.
Simple cookie-based – Applications hosted on the same organization domain can share the authentication credentials stored as cookies.
Smart card-based authentication – Here the credentials are stored in your smart card. All you need to do is authenticate the password once and the smart card can provide access to all other applications.
Security Assertion Markup Language (SAML) – This is the most commonly used SSO implementation method in Pega.
With major social media explosion and excessive emergence of applications, most of which were built or started hooking with Facebook, LinkedIn, Google with the right authentication. All or most of these applications rely on Federated Identity in solving their login mechanisms.
What is Federated Identity?
Federated Identity is a way of centralising the authentication and authorization of users, i.e., linking a person's electronic identity and attributes, stored across multiple distinct identity management systems. There are three main protocols for federated identity:
SAML
OAuth
OpenID
SAML
Security Assertion Markup Language (SAML) is an XML-based framework for authentication and authorization between two entities aka SAML Providers:
Service Provider
Identity Provider.
A service provider needs authentication from the identity provider to grant authorization to the user.
An identity provider performs the authentication that the end-user is who they say they are and sends that data to the service provider along with the user’s access rights for the service.
SAML is a standard SSO format. Authentication information is exchanged through digitally signed XML documents. It's a complex SSO implementation that enables seamless authentication, mostly between businesses and enterprises. With SAML, you don't have to worry about typing in authentication credentials or remembering and resetting passwords.
OAuth
OAuth is an open-standard authorization protocol or framework that provides applications the ability for “secure designated access.” For example, you can tell Google that it’s OK for Pinterest to access your profile or post updates to your timeline without having to give Pinterest your Google password. This minimizes risk in a major way: In the event, if Pinterest suffers a breach, your Google password remains safe.
OAuth doesn’t share password data but instead uses authorization tokens to prove an identity between consumers and service providers. OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.
OpenID
A thorny problem for many organisations running a website is the registration process for new users. Consider, The marketing department wants to capture as much information about each new user as possible, but a lengthy registration form discourages people from signing up. The buying department is keen to get feedback via users’ comments, but who’s going to leave a comment that takes three minutes to write if registration takes five? Finally, the IT department may not have the in-house knowledge or resources to create a secure login process to store user passwords and data online.
One option may be to configure the login system to accept OpenID, but what is OpenID, and how does it work? OpenID allows users to sign in to multiple sites using just one identity, so users can sign in with an existing Facebook, Google, Yahoo, Twitter or other OpenID account. A new visitor to your site with an existing OpenID account doesn’t need to create another username and password or check his or her email for an account verification message, all of which are obstacles to getting people to register.
How OpenID works?
The OpenID protocol allows a user to prove he or she owns a specific URL. This URL can be used as an authentication credential, so when a site needs to know who a user is, the user can prove his or her identity with their OpenID URL.
The method of authentication may vary, but typically the site, known as the relying party, fetches the URL to discover who the OpenID provider is; it then uses Diffie-Hellman key exchange to establish a shared secret with the OpenID provider to sign messages between them.
If this is the first time a user is signing in using OpenID, he or she is redirected to the OpenID provider to sign in. The user is then redirected back to the relying party's site with an assertion that authentication was approved, which the relying party can verify.
SAML vs. OAuth
While OAuth is an authorization protocol, SAML (Security Assertion Markup Language) is a federated authentication protocol geared towards enterprise security. It is designed for use in single sign-on (SSO) scenarios, allowing a user to log in to various related systems and services using just a single ID and password.
Although SAML uses XML to pass messages and OAuth uses JSON, the real differentiator is that OAuth uses API calls extensively, while SAML uses session cookies. This is fine for accessing certain services during the working day but far less user-friendly for mobile apps, game consoles and IoT devices. OAuth 2.0 client registration is typically a one-time task. Once registered, the registration remains valid, unless the OAuth client registration is revoked.
OAuth vs. OpenID
OpenID Connect is an identity layer built on top of the OAuth 2.0 protocol. Whereas OAuth 2.0 permits a user of a service to allow a third-party application to access their data hosted with the service without revealing their credentials to the application, OpenID Connect permits a third-party application to obtain a user's identity information which is managed by a service. This functionality makes it easier for developers to authenticate their users across websites and apps without having to own and manage their passwords. Google Plus Sign-In is one platform based on OpenID Connect and OAuth 2.0 that developers can use to provide a secure social login experience for their users.
This post is just the basics we need to know before we jump into configuring SSO in Pega. We will know more about SSO in our future posts.
HAPPY LEARNING!