A Complete Guide to Implementing SAML Authentication in Enterprise SaaS Applications

What Is SAML Authentication?

SAML stands for Security Assertions Markup Language. Let’s say an organization wishes to authenticate its users without creating IAM roles and communicate assertions between the source and the target in a cloud environment. This can be easily achieved with the help of SAML.

This is part of a series of articles about SaaS architecture

SAML is a method of secure communication between parties using extensible markup language (XML). The following two endpoints are typically used in SAML:

1. Identity provider: The source that makes the request is known as the “identity provider” and the user’s identity might be either username/password or username/OTP.
   
2. Service provider: The “service provider” is the target to which the started request is directed for verification; it may be Gmail, AWS, or Salesforce. It keeps track of user permission records, and grants access to Software as a Service (SaaS) applications. It also keeps track of how long a user is permitted to stay or how to keep a user’s session on a certain application alive.

SAML is built on the notion of single sign-on (SSO). It means that one can use the same credentials on all of an organization’s portals to which they have access. SAML can also be used for access control list (ACL) permissions, in which it determines whether or not a user is authorized to access a specific resource. There’s also SAML 2.0, which is a version of the SAML standard that enables web-based, cross-domain SSO. It was ratified back in 2005.

Benefits of SAML

1. For users and systems built independently by an organization, SAML enables both authentication and authorization.
2. There is no need to use or remember numerous credentials after it is implemented. Only one sort of credential can access all of the organization’s resources or systems. 
3. SAML follows a standard methodology that is not dependent on any system because it has no interoperability concerns with multiple products/vendors. SAML follows a standard method that is not dependent on any system.
4. It uses a single point of entry to validate a user’s identity, allowing it to provide secure authentication without keeping user data or requiring directory synchronization. As a result, it removes the possibility of identity theft. 
5. The SSO principle provides a hassle-free and speedier environment for its users.
6. Administrative costs are also lowered for service providers. Because different authentication endpoints aren’t required, there’s no need to develop them.
7. It makes the system more dependable in terms of “risk transference” because it transmits responsibility based on identity.

Let’s discuss the benefits of SAML from different stakeholders’ perspectives:

SAML v.s OAuth

OAuth stands for “Open Authorization“. OAuth, like SAML, employs an authorization server to complete the login process, and both are based on the SSO principle. Let’s look at some of the fundamental differences between them.

1. SAML is concerned with the user, whereas OAuth is concerned with the application.
2. Users are managed centrally in SAML. When a user logs into his organization’s network, he has access to all the resources because everything is centralized. However, if a user wants to provide third-party websites access to his information from a website like Facebook or Google, OAuth is required.
3. SAML can do both authentication and authorization, whereas OAuth can only do the latter.
4. OAuth is based on JavaScript Object Notation (JSON), binary, or even SAML forms, whereas SAML is based on XML format.
5. In SAML, a token is referred to as a SAML assertion. In OAuth, a token is referred to as an access token.
6. If users need temporary access to resources, utilize OAuth instead of SAML because it is more lightweight.

How SAML Authentication Works

1. The identity provider obtains the user’s credentials (username and password). SAML validates the user’s identity at this stage.
2. The identity provider will now verify the credentials and permissions associated with that account. If the user’s credentials are correct, the identity provider will respond with a token and the user’s approved response to access the SaaS application. 
3. This token is sent to the service provider using a POST request. 
4. The service provider will now validate the token. If the token is valid, it will generate temporary credentials and direct the user to the desired application terminal.

Note: The actions listed above will only work if there is a “trust connection” between the identity provider and the service provider. The authentication process will fail if that does not exist.

How We Can Create a Trust Relationship between Identity Provider and Service Provider

The SAML basic configuration must be agreed upon by both the identity provider and the service provider. As a result, an identical configuration is required at both endpoints; otherwise, SAML will not work. 

How It Works:

1. Create a SAML document and submit it to the service provider. However, this document would be in XML format. We must first generate a certificate from the host machine.
2. Similarly, generate a document on the service provider and then import it on the identity provider. That document has a lot of information like certificate information, email address of the organization, and public key of the service provider.

SAML Use Cases

When an organization implements SAML, it can do so in a variety of ways. For example, all infrastructure can be deployed on-premises, in the cloud, or in a hybrid structure where part of it is on the cloud and part is on-premises. We have a couple of use cases based on it.

Hybrid

In this situation, identity verification takes place on-premises, but authorization takes place in the cloud, and the user has immediate access to the cloud resource before authentication, then:

1. Users can access cloud resources directly.
2. For authentication, users will be redirected to an on-premises setup.
3. The identity provider verifies the user’s identity and provides the SAML assertion for the service provider’s use.
4. The service provider will validate the assertion, and the user will be sent to the web application.

Cloud-Based

Both the identity provider and the service provider are cloud-based in this scenario, and the apps are either cloud-based or on-premises.

1. First, users will be redirected to the cloud infrastructure to verify their identity. Identity as a service (IaaS) is a term used to describe how identity providers work (IDAAS). 
2. Authentication will be handled via the identity provider. The identity provider assigns assertions after authentication.
3. The service provider verifies the veracity of the claim and provides the user access to the web application.  

How to Implement SAML on the Cloud

It is relatively simple to deploy SAML in the cloud because most cloud service providers now provide an option to do so automatically; you don’t need to know rocket science to do so. Here, we are discussing how you can implement SAML on Google Cloud.

Step 1

Create an account on Google Cloud and enable the identity provider.

Step 2

Now it’s time to set up the provider; there are a few things to do.

1. Go to Identity Provider -> Click on Add Provider -> Select SAML list from there -> Enter details such as Provider Name, Provider’s Entity ID, Provider’s SSO URL, Certificate (used for token signing).   
2. Go to Service Provider -> Provide Entity Id (that verifies your application).

Step 3

1. Add application URL in the authorized domain.

Step 4

2. After adding all this information at different places, click on save.

These are some basic cloud measures that we can use. However, we can take the procedures listed below to secure it, such as:

1. Signing request: By signing authentication requests, this feature improves the security of the requests.
2. Link user accounts: There’s a chance the user has already signed into the program, but with a different method than username/password. As a result, we can link the existing account to the SAML provider in such a scenario.
3. Re-authenticating user: When a user changes his email, password, or any other sensitive information, it is the obligation of the SAML to re-authenticate the user.

SAML Authentication Best Practices

Although we discussed the fundamentals of SAML, there are other fundamentals that make SAML communication more safe.

1. For secure web communication, always use SSL/TLS. As a result, all communication between users, identity providers, and service providers is encrypted at all times. Since communication is encrypted, an attacker attempting an MITM attack will be unable to access or modify the data. As a result, the requests’ confidentiality and integrity are preserved.
2. Whenever creating a trust relation between identity providers and service providers, configure identity providers to use HTTP POST, and for redirection of SAML responses, use the whitelisted domains. The service provider does not perform the authentication operation. If the domain is not whitelisted, attackers can manipulate the domain and redirect them into a malicious domain.    
3. SAML uses XML to perform validation schema on XML documents so that unsanitized user input cannot pass. Always prefer local schema from XML. Do not download it from untrusted websites. 
4. Maintain a blacklist of the domains that the organization wants to exclude from the SAML authentication process.
5. As an identity provider, we can manage the user through access control.