SAML Basics
SAML (security assertion markup language) as the name suggests that it is a markup language used for security assertion. It helps in authorizing and authenticating the applications. It has three vital parts:
1. Identity Provider (IdP)
2. Service Provider (SP)
3. User
The process of authentication and authorization using SAML assertion can be understood using SSO (Single Sign-On) applications. These applications (ex: Okta, OneLogin) act as a single mode of login for multiple external applications (ex: SumoLogic, Slack) when requested by a user. It is carried out in two ways:
- When a user tries to access an application (ex: Slack) which acts as an SP. SP checks if the user is verified else it redirects to an IdP (ex: Okta). IdP then authenticates the user and generates a SAML token which will be communicated to the SP by identity management service. Once the user is authenticated user will be given access to the application.

Steps involved:
- Request login: User tries to log in to a remote application.
- Authentication Request: Application identifies the user login and requests the browser for verification.
- Check if Authenticated: Browser checks if it has authenticated details about the requested user.
- Authentication request redirection: If the browser doesn’t have a saved session it re-directs the authentication request to the identity provider.
- Request Login through IdP: Identity provider requests the user to login to the identity provider for authentication.
- Login using credentials: User logs in to the identity provider using user credentials of IdP.
- Generate SAML token: Identity provider now generates a SAML token using the user’s username or email address and signs with X.509 certificates and embeds in an XML response (SAML token).
- Send SAML token: Identity provider now sends the SAML token generated for the user to the browser.
- Send valid SAML token: Browser now stores the SAML token associated for the user and sends it to the service provider.
- Successful login: Service provider now uses its X.509 certificate to validate the token and allows the user to login to the remote application.
2. In the second case, the User tries to access an application (SP), but if the user is already verified then it directly gives access to the application (SP) without redirecting the user to the IdP.

Steps involved:
- Request login: User tries to log in to a remote application.
- Authentication Request: Application identifies the user login and requests the browser for verification.
- Check if Authenticated: Browser checks if it has authenticated details about the requested user. Since the browser has the session saved, it recognises the user.
- Send valid SAML token: Browser now sends the stored SAML token associated for the user to the service provider.
- Successful login: Service provider now uses its X.509 certificate to validate the token and allows the user to login to the remote application.
SAML Tokens: Is an XML document which consists of user claimed details from one entity to another entity which is signed by X.509 certificate. A user claimed details can be a user’s username or email address.

Things to note:
1. SP never holds the credentials of the user, it just knows who the user is based on SAML token sent by IdP.
2. SP and IdP never communicate directly with each other since IdP is an application and all the details will be stored in the browser which is hosting IdP. Hence browser is an entity that acts as a gateway between IdP and SP. More info on this can be found here.
3. IdP stores the credentials of the user when the user logs-in to the IdP to access SSO enabled applications.
