What is SAML 2.0 Authentication, and How Does It Work?

The meteoric rise of SaaS (Software as a Service) has taken on the burden of managing, scaling, and installing necessary applications. A cloud service provider hosts all your services while you access them remotely.

While this is a convenient setup since it removes any IT overhead costs, it also created an underlying need for a SSO (Single Sign On) login standard. A corporation’s SaaS stack can have over a dozen applications in it and manually signing in to each one is a considerable time sink. It’s like sitting down for a meal and paying at the register for every bite.

The problem gets worse when you consider that security-minded users create unique login credentials for every account.

The Security Assertion Markup Language (SAML) method offers secure authentication with a better consumer experience than usernames and passwords.

How Does SAML 2.0 Work?

When you enter your username and password into a service, you’re telling that service that it can trust you. This is known as a trust relationship.

SAML Authentication creates a permanent trust relationship between an Identity Provider and all of the user’s applications. Establishing this connection means that logging into the Identity Provider automatically extends that trust to the user. This way, the user only has to log into one place to access all of their applications.

However, understanding the digital security benefits of SAML 2.0 requires a more in-depth understanding of its mechanics. To this end, you should understand a few key terms first. We’ve mentioned them briefly before: Identity Provider (IdP), Service Provider (SP), and The User.

• Identity Providers are a service that manages the digital identities of users and their attributes, including login credentials, email addresses, full names, and other identifiers.
• Service Providers are all the businesses that manage the applications used on your devices. For example, a workplace may use different applications for each need, such as communication, project planning, note-taking, sales tracking, etc. Each application represents a unique service provider. Service Providers also store user information that is identical to what Identity Providers record.
• The User or User Browser, is you. It refers to every part of the process you still have to perform manually. Don’t worry; it’s not a lot.

• These are all are the three critical stops along a SAML flow. But what good are these stops if nothing is traveling between them?

Of course, the Identity Provider, Service Providers, and the User need to talk to each other. They speak using SAML Requests, SAML Responses, and SAML Assertions.

• SAML Requests are known as a request for authentication. The token is generated by the Service Provider requesting user verification.
• SAML Responses are generated by the Identity Provider. The response states an actual assertion of an authenticated user.
• SAML Assertions are cryptographically signed SAML Responses that include the user’s credentials and what information the user can access with the Service Provider. 

Now that everything is clearly defined, let’s go over the progression of the SAML flow. This process may seem long, but it all happens in a matter of seconds.

• Step 1: The User types the URL for a Service Provider’s website. 
• Step 2: The Service Provider generates and sends a SAML Request to the User’s browser.
• Step 3: The SAML Request is forwarded to the Identity Provider.
• Step 4: The Identity Provider’s log in page appears on the User’s browser to fill in.
• Step 5: The Identity Provider sends the newly authenticated User a signed SAML Assertion.
• Step 6: The signed SAML Assertion is forwarded to the Service Provider.
• Step 7: The Service Provider validates the SAML Assertion and grants access to the User.

This seven-step process outlines every communication in the SAML flow. However, careful readers will notice that the User only did two things. They visited the Service Provider’s website and logged into the Identity Provider when prompted. There’s no need to memorize 15 username and password combinations or go through the trouble of typing them all in.

After the first log in, the User is set for the session. Every time they visit another Service Provider’s page, they’ll be automatically logged in.

Anyone wanting to utilize SAML, in any form, must be an Identity Provider and a quick way to become an IdP is to implement SecureAuth. As a SecureAuth organization, your company is transformed from simply holding secure identities to a secure, guidance-compliant IdP. 

Providers such as Google, Salesforce, and WebEx quickly implemented the SAML standard. Organizations were able to deliver security information about user identities and access privileges to service providers in a safe and secure environment

How Secure is SAML 2.0 Authentication?

SAML has an open standard, meaning anyone with the proper training can create a Service or Identity Provider compatible with the system. However, this also means that those providers are beholden to the solid security protocols embedded in SAML 2.0.

Since we’ve been using its acronym almost exclusively, it’s worth reminding you that the ‘S’ in SAML stands for Security. This is well-earned as SAML’s authentication process removes the use of passwords and replaces them with encrypted security tokens instead.

It’s worth noting that only the SAML Assertions are cryptographically encrypted. This is because, up to that point, none of the other tokens included information like your credentials, settings, and time of log in. However, the SAML Assertions utilize public key cryptography, otherwise known as asymmetric cryptography.

This type of protection uses two keys (an algorithm for scrambling and decoding data) instead of one. The first key, which is available to the public, encrypts the data. The second key, owned solely by the token’s recipient, is meant to decrypt the data back to plain text.

It may sound unsafe to have one of the keys available to the public, but this protocol means that the private key never needs to transfer to another source.

With single-key systems, the cryptographic key moves around alongside the file it’s protecting. So, a hacker could intercept the file and break the encryption at their leisure.

Apart from the encryptions, eliminating passwords is an obvious upside considering the gaping security risks that passwords create, especially from an employer’s point of view. With some operations using more than 20 different service providers, it’s only a matter of time until Rick from accounting uses ‘password1’ as his password. Removing passwords also dramatically reduces the threat of malware such as keyloggers.

Future of Authentication

In the world of technology, one truism says it all; the sector never slows down. Any company sitting on its hands is out of business. One key to technological success is always looking for the next best thing. 

In 2005, SAML was the next big thing in authentication, and today remains at the top of the heap. However, nothing lasts forever, and OpenID Connect is considered the heir apparent in digital authentication.

If you’ve ever logged into Instagram or YouTube with your Google account, then you’ve used OpenID Connect.

Most experts agree OpenID is the future of SSO. SAML has been a capable protocol for years. However, SAML has been caught up in rapid technology change. 

OpenID Connect is built on OAuth2, making it a great combination. While OAuth2 only allows for authorization, OpenID Connect has authentication permissions as well.

The authentication protocol has only been around for a couple of years, with prominent players implementing the protocol, including Microsoft Azure, Twitter, and PayPal. As of now, OpenID is a more consumer-based protocol with government and education clients on the way.

OpenID’s exploding popularity is based on a few features:

• It is a cloud-native protocol 
• Highly adaptable to new burgeoning technologies
• Rather than being heavy, it relies only on JSON
• Mobile Friendly

SAML will not go away soon and will remain a major player in the single sign-on space. The language is firmly entrenched in education and government. The 21st century has ushered in a digital revolution for secured access to various divergent services.

SAML Tools

Nothing works in a vacuum, and the same holds true for bedrock software. Over the last two decades, countless tools and tips have been available to customize the application exactly as the user wishes. One of the easiest ways to implement SAML is to leverage The OpenSource SAML Toolkit.

• Toolkits contain the logic needed to understand the SAML Response. Logic is given to users for a Service Provider sign-on request. 
• Protecting data is what ATAKAMA is all about. Working with SAML and OpenID, the company is well equipped to handle any size encrypt/decrypt project.
• OneLogin handles x.509 certificates for the SAML method. 509 certificates are used in SAML to validate, sign, and encrypt messages. 
• SAML Decoder decodes messages, metadata, and additional SAML encoded output and formatted in XML.
• SAML Tracer is used for viewing SAML and WS-Federation messages sent through the browser.

Maintain Your Safety by Authenticating Every App You Use

Every corner of the technology space is growing fast, and some sub-sectors are seeing a meteoric rise with the right product or service. Virtual Organizations without hard assets are dynamic enterprises and getting stronger by the day. Security will continue to grow and keep up with other faster-growing businesses. 

SAML is a foundational software application for thousands of global top-line corporations. SAML will continue its unwavering performance for years, with new applications coming online each year