SAML — What to check for?

SAML Validation and Pen testing.

This guide introduces the minimum requirements during validation and pen test of SAML implemented in your application.


Nowadays one of the most common ways of authentication is SAML (Security Assertion Markup Language). This is one of the ways in which we can implement Single Sign On into our applications. There are basically two parties involved in SAML. One is the Identity Provider (IdP) such as Okta, Microsoft SSO, DUO etc. The other one is Service Provider (SP), for example JIRA. The Identity Provider as the name suggests is the one responsible to authenticate the identity(user) requesting access. The Service Provider is the application for which an identity(user) wants access.


a. Let’s say John Doe wants to use the application JIRA. He visits JIRA.

  • Authorization Assertion: This indicates whether the user agent is authorized to access the requested service. If the message indicates access is denied, it indicates why.
  • Attribute Assertion: Attributes can be any information about the user agent.

What to look for


  1. SAML response expiration: Check the message for timestamps, such as an IssueInstant or NotOnOrAfter assertion. The message is supposed to expire and become useless after that time. SP should not provide session token if expired SAML response is passed.
  2. Message Replay: Assertions should contain a unique ID that is only accepted once by the application. Try replaying a SAML message to create multiple sessions.
  3. Missing Signature: If there is a SignatureValue field present that contains a signature, try to resend the message without a signature.
  4. Invalid Signature: Signatures which are not signed by a real CA are prone to cloning. Ensure the signature is signed by a real CA. If the certificate is self-signed, you may be able to clone the certificate or create your own self-signed certificate to replace it. Tool SAML Raider on burp.
  5. SAML from Different Recipient: An application should only accept a SAML message intended for the SP application. The Recipient attribute found on the SubjectConfirmationData element is a URL that specifies the location to which the Assertion must be delivered. If the Recipient is a different Service Provider than the one who receives it, the Assertion should not be accepted.
  6. Signature Wrapping: 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. The following are eight of the most common XML Signature Wrapping attacks. You can edit the original SAML file manually to perform these attacks but it is much quicker with the use of a tool. The short names (ex: XSW1) map to the names used in the SAML Raider tool, discussed below.
  1. Change the expiration date on an expired message to make it valid again
  2. Change the UserId to a different valid user — Bonus points if that user is an admin
  3. Change the UserId to a different invalid user — Sometimes an application will grant default permissions or higher privileges to an unmapped user


Recommended — Use in-built libraries for SAML implementations. This will prevent manual validations and logic writing.

  1. Understanding the SP- initiated SAML Flow or IdP initiated SAML flow.
  2. Do you want to enable SAML for Single User or subset of users or everyone?
  3. How to expose SAML configuration on SP.

Security in SAML

  1. Only admin should have control over enabling- disabling the username password-based authentication or any changes to PII.
  2. Session Timeouts must be enforced -set session expiry value to be the SAML Response NotOnOrAfter value. Set the session expiry value to logout time, when Forced session timeout occurs.
  3. SAML must not be replay-able, maintain an ID token to verify against it. Check against the ID token to see if SAML is replayed.
  4. Check the SAML response value against the IDP. If it is coming from the expected Identity Provider, before even checking the username.
  5. Make sure the redirect is done to the expected page after SAML authentication. Use SAML RelayState parameter to check for this.
  6. Validate the SAML signature using the IdP Cert provided in the SAML response. To make sure it is not tampered with.
  7. Follow Secure XML guidelines provided by OWASP. SAML responses and assertions should be constructed using an appropriate XML library that can safely set user-controlled data in attributes and text nodes. XML Validation and XML Encoding must be in place. SAML Signature and their validation is the best way to detect tampering and prevent XML Attacks.

IdP Configuration

Entity ID: <EntityDescriptor entityID=” /dashboard”>

  1. ACS Validator: Regex to validate if assertion is sent to correct ACS.
  1. RelayState : Where to take the user after a successful login.
  2. SAML Algorithm: SHA-256. Less commonly SHA-384 or SHA-512. This algorithm is used with the X.509 certificate.

SP Configuration

  1. X.509 Certificate — A certificate provided by the IdP. It allows the SP to verify the SAML assertion is coming from the IdP it trusts. SAML assertions are usually signed, however SAML requests can also be signed. Download from IdP and paste it in SP.
  2. Issuer URL — Unique identifier of the IdP. <saml: Issuer></saml: Issuer>
  3. SAML SSO Endpoint — Service Provider Login URL.
  4. SAML SLO (Single Log-out) Endpoint — An IdP endpoint that will close the user’s IdP session when redirected here by the SP, typically after the user clicks “Log out.” This will help logout users not only from SP but from IdP as well.


The above article is combined from various resources and sole purpose was to keep things at one place. Concise and precise.



OSCP | CEH | Cyber Security Enthusiast.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store