OpenID Connect in ActiveMatrix

OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, and can be used by WebApp IT applications to:

  • verify the identity of an end-user based on the authentication performed by an authorization server (such as Google or Microsoft Active Directory Federation Services (ADFS)), and
  • obtain basic profile information about the end-user in an interoperable and REST-like manner.
The user's identity is encapsulated in an ID Token (a JSON Web Token (JWT)), which must be signed by the authorization server using JSON Web Signature (JWS).
Note: Using the OpenID Access Token is not currently supported in ActiveMatrix Service Grid. The OpenID ID Token is used to identify the user.

The OpenID Connect specification specifies two flows:

  • Implicit Code Flow - In this flow, the client (likely a browser) gets an ID Token after the Resource Owner (the end-user) grants access.
  • Authorization Code Flow - In this flow, the client (usually a web server) only gets an authorization code after the Resource Owner (the end-user) grants access. With that authorization code, the client then makes another call to the API, passing client_id and client_secret, together with the authorization code, to obtain the ID Token.

ActiveMatrix supports the Authorization Code Flow.

Policy Sets used to Enforcement OpenID Connect

OpenID Connect support is provided in ActiveMatrix through the use of OpenID Authentication policy set. It makes it easy for applications to use any existing OpenID providers without worrying about the underlying OpenID Connect implementation.

Using a policy set to enforce Single Sign-On (SSO) using Open ID Connect offers the following benefits:

  • It simplifies application support for OpenID Connect with no specific programming or coding needed. This allows application developers to focus solely on the business logic of their application and delegate the OpenID Connect authorization to the security administrator.
  • Multiple OpenID Connect Providers are supported, and so is switching between OpenID service providers by reconfiguring the policy set without having to modify the application code.
  • It allows a group of applications to take part in SSO.

Example Scenario

In this example scenario, the user application wants to access the protected API. The API is protected using the OpenID Authentication policy, which requires the user to authenticate by the OpenID Authorization Server. The OpenID Authentication policy is configured with the OpenID Connect Authorization Server information and the client details (specified via OpenID Authentication Resource Template). The OpenID Authentication policy acts as the client endpoint that requests the Authorization Server to access the user details.

  • When the user requests access, the OpenID Authentication policy is enforced by redirecting the user to the OpenID Authorization Server.
  • Once user is authenticated using valid credentials, the request goes to the policy layer using the redirect URI (specified previously via OpenID Authentication Resource Template).
  • The policy layer gets the authorization code from the response and connects to the authorization endpoint to get the ID Token.