Before diving deep into SAML we must understand Single Sign-On is.
What Is Single Sign-On
Single sign-on is a method of logging in that lets a user enter in their login credentials (usually a username and password) just once and automatically be logged into multiple websites or applications.
What is SAML
SAML stands for Security Assertion Markup Language. It is a standard commonly used Single Sign-On (SSO). It is an XML-based open-standard for transferring identity data or authorization credentials between two parties: an identity provider (IdP) and a service provider (SP).
Identity Provider (IDP) — Performs authentication and passes the user's identity and authorization level to the service provider.
Service Provider (SP) — Trusts the identity provider and authorizes the given user to access the requested resource.
Example: Suppose you want to use Gmail, Hangouts and Google Docs we can call them service provider. Signing into all of them separately and remembering passwords for all of them seems very annoying. So, to solve this problem we will use SAML. Where we will only provide credentials to one Identity Provider in this case it would be Google and that IDP will allow us to login into Gmail, Hangouts and Google Docs without providing any credentials to them.
Basic SAML Terminology
- SAML Request - Also known as an authentication request, is generated by the Service Provider to "request" an authentication.
- SAML Response - It is generated by the Identity Provider. It contains the actual assertion of the authenticated user.
- Assertion - It is an XML document that has the details of the user which we've been discussing is transmitted from IDP to SP.
- XML Signature (DSig) – It is a Base64 encoded string which protects the integrity of the assertion.
- Assertion Consumer Service (ACS) - The URL location where the SAML assertion is sent.
- Attributes - This contains the information about the user such as their first name, last name or any other information might required for identifying the user.
- RelayState - This tells the SP where to take the user once they've successfully logged in.
SAML Authentication Workflow
At a basic level, a successful Service Provider Initiated SAML flow occurs as follows:
- The user navigates to the SP's login page and begins to log in.
- The SP then generates a SAML request and redirects the user to the appropriate IDP.
- Once the user is redirected to IDP they'll need to enter their credentials, unless they had already authenticated into IDP in a previous session within the same browser.
- On successful authentication request IDP will redirect the user back to the SP's Assertion Consumer Service (ACS) with an SAML response from IDP containing the authentication information needed by the service provider.
- After the response is successfully processed by the SP, the user will logs you in. After this user will be redirected to SP's default relay state.
Weak Points
SAML might be complex, but it can be secure if properly implemented. Let's look at some mistakes that could lead to disaster.
Flawed Validation
Message Expiration
SAML messages should contain a timestamp of when the request was issued, when it expires or both. If the SAML message never expires a malicious user could capture the SAML response and reuse it.
SAML Response Forwarding
An application should only accept a SAML response intended for the SP application. If the application does not perform this check, malicious user could pass a valid SAML response generated for an application to another application and allow it to login.
Flawed Signature Validation Mechanism
The SAML authentication mechanism relies on signature for maintaining its integrity and if they are not properly implemented this can leads to authentication bypass or account takeover.
Signature is not verified
If the ACS is not verifying the signature or not checking if its exist in SAML response a malicious user could try removing the signature value from the SAML response.
Signature is only verified if it exist
Sometimes service provider only verify the signature if it is present in the SAML response. If it's not being provided, in that case ACS simply skips the validation.
Flawed XML Parsers
The service provider processes the SAML response which is basically a XML document hence vulnerability exist in XML also exist in SAML such as XXE.
XML Comment Injection
XML can be quite complicated. Different XML parsers parses XML differently. A malicious user could leverage this problem and can create a account very similar to a admin account and can modify SAML assertions to change the NameID when processed by the SP.
XML Signature Wrapping Attack
Some implementations check for a valid signature and match it to a valid assertion, but do not check for multiple assertions, multiple signatures, or behave differently depending on the order of assertions.
Best Practices
- Limit the XML parser as much as possible when implementing Assertion Consumer Service.
- Use Canonicalized XML to normalize XML via specified algorithms.
- Validate the schema of the XML within the SAML response.
- Validate every signature and every assertion should be signed.
- Reject partially signed responses.
- Limit accepted encryption algorithms.
- Use only strong encryption algorithms.
- Validate Destination and AssertionConsumerServiceURL.
- Enforce Validation window so that no SAML response get accepted outside the mentioned time window.