What is SAML?
SAML is a (XML) open standard for the digital mechanics when performing and sharing Authorization and Authentication between two parties, namely (SP) Service Provider and (IdP) Identity Provider.
How does the SAML Work?
1. User initiates a request to a resource (www.mybankApp.com)
2. (SP) Service Provider picks up the request (should be from behind a API gateway protected by a WAF and Edge controls) , checks to see if the request needs to be authenticated, if so the SP will send a SAML request to the IdP via the users browser.
3. Users browser forwards the SAML request to the IdP.
4. IdP sends a HTTPS request to the user with a SAML authentication request. User responds with valid authentication credentials (USER && PASS && OTP).
5. If authentication is successful the IdP will send a response back to the SP via the users browser.
6. User browser forwards to the authenticated response back to the SP to request the restricted resource.
7. SP will check if the authenticated user has the rights to access the resources if so an authenticated session will be established with the user and resource via the SP.
Key Terms relating to SAML
|IDP||Identity Provider responsible for Authentication|
|SP||Service Provider responsible for managing authorisation of resources.|
|SAML Request||Issued from SP to user’s browser for redirecting to IdP|
|SAML Response||Trusted response sent from SP to requestor with access to the requested resource or failed response with no access to the resource. Should always be signed by a private key|
|Assertion||Secure encrypted XML entity with sensitive data|
|XML Signature (DSIG)||Typically a configuration of a shibboleth library within the SP to carry out hashing|
|Attributes||User attributes encrypted within an assertion|
|Relay State||Used for pre authed users requests, set to use once to stop replay attacks|
|SAML Trust||Trust store and configuration for certificates. (Certificate Trust configuration)|
|Metadata||XML Configuraiton files for discover and configuration convenience.|
What is SAML used for?
It’s basically a standard way of using XML to facilitate SSO.
SAML is used to authenticate users in a (SSO) Single Sign On scenario. As we explained more technically above, it passes user identity credentials between a SP and IDP such as Azure AD.
SAML can be configured to be IdP initiated or SP initiated these are the 2 uses case flows for SAML. Both have different use cases:
Use case 1 IdP Initiated: Used for protected resources, only a valid authenticated response is needed to access the resource.
Use case 2 SP Initiated: is used to access the resource directly, the SP will determine if the user is needed to authenticate before accessing the resource. If the resource is protected (non public data) a request will then be sent to the IdP in order for the user to authenticate first with the IdP in order to create the correct assertion to be sent to the SP to allow access to the resource.
A modern based cloud architecture for SAML SSO via application proxies with AAD on Azure Cloud.
SAML Architecture is based on existing standards such as:
- XML Schema (XSD)
- XML Signature – Both SAML 1.1 and SAML 2.0 use digital signatures (based on the XML Signature standard) for authentication and message integrity.
- XML Encrytpion – SAML 1.1 does not have encryption capabilities, 2.0 uses encrypted attributes but has severe security concerns
- Hyper Text Transfer Protocol (HTTP) – Core protocol used in the SAML sequence flow.
- Simple Object Access Protocol (SOAP) – SAML specifies the use of SOAP, specifically SOAP 1.1
Security Concerns & Best Practices for SAML
Denial of Servicce (DOS) – Parsers should be reviewed for unused functions, design review of the request creation and parsing technologies used.
Flawed assertion validation – Signature checks, Assertion Consumer Service insecure configuration, Trust Store, SAML Response validation
XML Parser – Unused functions, known vulnerabilities, Document Type Definition (DTD) Fetching see XXE. Canonicalized XML (comment stripping)
XXE – XML External Entity (Injection) – Due to the fact that SAML Responses are deflated and base64’d XML documents, we can test for XXE by manipulating the XML document sent as the SAML Response. Example:
Schema Validation – Signature Wrapping (XSW) Attacks, Signature Validation & Function Validation, Explicit Expressions
Validate Every Signature – Limit Algos (SHA256), None =(,
HTTPS – Not self signed
Validate Parties – Destination, Issuer, Recipient,
Validation Window – Session Time
Historical Cache – No Duplicates (Replay Attacks)
Limit Buffer Size – DOS, Biuffer Overflow.