SAML - Explanation with example

Security Assertion Markup Language (SAML) is an open standard that allows identity providers (IdP) to pass authorization credentials to service providers (SP). What that jargon means is that you can use one set of credentials to log into many different websites. It’s much simpler to manage one login per user than it is to manage separate logins to email, customer relationship management (CRM) software, Active Directory, etc.

SAML transactions use Extensible Markup Language (XML) for standardized communications between the identity provider and service providers. SAML is the link between the authentication of a user’s identity and the authorization to use a service.

SAML enables Single-Sign On (SSO), a term that means users can log in once, and those same credentials can be reused to log into other service providers.

What is SAML Used For?

SAML implements a secure method of passing user authentications and authorizations between the identity provider and service providers. When a user logs into a SAML enabled application, the service provider requests authorization from the appropriate identity provider. The identity provider authenticates the user’s credentials and then returns the authorization for the user to the service provider, and the user is now able to use the appli

cation.

SAML authentication is the process of verifying the user’s identity and credentials (password, two-factor authentication, etc.). SAML authorization tells the service provider what access to grant the authenticated user

.

What is a SAML Provider?

A SAML provider is a system that helps a user access a service they need. There are two primary types of SAML providers, service provider, and identity provider.

A service provider needs the authentication from the identity provider to grant authorization to the user.

An identity provider performs the authentication that the end user is who they say they are and sends that data to the service provider along with the user’s access rights for the service.

How Does SAML Work?

SAML works by passing information about users, logins, and attributes between the identity provider and service providers. Each user logs in once to Single Sign On with the identify provider, and then the identify provider can pass SAML attributes to the service provider when the user attempts to access those services. The service provider requests the authorization and authentication from the identify provider. Since both of those systems speak the same language – SAML – the user only needs to log in once.

Each identity provider and service provider need to agree upon the configuration for SAML. Both ends need to have the exact configuration for the SAML authentication to work.

SAML vs. OAuth

SAML is a set of standards that have been defined to share information about who a user is, what his set of attributes are, and give you a way to grant/deny access to something or even request authentication.

OAuth is more about delegating access to something. You are basically allowing someone to "act" as you. Its most commonly used to grant access api's that can do something on your behalf.

They are two completely different things.

Some examples that might help out.

OAuth think of an twitter. Lets say you are using Google Buzz and Twitter, and you want to write an app to be able to keep the two synchronised. You basically can establish trust between your app and twitter. First time you go to link the app to twitter, you do the classic prompt to log into twitter, and then that confirmation box pops up and asks "Would you like to grant access to «your app name»?" once you click "yes", the trust has been established, and now your app can act as you on Twitter. It can read your posts, as well as make new ones.

SAML - For SAML think of some type of "agreement" between two unrelated membership systems. In our case we can use US Airways and Hertz. There is no shared set of credentials that can take you from one site to another, but lets say Hertz wants to offer a "deal" to US Airways. (Granted I know this is an extreme example, but bear with me). After buying a flight, they will offer a free rental car to its Chairman members. US Airways and Hertz would setup some form of trust, and some way to identify the user. In our case our "federated id" would be the email address, and it would be a one way set of trust Hertz trusts that US Airways identity provider will deliver a token that is accurate and in a secure manner. After booking the flight US Airways identity provider would generate a token and populate how they have authenticated the user, as well as "attributes" about the person in our case the most important attribute would be his status level in US Airways. Once the token has been populated it passes it via some type of reference, or encoded in a url and once we get to Hertz, it looks at the token, validates it and now can allow for the free rental car.

The problem with this SAML example is it's only one specialized use case out of many. SAML is a standard and there are almost too many ways that you can implement it.

Okta

It's an enterprise-grade, identity management service, built for the cloud, but compatible with many on-premises applications. With Okta, IT can manage any employee's access to any application or device. Okta runs in the cloud, on a secure, reliable, extensively audited platform, which integrates deeply with on-premises applications, directories, and identity management systems.

One of the main features of Okta is Single Sign-on, this eliminates the pain of making unique passwords for every application and it also improves the security of the data.

Company’s turn to Okta when they realize they can deploy SSO from Active Directory in less time.

Lets create an example by using Spring Boot, SAML, and Okta

first thing you’ll need to do is create a developer account at https://developer.okta.com. After activating your account, log in to it.

Click on < > Developer Console in the top-left corner and Click Add Applications in the top right to continue. This will bring you to a screen with a Create New App green button on the left.

Click the button and choose Web for the platform and SAML 2.0 for the sign on method.

Click the Create button. The next screen will prompt you for an application name. Enter the application name and click on next button. This brings you to the second step, configuring SAML. Enter the following values:

Single sign on URL: https://localhost:8443/saml/SSO
Audience URI: https://localhost:8443/saml/metadata

Scroll to the bottom of the form and click Next. This will bring you to the third step, feedback. Choose “I’m an Okta customer adding an internal app” and optionally select the App type.

Click the Finish button to continue. This will bring you to the application’s “Sign On” tab which has a section with a link to your applications metadata in a yellow box. Copy the Identity Provider metadata link as you’ll need it to configure your Spring Boot application.

The final setup step you’ll need is to assign people to the application. Click on the Assignments tab and the Assign > Assign to People button. You’ll see a list of people with your account in it.

Click the Assign button, accept the default username (your email), and click the Done button.

Create a Spring Boot Application with SAML Support

Add the spring-security-saml-dsl dependency to your pom.xml.

You’ll also need to add the Spring Milestone repository since a milestone release is all that’s available at the time of this writing.

In src/main/resources/application.properties, add the following key/value pairs. Make sure to use the “Identity Provider metadata” value you copied earlier (hint: you can find it again under the “Sign On” tab in your Okta application).

server.port = 8443
server.ssl.enabled = true
server.ssl.key-alias = spring
server.ssl.key-store = classpath:saml/keystore.jks
server.ssl.key-store-password = secret
security.saml2.metadata-url = 

From a terminal window, navigate to the src/main/resources directory of your app and create a saml directory.

Navigate into the directory and run the following command. Use “secret” when prompted for a keystore password.

keytool -genkey -v -keystore keystore.jks -alias spring -keyalg RSA -keysize 2048 -validity 10000

The values for the rest of the questions don’t matter since you’re not generating a real certificate. However, you will need to answer “yes” to the following question.

Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct?
  [no]:
 

Create a SecurityConfiguration.java file in the com.example.demo package.

Create an IndexController.java file in the same directory and use it to set the default view to index.

Since you chose Thymeleaf when creating your application, you can create a src/main/resources/templates/index.html and it will automatically be rendered after you sign-in. Create this file and populate it with the following HTML.

Run the App and Login with Okta

once you request the page Okta to sign in and redirected back to your app. If you’re already logged in, you won’t see anything from Okta. If you sign out from Okta, you’ll see a login screen such as the one below.

After you’ve logged in, you should see a screen like the one below.