In this article, we'll explain what SAML SSO is, how it works, and clarify some common misconceptions.
In this article, we'll explain what SAML SSO is, how it works, and clarify some common misconceptions.
Introduction
This article delves into the Security Assertion Markup Language, more commonly known as SAML – one of the most widely used single sign-on (SSO) methods. We’ll be covering:
What is SAML
How it’s used
Technical details of its implementation, and
Security-related issues.
What is SAML?
Security assertion markup language (SAML) is an open standard for exchanging authentication and authorization data between an identity provider (eg. Microsoft 365, Google Workspace, Okta) and an application (the service provider or SP).
SAML is one of the most common and widely used protocols that enable single sign-on (SSO) for enterprise-level services and can be used in both authentication or authorization contexts by providing assertions to claims. In other words, SAML authentication can be used to affirm that a user has been authenticated by an identity provider. Assertions can also include (but are not limited to) group or role membership properties that determine what a user can access in an application.
As expected from SSO implementations, SAML provides the ability for administrators to manage a user’s access to an application from a central point. This makes onboarding and offboarding tasks simpler, and reduces the overall number of identities that need to be managed for users.
What happens during a SAML authentication flow?
Without getting into the deep technical details of SAML, below is a simplified version of what happens when a user initiates the logon process against an app that is configured for SAML authentication.
A user attempts to access a resource or app.
They are redirected to the IdP with a SAML request.
The SAML identity provider (IdP) authenticates the user.
If authentication is successful, the IdP creates a SAML assertion that contains the requested attributes, such as the email address, group membership information, first name, and last name.
The SAML assertion is returned to the SP, and is signed by the IdP with a certificate configured during the initial configuration.
The SP verifies the response, and if it validates the signature, access is granted to the user based on the assertions.
An interesting side note: at no point does the IdP directly communicate with the SP; the user’s browser facilitates all actions by contacting the respective services and providing the requests, as well as the SAML response that ultimately grants the user access to the requested resources.
An example where this could be useful, or potentially abused by internal employees or attackers, would be enabling a third party internet-based IdP to allow access to resources within your internal network.
SAML responses and assertions
The SAML response is what an app requires to verify before granting the user access, and is generated by the IdP when a user requests to access resources. During the initial SAML configuration setup performed on the IdP, the administrator would specify which attributes are to be included in the assertion portion of the response that is returned to the app.
One required attribute included in each SAML response is “Subject”, typically set to the email address of the user, and specifies which account the assertion is for. However, this can be set to reflect other values like User Principal Names (UPNs) or other unique strings, depending on the requirements.
Depending on the app, the list of attributes may vary significantly and is usually the first time where administrators may run into configuration issues, either by not including all required attributes or by incorrectly mapping attributes to names.
A typical SAML response is Base64 encoded and included as a POST request to the SP. Below is an edited version for a user attempting to log into Okta via SAML, with Google Workspace as the IdP. As SAML responses contain plenty of information, I’ve broken it down into sections to cover it in an easier manner:
Destination, issuer, and status
Right at the top of the SAML response we have the “Destination” and “Issuer” statements. “Destination” is typically the app or SP where the SAML response is meant to go, and the “Issuer” is the service that created the response. In this case, we can see that the destination is for our Okta tenant, and it originated from our Google Workspace tenant. The status of the response is also included to signify whether the request to the IdP was successful.
Assertion issuer and signature information
The assertion starts with another Issuer statement, which in this case is our Google Workspace IdP. This is followed by the signature generated to verify that the contents of the assertion have not been tampered with. You can also note the “X509SubjectName” statement which includes information about the certificate used by the Issuer.
Subject
As mentioned previously, the “Subject” attribute is required and always included in the assertion. The NameID format is specified, and in this case is the “emailAddress” format. The “Recipient” value is usually synonymous with the “Destination” attribute.
Attribute statement
Lastly, the “AttributeStatement” is provided which contains any other attributes returned as part of the assertion. The contents of this statement will vary based on the app’s requirements and what the administrator has chosen to include when users initiate the authentication process.
One final note is that the above attribute names are not necessarily congruent between the IdP and app. Usually as part of the setup process the administrator will be given the opportunity to map attributes to names if necessary.
As an example, the IdP could refer to the email attribute simply as “email”, but the app or SP is expecting it to be named “User.Email”. If this is misconfigured, the SAML login process will fail, and likely without a sufficiently descriptive message indicating what the issue is. In such cases, it is best to review logs of the app.
SAML sounds great! What’s the problem?
SSO Tax
From our own experience, only about 30% of apps support SAML. Even then, it is typically held behind enterprise plans and pricing which makes it prohibitive in many situations. It’s not generally possible to rely on it for gaining control of identities in use within your organization. Depending on the app, it may be possible to use OIDC (which is a type of SSO.)
Security
SAML is usually seen as the go-to for improving identity security in organizations. However, if an attacker were to compromise your IdP it can result in widespread account compromise, and due to the nature of SSO, the attacker will have access to any account the user is able to access without further effort. This should not be taken as a criticism of SAML as this is the nature of SSO, but merely something to be aware of when responding to incidents.
At Push we’ve spent a lot of time looking at technology related to SaaS and found a few issues that could expose your organization to vulnerabilities when using SAML. One such vulnerability is SAML enumeration which allows an attacker to determine whether a target organization is in fact using SAML for authentication, and which IdP they are using.
Another attack you should be aware of is SAMLjacking. SAMLJacking occurs when an attacker configures a legitimate app such as Nuclino and sets the ACS URL to point to a fake login page. Designing the fake login page to look like your enterprise IdP will deceive users into entering their credentials into this phishing page and can lead to credential theft.
In this blog post, Push’s VP of R&D goes over combining the SAMLjacking technique with other techniques, such as poisoned tenants.
These attacks don’t directly manipulate the SAML protocol as with XML injection attacks and are more to do with using legitimate services to perform unintended functions.
Single Sign-On?
Luckily when you configure SAML for an app it solves the issue of users sharing credentials between services, right? Nope! During our research we’ve come across many apps that allow users to continue using other methods of authentication even after SAML has been configured.
When enabling SAML you may be given the ability to disable other methods of authentication such as login via email (username & password), and OIDC/social login methods. However, this varies between providers and there is no guarantee that you will be able to disable other login methods, or whether you’ll even be aware that this is an issue.
For more information on this subject, see ghost logins.
Conclusion
Hopefully you will have a better understanding of SAML, how it works, where it can go wrong, and what to be aware of when investigating related incidents.
While SAML has been around since the 1990s and can be considered a legacy service at this point, it’s very much still part of enterprise authentication and authorization solutions. Other technologies such as OAuth2 & OIDC have provided alternative ways for providing SSO while addressing some of the issues, such as the ability to specify permission scopes when integrating with an app.
Understanding SAML’s limitations is the first step toward tackling the wider issue of identity management. Push provides the means to gain visibility into the types of apps used in your organization, their login methods, and MFA status. Push will also let you see when users are using other login methods for apps which you may not be expecting.