saml-2.0 Getting started with saml-2.0 The SAML2.0 authentication flow
Example
SAML specifies three key roles:
-
The Identity Provider (IdP)
The party which provides and maintains the identity of the users. This can be a directory service like ADFS or a custom database solution.
-
The Service Provider (SP)
The Service Provider is the actual service which the user tries to login to. This can be a website, an application or any service a user ought to be required to login to.
-
The principal / the user
The actual user initiating the request, or trying to access a resource from the Service Provider (SP).
The main SAML use case is Web Based SSO, where the SAML process is conducted by a set of redirects within the users' browser, where the user acts as the token carrier between the IdP and SP.
There are two flows for Web Based SSO using SAML:
-
Identity Provider (IdP) Initiated
The user logs into the IdP and is then forwarded to the SP of choice. E.g. a user logs into a corporate intranet and is presented with all available applications.
-
Service Provider (SP) Initiated
The user tries to login to an application, but is forwarded to the IdP to perform the actual authentication. E.g. a user tries to login to a remote SaaS application, but is forwarded to a corporate IdP so the user can login with their corporate credentials into the remote application.
The SP initiated flow is visualized greatly by the workflow below:
Source: Wikipedia
- A user tries to access a resource on a specific application or webpage
- A user specifies (s)he tries to login using an external IdP. The SP will generate a SAML assertion, and will pass this along (usually through POST or GET variables) while forwarding you to the IdP
- The user will authenticate itself against the IdP
- The signed assertion and token are generated by the IdP
- The signed assertion and token are forwarded back (again using POST or GET variables) to the SP and if successful a session is initiated on the SP
- and further the user is able to request further resources from the SP while it has an active session with the SP (i.e. through cookies) so it does not have to authenticate with the IdP on every request.
