Skip to main content

Protecting Web Applications with IBM Security Verify Access


IBM Security Verify Access (formerly IBM Security Access Manager) provides user-friendly access management and multifactor authentication to help organizations maintain security as they adopt new technologies. It can be configured to act as an identity provider for the IBM Application Gateway (IAG) by acting as an OpenID Connect Provider (OP).

OpenID Connect is a simple identity protocol and open standard that is built using the OAuth 2.0 protocol. It enables client applications to rely on authentication that is performed by an OpenID Connect Provider (OP) to verify the identity of a user. OpenID Connect uses OAuth 2.0 for authentication and authorization, and then builds identities that uniquely identify users.

The IAG provides a native OpenID Connect relying partner (RP) capability that is able to consume an identity token which has been provided by the Security Verify Access OP in order to establish an authenticated session.

Authentication Flows

The OIDC specification states that authentication can follow one of three paths: the Authorization Code Flow, the Implicit Flow, or the Hybrid Flow. The flow determines how the ID Token and Access Token are returned to the Client. The Authorization Code Flow and the Implicit Flow are described below (please note that the IAG does not support the Hybrid Flow).

The Authorization Code flow is the default and recommended flow for the IAG, but it does require direct connectivity from the IAG container to the Security Verify Access OP. If direct connectivity is not possible the Implicit Flow may be used - although this flow is not recommended and is now considered a security best practices anti-pattern. There are two subtle variations to the Implicit flow, differentiated by the originator of the self-posting form (this form is used to POST the authentication tokens to the RP):

  1. The 'fragment' sub-flow uses a self-posting form which is served from the IAG container;
  2. The 'form-post' sub-flow uses a self-posting form which is returned from the Security Verify Access OP as a result of the authentication process.

Authorization Code Flow

Authorization Code Flow

Implicit Flow (fragment)

Implicit Flow (fragment)

Implicit Flow (form-post)

Implicit Flow (form-post)


IBM Security Verify Access

To configure the OIDC flow between Security Verify Access and IAG you need to have an existing IBM Security Verify Access or IBM Security Access Manager OIDC OP. If you do not already have one you can follow the IBM Security Verify Access Federation Cookbook, paying particular attention to Chapter 13 (OpenID Connect), to configure an OIDC Identity Provider.

Additional information on how to create an OIDC OP can be found in the IBM Security Verify Access documentation:

In order to configure the IAG to act as an RP the following Security Verify Access information will be required:

  1. Discovery Endpoint;
  2. Client ID;
  3. Client Secret;
  4. IBM Security Verify Access CA certificate.

IAG Container

The following initial tasks should be completed in order to protect a Web application using IBM Security Verify Access or IBM Security Access Manager

Task Reference Page
Complete the first steps to understand how to access the IAG image and run a container. First Steps
Create a server certificate for the IAG container. Managing Certificates
Configure the container so that it is able to consume tokens from the Security Verify Access OP. Configuring as an OIDC Relying Party for IBM Security Verify Access
Define the location of the applications which are to be protected. Protecting an Application
Define the rules which control access to the application resources. Defining the Authorization Policy

An example configuration yaml file which illustrates this scenario is available at: ../examples/basic-isva.