IAM in AWS

 

                                   

                    SAML Authentication

SAML is an XML based framework that stands for Security Assertion Markup Language. Let us see how SAML is used to enable SSO (Single-Sign-On). SSO is a term used for a type of login method where a company configures all of its web apps in such a way that the user can log in to all of these apps by just signing in once.

Example – When one logs in on gmail.com, they can visit YouTube, Google Drive, and other Google services without having to sign in to each service separately.

The SAML authentication flow is based on two entities –

1. Service Providers (SP) – The SP receives the authentication from the IdP and grants the authorisation to the user.
2. Identity Providers (IdP) – The IdP authenticates a user and sends their credentials along with their access rights for the service to the SP.

In the example given above, SP will be Gmail and IdP will be Google. SAML enables SSO, and as it is explained above, a user can log in once and the same credentials will be used to log into other SPs.


SAML Authentication Workflow –

1. A user tries to log in to Gmail.
2. Gmail generates a SAML request.
3. The SAML request is sent to Google by the browser, which parses this request, authenticates the user and creates a SAML response. This SAML response is encoded and sent back to the browser.
4. The browser sends this SAML response back to Gmail for verification.
5. If the user is successfully verified, they are logged in to Gmail.

SAML Request –

Some of the important terms in the SAML request are defined below –

1. ID – Identifier for a particular SAML request.
2. Issuer – The name of the service provider (SP).
3. NameID – The username/email address or phone number which is used to identify a user.
4. AssertionConsumerServiceURL – The SAML URL interface of the SP where the IP sends the auth token.

SAML Response –

A SAML response consists of two parts –

1. Assertion –
   It is an XML document that has the details of the user. This contains the timestamp of the user login event and the method of authentication used (eg. 2 Factor Authentication, Kerberos, etc.)
2. Signature –
   It is a Base64 encoded string which protects the integrity of the assertion. (If an attacker tries to change the username in the assertion to the victim’s username, the signature will prevent the hacker from logging in as the user).

Key Generation –

The Identity Provider (IdP) generates a private key and a public key. It signs the assertion with the private key. The public key is shared with the Service Provider (SP) which uses it to verify the SAML response and then log the user in.


SAML Vulnerabilities Exploited by Hackers –

1. Signature not checked –
   If someone is able to change the name id (username) in the SAML response and log in as someone else due to the lack of a signature checking process.
2. Signature only checked when it exists –
   If someone changes the name id value and removes the signature before the response is received by the browser and is still able to log in as the victim.
3. Comment Injection –
   A user can be registered with an XML comment in the username as follows –

   email: prerit<!--notprerit-->@test.com

   While processing the SAML response, the SP will ignore the comment and log us in as the victim. The entire SAML response can be intercepted by using a proxy like a burp suite. Note that it has to be decoded first by the URL format and then by the Base64 format in order to be viewed.

4. SAML Replay –
   The attacker captures the SAML response and uses it multiple times to log in as the victim.