Single-Sign-On (SSO) capabilities with Identity Providers
Exclusive for the folks having enthusiasm in Identity Access Management
Is there anyone fresh into the IAM domain, there are some crucial concepts to learn. Even if in a very abstract approach anyone can define simply IAM as just user management, login, and registration. Yes, it’s true. However, as long as you are working in this domain you should have to have a better understanding of IAM. Therefore the following blog is exclusive for absolute beginners of this domain.
“Identity and access management (IAM) is a framework of business processes, policies, and technologies that facilitates the management of digital identities.” — TechTarget
In the IAM domain, there are some common terms like “Authentication”, “Authorization”, “Access Control”, “Authorization Server”, “Identity Provider” and “Single-SIgn-On” etc. As an IAM Developer, you should have a better idea regarding the above terms. Let me describe them one by one as follows.
Authentication
Who is the current user and in other words the identity of the current user? Checks whether the given user credentials are validated or not. In contrast, Authentication checks the validity of the user as the user said.
Authorization
Authorization is going to happen after successful authentication. What the user can do / what is the access level that the user has within the application. It always evaluates the right user having the right access to a certain resource in the right period of time. In more contrast, authorization means granting permission to do something.
But there is a common misunderstanding still, Access Control term does not mean exactly about Authorization.
Access Control
Control or add some constraints to access certain entities towards the protected resources. There are a lot of types of Access Control. Mandatory Access Control (MAC), Discretionary Access Control(DAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC). Same as above we can divide Access Control into another aspect called Fine-Grained and Coarse Grained. I hope to discuss more Access Control in my upcoming blogs.
Identity Provider
Simply a kind of database that stores users’ identities. But this is just not only a database. Identity Provider (IdP) creates centralized governance to handle Access Control access to various business applications both internally and externally. Using an IdP, developers can reduce the cost of development and maintenance overhead due to user management. In summary, an IdP can provide user registration, user login, password reset options, Two-Factor/Multi-Factor verification, Adaptive Authentication, Federated Authentication Account disabling features, and many more. So developers no need to worry about implementing the above features inside of the business applications. The only thing that they have to do is, just invoke the IdP functionalities inside the application. The rest will be taken care of by the IdP.
Why IdP?
Businesses and their information technology teams face greater regulatory and organizational demand to secure access to business resources. As a result, they are no longer able to assign and track user credentials using manual and error-prone processes.
Considering history one of the most popular Identity providers has been Microsoft Active Directory. It was introduced in 1999. It was running on On-Premises and specifically designed to manage windows usernames and passwords. Subsequently, it connected with the other windows resources. However, with the enhancement of Cloud Computing, the modern enterprise has been moved into the virtual hosted infrastructure. Therefore traditional IdP s like Microsoft Active Directory were struggling to keep continuing.
WSO2 Identity Server
WSO2 introduced their IdP as WSO2 Identity Server. It provides enterprise-grade features such as identity federation, single sign-on (SSO), robust and adaptive authentication, account management, and identity provisioning to assist digital-native enterprises in becoming integration agile via API security. It can deploy On-Premises, Public/Private Cloud governance, bare-metal hardware, virtual machines, and containerized environments.
Identity as a Service (IDaaS) IdP s
In late 2014, the JumpCloud CEO announced the invention of the world’s first-ever Directory as a Solution. (DaaS) It was a SaaS-based offering. Using DaaS organizations were able to transform their IT services from On-Prem servers to Cloud. A core tenant of DaaS is that it is the single, secure directory store for an organization. Later Microsoft launched an extended version of Microsoft Active DIrectory called Azure Active Directory (AAD) based on Azure Cloud Platform and it is an IDaaS (Identity as a Service) solution.
The term “Identity-as-a-Service,” or IDaaS, refers to a broad range of cloud-based IAM services. Essentially, IDaaS is a group of cloud-hosted technical operations that deal with the user identity. Providers of identity as a service (IDaaS) assist guarantee that users are who they claim to be, preventing cyber thieves and other unauthorized users from accessing critical data. Well, the next question that pops up in your mind is how an IDaaS solution is going to provide the identity as a service?
Just a simple answer. The IDaaS solution will operate as tenants in the public cloud. Recently WSO2 has announced their IdaaS solution as Asgardeo. WSO2 Identity Server is utilized by several businesses worldwide, including Fortune 500 companies. Asgardeo combines these experiences and capabilities into a modernized, cloud-native, developer-focused Identity as a Service (IDaaS) environment, enabling users to take advantage of the cloud’s benefits.
Single-Sign-On (SSO)
SSO enables users to sign in to many applications using a single account rather than maintaining a separate login for each application. It couldn’t be possible unless having an IdP configured.
Need of SSO
SSO can minimize the cost of login each application again and again. Hence it can enhance the end-user experience as well. Modern enterprises couldn't limit their business to just within one or two applications. Those consumer applications should be connected one to another. THerefore without SSO, there is no centralized governance in authentication to a series of applications in the same domain. Also using an IdD, developers can shift Identity as a layer on top of the consumer application.
Once a user has logged into the HR application via a web browser, the HR application delegates the authentication control to the IdP. Because there is a mutual trust between IdP and consumer application. (HR) According to the implementation either IdP can send consent screens to the browser or IdP can redirect HR applications to the browser by asking for the user credentials.
As we discussed earlier, there should be mutual trust between IdP and Service Provider. (Business Application or HR) I will use the HR term here onwards for the Service Provider. The dotted line shows that pre-defined trust.
First will take a look at 1st diagram. (IdP provides a login screen) Note this is neither IdP initiated flow norSP initiated flow. Click here for more info
- Browsers access the HR application directly.
- 2. HR application delegates the authentication request to the IdP.
3. Once an authentication request is received to the IdP, the IdP sends login consent to the browser.
4. User provides the credentials to the consent screen.
5. IdP validates the credentials and if valid, sends a successful authentication response to the browser. (Browser will save the response as a cookie)
6. For future logins, Sales and Finance applications do not ask to login again and again since the above cookie is there.
Note: IN the 5 the step of 1st diagram and the 3rd step of the 2nd diagram, once the browser received the valid session from IdP browser again create another session that can be uniquely identified by the browser itself.
The only difference between the 2nd diagram is it is going to redirect the HR application back to the IdP without asking anything from IdP (02ns step of the 2nd diagram). You may have experienced the same thing, once you try to login into a certain application if you have used Microsoft O365 login there, your application will pass a query string with the browser URL. Then within the service provider’s domain, your browser redirects the application URL to the IdP login screen. Then you have to provide your user credentials there.
So hope you have learned something new. Let’s catch up in the very next episode. Otherwise, the content getting more and more :)
