Continuing the theme of programmatic interaction with CA SSO that we began in my last post, today I’ll talk about another great new feature in CA SSO 12.8: the JWT authentication scheme. The feature enhances programmatic interaction with CA SSO and its protection mechanisms, thus helping to create a modern software environment where APIs, JSON format and ID tokens run the show.
Before I get into how this new feature can be implemented in CA SSO, let me describe what JWT is and how it can be used in the world of SPA (single-page application) and API-based applications.
Some folks think JWT (JSON Web Token) is the hottest topic when it comes to authorization and single sign-on, especially for API-based applications. In its most basic form, JWT does what SMSESSION has done for over 25 years. Where JWT really shines is when it contains additional claims or user attributes. Just as SMSESSION was “tossed around” between applications as a cookie, JWT is tossed around as a header and does not need a domain dependency.
A JWT can be generated when a user is authenticated. For example, CA API Gateway, Google and many other entities can authenticate a user and generate a JWT, with or without additional claims.
A JWT contains three sections:
base64urlencode(header) + "." + base64urlencode(payload) + "." + base64urlencode(digitalsignature(header + payload))
Here’s a sample JWT from https://jwt.io/:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
When this JWT is decoded, it shows the three JSON sections:
{
"alg": "HS256",
"typ": "JWT"
}
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
)
Essentially, the new authscheme in CA SSO version 12.8 accepts a JWT, authorizes the user to access a protected resource and issues an SMSESSION token so it can be used by other applications protected by CA SSO. Setting it up is pretty straightforward. But before we go through the setup, you should know that this authscheme requires use of CA Access Gateway and public certificates for signature verification, since CA Access Gateway has the main application to capture and decipher the JWT. CA Access Gateway is also used for all other federation types of single sign-on, such as SAML and WS-Fed. This new feature just extends the existing capabilities even further.
Below is my simplified setup with CA SSO 12.8:
You can get your JWT by logging into your Google account or CA API Gateway. (Don’t forget to get the public certificates while you’re there!) Then, add your JWT as a header to access a protected resource, say “/jwt/” on CA Access Gateway (as below, where I use SoapUI).
Now that we know what JWT is and how it is used, let’s look at how we can configure it in CA SSO in a few simple steps:
1. Set up the certificates. Pay attention to the aliases you give your certificates when you import them, as they will come in quite handy later.
2. Set up the authscheme. Notice the list of certificate aliases. If an alias is in the JOSE header, make sure you click that button. The most important part is the user lookup claim in the JWT; in most cases it is “sub,” but it could be email or whatnot.
The additional configuration items at the bottom reflect how secure you want the communications to be and what you want to do with the information. If you disable SMSession cookie generation, calls to other apps protected by CA SSO will require use of the JWT authscheme, where the apps need to present JWT for every single call. Persisting session variables will help with SSO in other protected realms.
One last thing: Once you have the authscheme, attach it to the realm protected by the CA Access Gateway agent:
There you have it—JWT Authentication Scheme in CA SSO. Questions? Comments? Please post them below or contact me at Amin.PashapourAlamdary@ca.com.