Configuration Data

IBM Security Verify Access OIDC Provider is an OpenID Connect Provider solution that runs in a separate container from IBM Security Verify Access.
IBM Security Verify Access OIDC Provider does not have a user interface configuration. It relies on the existing local management interface to perform the configuration.

To ensure that IBM Security Verify Access OIDC Provider functions properly, it must be configured and resources are made available upon successful configuration.
Currently, all the configuration is stored in the shared /var/isvaop/config directory.
The folder structure is as follows:

config
 |
 - provider.yml
 - attributesources.yml
 - storage.yml
 - ldapcfg.yml
 - clients
 |    |
 |    - <clientID1>.yml
 |    - <clientIDn>.yml
 |
 - javascript
 |    |
 |    - accesspolicy
 |    |     |
 |    |     - <policy>.js
 |    |
 |    - mappingrule
 |          |
 |          - <pretoken>.js
 |          - <posttoken>.js
 |
 - keystore
 |    |
 |    - <keystoreName>
 |          |
 |          - personal
 |          |   |
 |          |   - <personal_label1>.pem
 |          |   - <personal_labeln>.pem
 |          |
 |          - signer
 |              |
 |              - <signer_label1>.pem
 |              - <signer_labeln>.pem
 |
 - templates
      |
      - C
         |
         - static
         |     |
         |     - ibm-logo.png
         |     - styles.css
         |
         - user_consent.html
         - user_error.html
         - user_authorize_success.html
         - user_authorize_failed.html

1. Configuration Files

2. JavaScript

User customization code is done with JavaScript. Two types of JavaScript exist, accesspolicy and mappingrule. accesspolicy is used to handle user interaction with the system that is associated to user authentication. mappingrule is used to manipulate the data.

Note : If one script imports other scripts, they must be in the same folder. For example, if a script exists in the mappingrule folder, it cannot import scripts that are under the accesspolicy folder.

3. Keystore

IBM Security Verify Access manages keys inside keystores. User can create multiple keystores. Each keystore contains a personal folder to store private keys and a signer folder to store public keys.

Annotation used for keystores and certificate files

• ks: Represents a keystore, the file system path that it will look under is /var/isvaop/config/keystore. If its a key reference the equivalent pem file should reside under /var/isvaop/config/keystore/<keystore_name>/personal/ folder. If its a certificate reference the equivalent pem file should reside under /var/isvaop/config/keystore/<keystore_name>/signer/ folder.
• @ Represents a file, it used a relative file system path that it will look under is /var/isvaop/config/. Extensions such as .pem, .crt and .key can be used.
• B64: Represents the literal value of the base64 encoded certificate or key.

4. Page Templates

IBM Security Verify Access OIDC Provider uses template pages. The ready-to-use templates are used to display errors and to display user consent. User might add more pages that can be used. For example, by access policy challenge or deny action.

The templates are separated by language. The default language is in the C folder. All the template pages are expected to be in the language folder and must not be nested in another folder.

Under the templates folder, a static folder also exists that contains static contents such as images or stylesheet files. Initially, it contains the ibm-logo.png image and default stylesheet styles.css.

If templates are not mounted into the volume as a part of deployment, it will default to use the templates that are packaged in the container image based on the locale of the request, if a specific locale is not found, it will fallback to C.