Identity

SAML

SAML is an open standard that allows an Identity Provider to pass signed authentication assertions to applications, enabling Single Sign-On.

Security Assertion Markup Language (SAML) is a standard for logging in via an Identity Provider. It enables Single Sign-On between organisations and applications.

How it works

A person opens an application that supports SAML. The application redirects them to the Identity Provider. There, the person signs in. The IdP creates a signed authentication assertion with details about the person. The application checks the signature and grants access without another password. SAML is based on XML and is common in enterprise applications.

For example, a company connects its HR system to Entra ID using SAML. Employees sign in with their company account. When a person leaves, blocking the central account is sufficient. New logins are blocked immediately. Existing sessions run until they expire, depending on the application.

What to look out for

  • Protect the IdP's signing certificate with great care. Anyone who possesses it can forge valid logins.
  • Monitor changes to SAML configurations and certificates.
  • Watch out for expiring certificates. An expired certificate will lock out all users.
  • Deactivate local accounts in the application when SAML is active, except for protected emergency accounts.
  • Check if the application validates assertions correctly.

Known attacks

In a 'Golden SAML' attack, attackers steal the signing key of an on-premises Identity Provider, such as AD FS. They use this to create valid logins for any account. Such attacks have been observed in major security incidents. Flaws in how applications check signatures provide another attack vector.

How it differs from OpenID Connect

SAML is older and XML-based. OpenID Connect is built on OAuth 2.0 and uses JSON. New applications often use OpenID Connect. However, many enterprise applications still mainly support SAML.

Typical mistakes

Often, new trust relationships or certificates in the IdP are not monitored. Attackers with admin rights can then create their own login paths unnoticed.

How we implement it

We monitor changes to federations, certificates, and trust relationships in your IdP. We treat such changes with high priority.

How ANOMAL implements this