Single Sign-On (SSO) is a popular method for simplifying authentication across multiple applications, and the SAML (Security Assertion Markup Language) protocol is widely used to implement it. While Service Provider (SP)-initiated SSO is the more common approach, there is also the IDP-initiated SSO flow, which can offer some distinct advantages, particularly in use cases where the authentication is initiated by the Identity Provider (IDP) rather than the Service Provider (SP).
In this article, we will describe the basic high-level flow of the IDP-initiated SSO process, outlining the interaction between the key components: the End User/Browser, Service Provider (SP), Identity Provider (IDP), and the Identity Store (LDAP).
Components in the IDP-Initiated SSO Flow
Before we dive into the flow itself, let’s first define the key components involved in the SSO process:
End User/Browser: The end user’s browser is the interface through which the user interacts with both the Service Provider and the Identity Provider.
Service Provider (SP): The application or service that the user wants to access. The SP relies on the IDP to authenticate the user.
Identity Provider (IDP): The system responsible for authenticating users and providing assertions to the SP. The IDP holds the authentication credentials for users and works with an Identity Store to validate these credentials.
Identity Store (LDAP): A directory or database that stores user credentials and identity-related information. The IDP queries the LDAP to verify user credentials.
High-Level IDP-Initiated SSO Flow
Unlike the SP-initiated flow, where the SP triggers the authentication process, in the IDP-initiated SSO flow, the authentication process begins at the Identity Provider. Here is a step-by-step breakdown of the process:
1. User Accesses the IDP Portal
The end user begins by navigating directly to the Identity Provider's portal. This portal serves as the centralized login page where users can authenticate themselves.
- Action: The user opens the IDP's login page in their browser.
- Eg: https://www.pingfederateIDP.com/partnerSPID=salesforcepayment
2. User Authenticates with the IDP
Once the user reaches the IDP portal, they are prompted to authenticate by entering their credentials, such as a username and password. The IDP then checks these credentials against the Identity Store (LDAP) to validate the user’s identity.
- Action: The IDP queries the LDAP identity store to verify the user’s credentials (username, password, etc.).
If the user is authenticated successfully, the IDP generates a SAML assertion. This assertion contains the user’s identity information, such as their username, roles, and any other attributes that might be relevant for access control at the SP.
- Action: The IDP generates a signed SAML assertion containing the user's identity attributes and authentication details.
3. IDP Redirects the User to the SP with the SAML Assertion
After successful authentication, the IDP needs to send the SAML assertion to the SP to authorize the user there. The IDP packages the SAML assertion in an HTTP POST message and sends it directly to the SP.
This redirection happens automatically, and the user’s browser is used to transmit the SAML assertion to the SP. This is what differentiates IDP-initiated SSO from the SP-initiated flow, where the user typically clicks on a link to begin the authentication process.
- Action: The IDP redirects the user’s browser to the SP with the SAML assertion in the form of an HTTP POST.
4. SP Validates the SAML Assertion
Once the SP receives the SAML assertion from the IDP, it needs to validate it. This validation process includes:
- Checking the digital signature of the SAML assertion to ensure it was issued by the trusted IDP and has not been tampered with.
- Verifying the time validity of the assertion to prevent replay attacks.
- Ensuring that the assertion is intended for the SP and that it has not expired.
Once the SAML assertion is validated, the SP uses the information in the assertion to authorize the user. This can include user details, roles, and other attributes to determine the user's permissions and access rights.
- Action: The SP validates the SAML assertion and extracts the necessary user information.
5. SP Grants Access to the User
Once the SP validates the SAML assertion and establishes the user’s identity, it grants the user access to the requested resource. The SP may create a session for the user, and the user can access the application without needing to reauthenticate for subsequent requests.
- Action: The SP grants the user access to the requested resource or application.
6. User Accesses the Service
The user is now successfully authenticated and authorized by the SP, and they can continue their session without needing to provide credentials again, as long as the session remains active.
- Action: The end user can interact with the SP and access the application.
0 comentários:
Post a Comment