Apr 12, 2021
Use OKTA to design Service provider initiated Single Sign-on Flow: IAM
Integrate Service providers(SPs) with OKTA Identity provider(IdP)
SAML 2.0 Platform + OKTA as Identity provider
Scope
This article explains SAML2.0 SSO with multiple service providers built using Spring Security and registering them with OKTA which acts as Identity provider.
What is SAML SSO ?
SAML single sign-on goal is to minimize the number of times a user has to login at various web sites. It facilitates the user to manually login at one site (called the Identity provider(IdP) and then automatically logging in, without having to provide credentials, at one or more other sites (called the Service providers (SP)).
A trust relationship must exist between the identity provider and service providers. Service providers trust that the identity provider has authenticated the user.
SAML2.0 Terminology
a. The Principal is the user trying to authenticate.
b. Service provider(SP) are the services requesting authentication and identity information about a Principal. SP will take authentication response from IdP and use that information to create and configure sessions.
c. Identity provider(IdP) is the source providing identity information and authentication decision. IdP authenticates Principal and return identity information to SP.
d. SAML supports two single sign-on flows. SP-initiated SSO and IdP-initiated SSO. In this article we will look at SP-initiated SSO.
e. Bindings are the format in which data is transferred between service providers and identity providers. The two most popular are HTTP Redirect Binding and HTTP POST Binding. HTTP Redirect Bindings transfer data using HTTP redirects and query parameters. This type of binding is typically used in authentication requests. HTTP POST Binding transfer data using HTTP POST forms, this type of binding is typically used in authentication responses.
f. Assertions are statements made by the identity provider about the principal. It defines how the identity information about the principal is communicated from an identity provider to a service provider.
For example, the principal’s email address and/or groups/roles the principal may be associated with. Assertions are used by the service provider to create and configure sessions for a principal.
g. SAML Request, also known as an authentication request, is generated by the Service Provider to “request” an authentication.
h. SAML Response is generated by the Identity Provider. It contains the actual assertion of the authenticated user. In addition, a SAML Response may contain additional information, such as user profile information and group/role information, depending on what the Service Provider can support.
When to use SAML authentication protocol ?
Use Case
a. The SAML SP is always a website. So it should be a web application.
b. To leverage an existing SAML authentication and explore OAuth2 authorization, a SAML Assertion grant type can be used to exchange assertions for OAuth2 access tokens.
example: grant_type: urn:ietf:params:oauth:grant-type:saml2-bearer
SAML2.0 Flow
Service Provider — Spring boot applications running in HTTP Secure port 8443 and port 7342.
Identity Provider — OKTA.
1. Given that a user is logged in using Windows desktop login (Kerberos) and requires access to a web application SSO service. Steps ❸ & ❹ are not required. The user experience is that they click on the application link and are immediately and seamlessly granted access to the application
2. Given that a user access the website directly without authentication session, then steps ❸ & ❹ are required to authenticate with Identity provider to get access to application.
Steps
a) User clicks on link to web application (❶).
b) Application recognizes that the user does not have a valid SSO session token and redirects the user’s browser to the IdP Service (❷).
c) IdP service authenticates the user on the basis of their existing login using Kerberos (or) if Kerberos not implemented then IdP challenges user to authenticate and sends a SAML assertion token to the application (❺& ❻) via the user’s browser.
d) Application receives SAML assertion containing user identifier (e.g. email address) and determines whether it has an account for that user and whether they are allowed to use the application.
e) Application presents appropriate pages to the user (❼).
OKTA, as Identity provider
Service provider configuration
a. Login to OKTA with your credentials.
b. Click ADMIN on the far right.
c. Click Applications, and Add Application
d. Create New Application
e. In the Create New Application Integration screen, select as given below and click Create;
f. Once created, open application.
g. In the General tab, the minimum configuration are shown below;
1. The Single Sign On URL shown below is the Assertion Consumer Service (ACS) URL . The ACS URL is an endpoint on the service provider where the identity provider will redirect to with its authentication response. This endpoint should be an HTTPS endpoint because it will be used to transfer Personally Identifiable Information (PII).
2. The Audience URI is the intended audience of SAML assertion sent by Identity provider.
Service provider 1 configuration in OKTA
Service provider 2 configuration in OKTA
In the Sign on tab,
1. Download the IdP metadata to configure with Spring boot application.
2. The important tags to look for in the IdP metadata are SingleSignOnService and KeyDescriptor. The SingleSignOnService tag define the binding and endpoints to send authentication requests to, and the KeyDescriptor tag contains the public key of the identity provider which will be used to validate the authentication response.
In the Assignments tab,
1. Select Users and/Groups, to provide access to application.
Create JKS keystore using Keytool
a. JKS until Java 8
b. Since Java 9, the default keystore format is PKCS12
As IdP transfers Personally Identifiable Information (PII) to Assertion Consumer Service(ACS) URL, we make the HTTP Secure. So we create a keystore at the Service Provider to initiate HTTPS request.
Spring Boot Security
To demonstrate Single Sign-On, we create 2 Spring boot security applications.
Minimum Configuration
OktaIS application as Service provider 1 running in secure port 8443
OktaIS2 application as Service provider 2 running in secure port 7342
Launch User Agent
a. When the user hits the above Service provider URL, the User Agent will redirect to Identity provider as shown below;
b. The SAML AuthnRequest generated by Service provider can be seen in the below screen shot. The XML document will be serialized (base64, compress, and URL encode), add it as a query parameter to the URL, and redirect the principal’s browser to the Identity provider’s login page.
c. If the principal enters their correct login credentials, the Identity provider will perform a 302 Redirect to the ACS URL of the service provider with body containing the authentication response as shown below.
d. When a service provider receives an authentication response, it should first check if the InResponseTo attribute references an ID of an AuthnRequest that the service provider actually sent. In addition, the IssueInstant attribute should be used to scope the validity window of the response.
e. The ACS URL to which the authentication response is delivered performs no authentication of the client, this is why the Signature in the authentication response must be checked to ensure the client is the identity provider.
f. The information is exchanged out-of-band ahead of time which is then used to authenticate the client
Navigate to Service provider 2
a. Using the navigation hyperlink given in OktaIS application, click to access OktaIS2 application using SSO, as shown below.
Conclusion
In this article we have seen SAML2.0 SSO integration with Spring Security and Spring boot applications with OKTA, as Identity provider.
You can view the code in GitHub to learn and understand.
published on 12th April 2021
Other medium articles, by Ganesh Nagalingam
Quest Syntax Tree and remedy Code Smell using JAPA Visitor Patterns
Asynchronous WebSocket Messaging Middleware and Microservices
Amalgamate Angular with Spring Cloud Architecture through CORS
Multi-Broker Insights into Apache Kafka Cluster Architecture
Remote Queue Definition: IBM MQ v9.2
Kubernetes Pods & Docker Containers: Spin VM using Virtual Box in Windows 10 Home
Federate OKTA IdP + WSO2 API Manager as Gateway to Spring boot Microservices Integration
Integrate IBM Business Process Manager with Hybrid MobileFirst application
Kerberos v5: SSO authentication in Windows 10 Home using Apache directory studio
Integrate IBM WebSphere Service Registry and Repository with IBM Process Server
