Identity provider - JSON Web Token

AVAILABLE IN 9.6.6 AND LATER

Overview

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it. Authorization and single sign on are the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. 

The Verba system can be integrated with customer applications via JSON Web Token (JWT) based authentication to provide a seamless single sign on login experience. Authentication and password verification takes place during signing in to the client application. The system verifies the user's identity based on the information presented in the JWT.

A sample scenario is shown on the diagram below.

  1. User authenticates in the Client Application (web, mobile, etc.) with the Authentication Server.

  2. Client Application requests a JSON Web Token (JWT) from the Authorization Server to login to the Verba Web Application.

  3. The Authorization Server verifies the request and signs the JWT with its private key and sends the JWT to the Client Application

  4. The Client Application opens/redirects to the Verba Web Application with the JWT (which includes the user ID) in the HTTP header.

  5. The Verba Web Application validates the JWT (verifies the signature, the user ID, etc). If all checks succeed, the user is logged into the application.

Configuration

Step 1 - Provide a Name.

Step 2 - Provide the user attribute for the matching in the Verba User Attribute setting.

Step 3 - If not exact matching of the attribute is required, change the Verba User Attribute Matching

Step 4 - Edit the Request Header, Request Header prefix, and Request Parameter if needed

Step 5 - Provide the Expiration Timezone

Step 6 - Check Prevent Token Reuse Mandatory Token Fields

Step 7 - Define the Signature Algorithm for the Signature Key (RSA needs a Public Key, HMAC needs Secret Key)

Step 8 - In case of multiple issuers, define a Regex unique to each issuer and repeat Step 7 for each

Step 9 - Check if HMAC Secret is Base64 Encoded


Multiple timezones

If multiple Issuers (Authorization Servers) are used with different time zones, then separate Identity Providers are needed.

Item Description
Verba User AttributeThe user attribute used for matching the user
Verba User Attribute MatchingDefines the matching for the user attribute
Request Header

The token can be sent either by a request header or an HTTP parameter
This configuration specifies the HTTP request header that will contain the token
The default value is "Authorization"

Request Header prefixThe authorization scheme
This prefix will be cut by the Verba server from the request header value
Request parameterThe token can be sent either by a request header or an HTTP parameter
This configuration specifies the HTTP request parameter that will contain the token
Audience RegexOptional, if defined the system will disregard tokens that do not have the matching "aud" attribute

Expiration Timezone

The timezone for the token expiration

Prevent Token ReuseChecking prevents reuse of the token
Mandatory Token FieldsDefines mandatory token fields
Tokens that do not contain the fields marked as mandatory will be discarded

Signature Keys

One Identity Provider can have multiple Signature Keys to support multiple Issuers (Authorization Servers).

Issuer Regex

The system will use the Issuer Regex to choose which key to be used to validate a given token

Signature AlgorithmThe algorithm used for the communication, either RSA or HMAC
KeyThe key used for the communication
RSA needs a Public Key, HMAC needs Secret Key
HMAC Secret is Base64 EncodedThe HMAC Secret is a list of bytes and so can contain special or even non-displayable characters
In that case, the secret's Base64 encoded form should be used in the Key field, and this checkbox should be turned on.