IdP Vs SP Initiated SSO | Understanding IdP Initiated login

SAML Authentication

SAML stands for Security Assertion Markup Language. It is an XML-based open-standard for transferring identity data between two parties: an identity provider (IdP) and a service provider (SP).

Identity Provider (IdP)

The user credentials and other identifying information are stored and managed by a centralized system called Identity Provider (IdP). The Identity Provider is a trusted system that provides access to other websites and applications. An identity provider is the one that authenticates user xyz as user xyz after credentials are entered.

An IdP provides authentication services to relying applications. Through this, you can use Single Sign-On (SSO) to access other websites. miniOrange Identity Server ( IdP ) provides centralized, simple management and synchronization of identities for users, devices, and things. It is highly flexible and therefore able to fit almost any use case and workflow. It is designed as a unified

Service Provider (SP)

A service provider provides services to the end-user. Service providers rely on identity providers to assert the identity of a user, and typically certain attributes about the user that are managed by the identity provider. In simple words, service providers do not authenticate users but instead request authentication decisions from an identity provider. l account for the user along with attributes that are unique to their service.

IdP initiated VS SP initiated SSO

The IdP determines if the Windows session exists and gets the credentials of the currently logged-in user. It generates a SAML Response.

The user’s identity and attributes are managed by an Identity Provider (IdP). And the application user wants to login and access is your service provider(SP).

SP-Initiated Login

The request to login is initiated through your application for which you want to access.
The user is redirected to the IdP, where you can see a miniOrange login page to authenticate users
The IdP determines if the Windows session exists and gets the credentials of the currently logged-in user. It generates a SAML Response.
With the help of a SAML response from IdP, miniOrange SSO service logs in the user to applications.

IdP-Initiated Login

In IDP initiated login The user logins directly to the IdP instead of the application dashboard.
With the help of SAML response from IdP, logs in the user to applications.

Trust established between the user and SAML Authority

SAML transactions use Extensible Mark-up Language (XML) for standardized communications between the identity provider(IdP) and service providers(SP). SAML is the link between the authentication of a user’s identity and the authorization to use a service.

Users logged into a system that acts as an Identity Provider(IdP), users want to login to a remote application, such as a support or accounting application(Service Provider).
The application identifies the user’s login & redirects the user back to the IdP asking for an authentication request.
The user establishes a browser session by login into the Identity Provider (IdP).
IDP builds the authentication response in the form of an XML document containing the user’s username or email address & posts this information to the SP.
SP which already knows the IDP & has a certificate fingerprint retrieves the authentication response & validates it.
The Identity of the user is established & the user is provided with app access.
- SAML is a very general framework that will be used in a wide variety of environments. It is up to relying parties to decide what asserting parties they trust for what purposes.

IdP-initiated SSO with SAML Authentication

In this scenario, users first log in to their dashboard, which presents an application catalog. This catalog will contain visual icons of all the internal and external applications that the admin has configured SSO for their end-user and that the end-user has privileges to access those applications. Only configured external and internal applications are visible in the end-user dashboard when you try idp-initiated sso.

When the user clicks on any of the application icon visible , the SAML flow is as follows:

The SAML IdP takes the user’s identity, along with any other attributes that the IdP and SP agree to communicate.
It builds an XML-based document called SAML Assertion. This includes the information sent by the identity provider(idp) to service provider(sp).
IdP signs the SAML assertion with the private key of a public/private keypair that was exchanged between the IdP and SP when the SSO trust was established.
IdP either sends the SAML assertion to the SP via the user’s browser session or sends a reference to the SAML assertion that the SP can use to retrieve the SAML assertion securely.

SP-initiated SSO with SAML Authentication

SP-initiated SSO starts when a user tries to access an application at the service provider(sp) end, but hasn’t yet authenticated from Idp. A user may have visited the site directly . Once the SP sees that the user doesn’t have any browser session active , it will redirect them to the Identity provider(IdP) asking for the authentication request.

The IdP will authenticate the user, create the SAML assertion and redirect the user back to the SP just as in the IdP-initiated sso use case.

How come SP knows which IdP to redirect the user to? if it supports a single sign-on from more than one IdP.

These are the ways how the SP can determine which IDP to redirect the users to:

The SP may ask the user identity such as the user’s email address and use the domain of the same, such as jon@miniorange.com, to determine which Identity Provider (IdP) to use from multiple configured IdPs.
The SP will show the user a list of IdPs it supports and ask the user to select the one IdP from which they want to authenticate themselves.
The resource URL may be specific to one IdP.
The SP may have restored a cookie containing IdP information in the user’s browser session the first time the user successfully logged in from the IDP and will use this user’s information on further subsequent accesses.

Once the SP has received the SAML assertion, it validates the signature using the public key in order to ensure the SAML assertion really came from the trusted IdP and no attributes have been modified in SAML assertion. The SP can then extract the user’s identity from the SAML assertion along with other attributes that’s needed. At this point, the user is on the service provider’s landing page, just as though they had logged into the site manually.

Conclusion

SAML is a very general framework that will be used in a wide variety of environments. It is up to relying on parties to decide what asserting parties they trust for what purposes. For example Company A might trust Company B to tell it if an individual is an employee of Company B, but does tell if the employee has a secret clearance. Trust Relationships must be established out of the bond.

For the SP initiated SSO, the user navigates to the service provider (application), the service provider sends a SAML request to the IdP, the IdP sends a response with SAML assertion to SP, the SP signs in the user through a web browser.

Whereas for the idP initiated SSO the user enters his credentials at IdP login page, IdP sends an SAML assertion to SP and the SP signs in the user through a web browser.