SAML
If you have ever heard of OAuth or OAuth2 , SAML is another standard to solve the same problem as OAuth and OAuth2 .
The problem that the above standards solve is called SSO (Single Sign On).
SSO arose from the problem when service providers wanted users to be able to use different services by just logging in to a single place, making it convenient to use as well as helping users. To keep username and password management to a minimum, there needs to be a way to authenticate and authorize user information without forcing them to create different accounts on different services.
Note: SAML automatically solves both authentication and authorization problems , but OAuth and OAuth2 only automatically solve the authorization problem (reference link here ).
SAML (Security Assertion Markup Language) is an "open standard" that allows the entity provider (Identity Provider - IdP) to authenticate users and authorize users to use certain services of the service provider ( Service Provider - SP) without requiring users to create an account to log in to that service.
The above definition will be difficult to understand, but if you know the " Log in with Facebook " button on some websites, the purpose of that button is the purpose of SAML .
How SAML works.
In the picture above: SP is the service provider (the application with the "Login with Facebook" button), IdP is the provider of entities (user account - IdP here is Facebook).
Step 1: The user will click on the "Log in with something account" button from the browser, this request will be sent to the SP .
Step 2: The SP will create a SAML Request to send to the IdP . This SAML Request will be digitally signed by the SP itself with the SP's signature (the SP's signature here is the SP's secret key).
Step 3: When the IdP receives a SAML Request from the SP , it will have to verify whether the signature belongs to the SP or not by using the SP's public key to authenticate:
Where does the IdP get the public key of this SP?
Before performing a transaction, the SP and IdP must somehow exchange public keys with each other first (not private keys ). Normally, each SP and IdP will have a public url containing metadata, this metadata contains public information such as public keys , entity IDs and URLs to navigate when a request arrives. The IdP side will know the SP's metadata url from which to retrieve the SP's public key to authenticate the SP's signature . In case the Idp 's system is available and cannot retrieve the SP's public key via metadata url , the SP must send its public key to the Idp to install before performing the transaction.
Step 4: Still in IdP , after verifying the SP 's signature , IdP will do the following:
Retrieve information about the user using the browser (if the user is logged in to the IdP , if the user is not logged in, force the user to log in first) to redirect (http post) back to the SP for use (results). I call this return SAML Response ). Before sending it to the SP , the IdP will digitally sign the SAML Response with the IdP's secret key .
Not only will the IdP sign the SAML Response , but the IdP will also encrypt the data results (SAML Assertions) contained in the SAML Response with the SP's public key.
Step 5: When the SP receives the SAML Response , it will do the following:
Use the IdP's public key to authenticate whether the result is sent from the IdP (this is the authentication part that OAuth and OAuth2 do not have). The IdP's public key , as mentioned above, can be obtained through the IdP's metadata url or can be exchanged in advance.
If the signature is authenticated correctly, the SP will continue to use its own public key to decrypt the encrypted SAML Assertions from the IdP side .
Retrieve user data information in SAML Assertions to log the user into your own system, and return the user a success notification (or navigate the user to the desired resources).
Last updated
