Single Sign on – Part 1 – Understanding
In this blog article, we will see the basics about single sign-on (SSO) mechanism and the common configuration for single sign-on. Warning!! Only theory!
What is single sign-on?
It is an authentication process, where one set of login credential provides access to multiple applications.
It helps in 2 ways
a) You don’t need to have separate credentials for separate applications because the risk of forgetting the password is high
b) You don’t need to re-enter the password again and again for all the applications you sign in.
Authentication tokens will be passed seamlessly at the backend for all the configured applications.
There are certain risks involved with single sign-on as well, because you get the master key and gets access to many doors! This can be misused!
I am not going to talk about looking inside someone door 😉, let’s get back to the business!
Now let’s see the mechanics behind SSO
There are different types of implementations for SSO
1. Simple cookie-based
Applications hosted on the same organization domain can share the authentication credentials stored as cookies.
2. 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.
3. Security Assertion Markup Launguage (SAML)
This is the most commonly used SSO implementation method in Pega.
What is SAML?
Security Assertion Markup Language – is an XML based framework for authentication and authorization.
SAML is a open standard SSO format. When I say standard, it means you don’t need to worry if it will work with all platform specific implementations! It adheres to its own best practices and can be trusted!
All the authentication information is exchanged through digitally signed XML documents.
Usually SAML performs the authentication and authorization between two entities or the SAML providers– Service Provider and Identity provider.
What is Service provider?
A service provider is basically as system or an application that needs authentication from the identity provider to grant access to the users.
Pega application which uses SSO authentication can be related to the service provider.
So, service providers usually depend on the identity provider for authentication and trusts them blindly!
What is Identity provider?
An identity provider is a trusted one that generates authentication assertion that determines the user has been authenticated.
It returns the authorization for the user to the service provider.
There are many SAML identity providers currently in the market.
Few notable ones are
- Active directory federation service (ADFS) from Microsoft
- Keycloak from JBoss
- OpenAM from ForgeRock (This is the open source one which I will using for this tutorial 😊)
- Oracle Identity Federation services from Oracle
- Also lot of cloud providers have their own Identity services (like Microsoft Entra ID in Azure)
Now you know the Identity providers service the service providers with the authentication details.
Let’s look out the sequential background steps involved between the two entities during an SSO SAML transaction.
Step 1: User enters the application URL, say pega SSO URL.
Step 2: The service provider or the pega application redirects the request for IdP via the browser.
Step 3: Browsers sends the request to IdP SSO URL
IdP verifies if the user is already authenticated in the system (This means the user might have already identified via other application login).
If No, the IdP challenge the user to provide the login credentials
Step 4: In a happy path, The IdP returns the SAML response to the browser
Step 5: The browser sends the SAML response to the Assertion Consumer Service (ACS) URL.
Step 6: Finally, the user gets logged in to the application from the browser.
All these steps execute at the backend in a fraction of a second 😊
Let’s see a familiar SSO implementation by Pegasystems!
Important note: The below steps were executed and captured years, before!!
Step 1: Login into the PDN – https://community.pega.com/
Step 2: Navigate to Pega support portal link.
Make sure you fix your eyes on the browser URL link field. It keeps on changing!
Step 3: Once you are authenticated, then You will see the support request portal.
Actually, the MSP – My Support Request is a Pega application that use the SSO credentials of your PDN.
The URL for the MSP application is – https://msp.pega.com
Let’s do some incognito work 😉
Step 4: Hit the MSP URL – https://msp.pega.com in the browser incognito mode. Again watch the browser URL fields
Step 5: Here you go! You caught the Identity provider red handed 😉
Note: You may note recently Pega has used Open ID SSO authentication!
The server – http://uag.pega.com/sso-gateway is the IDP server
In the Incognito mode, your pdn credentials are not passed from the browser and hence the IDP – Identity provider fails to authenticate the user and throws the challenging screen.
Step 6: You can enter your PDN credentials and click login
Step 7: You will see the SAML response gets passed to the Assertion Consumer Service URL.
And then finally you will be authenticated!!
Hope you get the basics of how SAML works. I touched only very basic stuffs. I recommend you to read some articles or watch some cool youtube stuffs about how SSO works!!
This is a very small post!! Calm before Storm!!! 😛
Keep reading 😉
