Making Headlines: SAML

March 19, 2018

On February 27, 2018 the CERT Division of Carnegie Mellon University’s Software Engineering Institute issued advisory #475445, outlining a design flaw in Security Assertion Markup Language (SAML) implementations, which affects various Single Sign-On (SSO) software and several open source libraries meant to support SAML-based SSO operations. Centrify customers are not susceptible to this vulnerability nor any Service Provider Applications that leverage the Centrify SDK (for more details, click here).

The disclosed vulnerability drew a lot of media attention, generating coverage by tech publishers like ZDNet, eWeek, and TechTarget. Some of you might ask why there has been so much hype around this vulnerability. To answer this question, you must understand the importance SAML plays in the context of user authentication and authorization.


For many, SAML might just be another acronym in the security alphabet. However, SAML is an open standard that allows security credentials to be shared by multiple computers across a network. In this context it’s one way to implement SSO, which enables users to log into accounts using a single identity. SSO is by far SAML’s most common use case.


When using SAML-based SSO, three distinct parties are involved. There is a user (the so-called principal), an identity provider (IdP), and a cloud application service provider (SP).

The IdP stores information about the user in a database like Active Directory. The user connects to the SP and attempts to authenticate. If the SP recognizes the user name, it delegates authentication to the IdP. Subsequently, the IdP validates the user against its identity database. It then sends a SAML assertion about that user to the SP. The SP then gives the user access to the application.

FIGURE 1: Simplified Overview of SAML-based SSO

In SAML, one IdP may provide SAML assertions to many SPs. Similarly, one SP may rely on and trust assertions from many independent IdPs. SAML itself does not specify the method of authentication at the IdP; it may use a user name and password, or other form of authentication, including multi-factor authentication.


SAML exchanges security and identity related information such as authorization and authentication, using signed digital certificates and Public Key Infrastructure (PKI) to ensure the integrity of data. SAML eliminates the possibility of passwords theft/reuse, thereby increasing security. And because it’s based on an open standard, SAML is interoperable with many different SPs.


The newly discovered SAML vulnerability allows a threat actor who already has authenticated access into a SSO system to authenticate as another user without that individual's SSO password. For example, an attacker who obtains login credentials for an SSO user through a phishing email can intercept a SAML response from the SSO system to the application requesting authentication. The attacker can then alter the SAML-based response to sign in as an entirely different user. Please note that the only condition for an attacker to exploit this flaw is to have a registered account on the victim's network, so it can query the SAML provider and forge requests to trick SAML systems into authenticating as a different user.


If you’re using SAML-based SSO, you should follow the below guidelines:

  • Check the CERT Vendor Information to validate if any of the solutions you might use (IdPs and SPs alike) is affected by the vulnerability.
  • Disable public registration of user accounts on sensitive networks and vetting each user manually to avoid attackers registering an account on internal networks in the first place.
  • Alternatively, ask your network admins to configure a white list of accepted email address domain names to limit who can register on the network. However, this is not a reliable protection measure and a determined attacker will find a way around it.
  • Enable two- or even multi-factor authentication, which stops the attack in its tracks.


At Centrify, we not just preach Zero Trust Security ― meaning never trust, always verify ― but more importantly we apply this approach to our development practices too. Thus, Centrify customers can be assured that this new SAML vulnerability is not impacting any of Centrify’s solutions, including the Centrify SDK for developers. In fact, if the SP supports it, the Centrify Application Services can be configured to fully encrypt the assertion, to provide further security.

This is written by the individual author in his/her personal capacity, and the opinions, views and/or thoughts expressed herein are solely the author’s own. They are not intended to and may not necessarily reflect the official policy or position, or the opinions or views of ThycoticCentrify or its affiliates, employees, or any other group or individual.