Identity provider - JSON Web Token
- Kiss, Mate
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.
User authenticates in the Client Application (web, mobile, etc.) with the Authentication Server.
Client Application requests a JSON Web Token (JWT) from the Authorization Server to login to the Verba Web Application.
The Authorization Server verifies the request and signs the JWT with its private key and sends the JWT to the Client Application
The Client Application opens/redirects to the Verba Web Application with the JWT (which includes the user ID) in the HTTP header.
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 Attribute | The user attribute used for matching the user |
| Verba User Attribute Matching | Defines the matching for the user attribute |
| Request Header | The token can be sent either by a request header or an HTTP parameter |
| Request Header prefix | The authorization scheme This prefix will be cut by the Verba server from the request header value |
| Request parameter | The 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 Regex | Optional, 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 Reuse | Checking prevents reuse of the token |
| Mandatory Token Fields | Defines 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 Algorithm | The algorithm used for the communication, either RSA or HMAC |
| Key | The key used for the communication RSA needs a Public Key, HMAC needs Secret Key |
| HMAC Secret is Base64 Encoded | The 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. |