SSO
Last updated
Last updated
SAML (Security Assertion Markup Language) is an open standard for exchanging authentication and authorization data between parties, specifically between an identity provider (IdP) and a service provider (SP). SAML is widely used for enabling single sign-on (SSO) capabilities across different applications and services.
Identity Provider (IdP): The entity that authenticates a user and issues authentication assertions. Examples include Okta, Google, Microsoft Azure AD, and others.
Service Provider (SP): The entity that provides the service the user wants to access. It relies on the IdP to authenticate the user. Examples include various web applications and services. Clear for this use-case.
EntityID: It is a unique identifier for a SAML entity (such as an Identity Provider or a Service Provider). It is an important part of the SAML metadata, serving as a way to uniquely identify and distinguish between different entities in a SSO deployment.
ACS (Assertion Consumer Service)/ ReplyURL: Its is a specific endpoint on the Service Provider (SP) side that handles SAML assertions sent by the Identity Provider (IDP). The ACS URL is where the IDP sends the authentication response (SAML assertion) after a user successfully authenticates.
Assertions: Statements about a user that include authentication, attribute, and authorization information. These assertions are formatted in XML and are transmitted between the IdP and the SP.
IDP Metadata: (Identity Provider Metadata) is a structured XML document that contains configuration details about the Identity Provider (IdP). This metadata is crucial for establishing trust and communication between the Identity Provider and the Service Provider (SP) in a SAML-based Single Sign-On (SSO) setup.
In the context of Single Sign-On (SSO), "Service Provider Initiated" (SP-initiated) and "Identity Provider Initiated" (IDP-initiated) are two different ways to start an authentication process. Here’s an explanation of each:
Process:
User Action: The user first attempts to access a resource or service on the Service Provider (SP) side (e.g., a web application).
Redirect: The SP detects that the user is not authenticated and redirects the user to the Identity Provider (IDP) for authentication.
Authentication: The user authenticates at the IDP.
Response: After successful authentication, the IDP sends a response (usually containing a SAML assertion or JWT) back to the SP.
Access Granted: The SP processes the authentication response, creates a session for the user, and grants access to the requested resource.
Flow:
User → Service Provider → Identity Provider → Service Provider.
Use Case: This flow is common when users try to access specific services or applications directly.
Demo Video:
Process:
User Action: The user starts the process at the IDP, often by logging into a central dashboard or portal provided by the IDP.
Select Service: From the IDP interface, the user selects the desired Service Provider/application they want to access.
Authentication: If not already authenticated, the user authenticates at the IDP.
Response: The IDP sends an authentication response (usually containing a SAML assertion or JWT) directly to the SP.
Access Granted: The SP processes the authentication response, creates a session for the user, and grants access to the requested resource.
Flow:
User → Identity Provider → Service Provider.
Use Case: This flow is common when users have a central place (like a corporate login portal) where they start their work and access multiple applications.
Demo Video:
ClearTax Support team should be reached out for the SAML setup.
This is a 3 step process:
Client needs to share the list of allowed domains. (eg clear.in, gmail.com)
ClearTax Support team will share the below resources required for setting up the SAML
EntityId
ACS / ReplyURL
CT SignOn Page - *Required only in case of SP initiated.
Relay State
Using the above data, IDP metadata should be generated and shared back to ClearTax team.
A: There can be couple of reasons for 404:
Verify IdP Metadata:
Double-check the IdP metadata XML file to ensure that the URLs for the SSO and SLO endpoints are correct.
Ensure that the Entity ID, SSO URL, and any other endpoints specified in the metadata are correct and match the actual configuration on the IdP
Review RelayState:
Make sure the relay state is configured properly in IDP settings. If it is not set, make sure to generate metadata again.
Look for the setting related to the NameID format.
Ensure that the NameID format is set to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress or a similar format that specifies email addresses.
Read this document for more understanding -
