How to connect Okta SAML and Spring Boot using saml2Login, part 2
This is the second article in the series. For the first article, visit here.
Multiple Okta SAML Identity Providers
What’s the best way to register multiple Okta instances in a Spring Boot application as potential sources of identity and authorization?
It’s that simple. The properties are briefly introduced in the Spring Security documentation (5.4.2), and I haven’t been able to find a more detailed description. As typical for Spring Boot, there’s some magic and defaults that kick in when explicit configuration isn’t given, so if it’s not behaving as expected, check out the Saml2RelyingPartyProperties source code.
okta2 are the Relying Party
registrationIds, which for our example are used primarily for the Okta SSO URL and Audience Restriction URI which are configured in the Okta User Interface.
SSO URL: http://localhost:8080/login/saml2/sso/okta1
Audience Restriction URI: http://localhost:8080/saml2/service-provider-metadata/okta1
Now when you launch your app, you will see the following login page — without having to do any extra work!
Simply choose which Okta instance to use, sign in, and you will be returned to the application. I’ve created a sample application at https://github.com/joshuatcasey/okta-boot-and-saml2login, all you need to do is substitute the correct Okta metadata URLs in
Map SAML attributes to Identity and Authorization
SAML has limited support for identity / authorization concepts. The
Subject attribute of an
Assertion will provide some form of identifier, but it’s usually not the only identification attributes that we want to know. What about given name, last name, email address, and so on? And how do we know what this user is allowed to do within our application? Let’s say that the user belongs to some Groups in Okta, such as
Customers. We can configure Okta to provide these Groups in an attribute in the
Assertion. For more information, see part 1.
How is this information represented in Spring Security? Identity is contained in the
Principal and authorities are contained in the
Authorities. For more information, see the links below. But how do we link a SAML
Subject into a Spring Security
Principal? How do we translate SAML
Groups Attribute into Spring Security
First, let’s pick a terminology for Identity. Should my name “Joshua” be my first name, given name, or forename? Should my name “Casey” be my last name, family name, or surname? I’ll select SCIM as the common labeling methodology. For today, all we will use is
emails from the SCIM specification.
We need a way to map the attributes from SAML to our SCIM attributes. This will depend on the SAML provider and how it is implemented, so we’ll have to link it to the
registrationId. As an example, let’s specify this mapping in our properties:
authorityMapping, we can specify which SAML attribute to use for authorities. In this case, it’s
Groups for both Okta instances.
identityMapping, we can specify a list of attributes to map from SAML to SCIM. In this case, the
FirstName SAML attribute will map to
name.givenName SCIM attribute and so on.
If you run the sample application, and visit the
/whoami endpoint you should see something like the following JSON. Also, if you create a group in Okta called
Admins and put the user groups in a SAML attribute called
Groups, you should be able to visit the
/admins endpoint as well.
"userName": "<your email>",
"value": "<your email>",
I hope this helps you to understand how identity and authorization are configured in Okta and Spring Boot! Let me know if I can add clarifying information or more examples.