IBM Security Verify Access OIDC Provider

https://docs.verify.ibm.com/ibm-security-verify-access/docs
Admin
IBM Security Verify Access OIDC Provider is a containerized, lightweight OpenID Connect provider...
Tokens:211,424
Snippets:882
Trust Score:10
Update:1 year ago
Show doc for...
Tokens:
Raw
### LdapAttributeUtil Usage Example

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/util_ldap

This example demonstrates the core functionalities of the LdapAttributeUtil, including initializing the utility, creating subcontexts, managing attribute values (add, get, remove, set), and performing searches. It also shows how to handle potential errors and iterate through LDAP search results and attributes.

```javascript
var attrUtil = new LdapAttributeUtil("ldap_staging");
// createSubContext
let result = attrUtil.createSubContext("ou=newOu", {"objectClass": ["top", "organizationalUnit"]});
if (result.hasError()) {
    let error = result.getError();
    // handle error...
}
// addAttributeValue
result = attrUtil.addAttributeValue("ou=newOu", "description", "description_01");
if (result.hasError()) {
    let error = result.getError();
    // handle error...
}
result = attrUtil.addAttributeValue("ou=newOu", "description", "description_02");
if (result.hasError()) {
    let error = result.getError();
    // handle error...
}

// getAttributeValue
result = attrUtil.getAttributeValue("ou=newOu", ["objectClass", "description"]);
if (result.hasError()) {
    let error = result.getError();
    // handle error...
} else {
    let attributes = result.getAttributes();
    // do something...
    let attributesSize = attributes.size();
    // do something...
    // loop through attributes using attribute name enumeration
    let attrNameItr = attributes.getIDs();
    while (attrNameItr.hasMore()) {
        let attrName = attrNameItr.next();
        let attribute = attributes.get(attrName);
        // do something...
    }
    // loop through attributes using attribute enumeration
    let attrItr = attributes.getAll();
    while (attrItr.hasMore()) {
        let attribute = attrItr.next();
        let attrSize = attribute.size();
        let attrName = attribute.getID();
        // do something...
        // loop through attribute values using attribute value enumeration
        let attrValItr = attribute.getAll();
        while (attrValItr.hasMore()) {
            let attrValue = attrValItr.next();
            // do something...
        }
    }
}
// removeAttribute
result = attrUtil.removeAttribute("ou=newOu", "description", "description_02");
if (result.hasError()) {
    let error = result.getError();
    // handle error...
}

// setAttributeValue
result = attrUtil.setAttributeValue("ou=newOu", "description", "new_description_01");
if (result.hasError()) {
    let error = result.getError();
    // handle error...
}

// search
result = attrUtil.search("", "(objectclass=*)");
if (result.hasError()) {
    let error = result.getError();
    // handle error...
} else {
    // loop through searchResult using search result enumeration
    let searchResultItr = result.getNamingEnumeration();
    while (searchResultItr.hasMore()) {
        let searchResult = searchResultItr.next();
        let name = searchResult.getName(); // dn
        let attributes = searchResult.getAttributes(); // Attributes
        // do something...
        // refer to getAttributeValue section for iterating through Attributes
    }
}

```

--------------------------------

### Example Redis Staging Configuration File

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/configuration

This is an example of a simple YAML file containing Redis configuration details, including name, type, deployment model, hosts, and credentials. This file can be sourced by other configuration files using the '@' prefix.

```yaml
name: redis_stg
type: redis
deployment:
  model: standalone
hosts:
  - hostname: redis_stg.isvaop.top
    hostport: 6390
credential:
  username:
  password: "OBF:U2FsdGVkX18rz1DFhOzHmrG5GKCRQJsEMmTcN/5VxSA="

```

--------------------------------

### Example: Run Pre-mapping Rule with Docker

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/runjs

An example of running the runjs utility to test a pre-mapping rule named 'isvaop_premap.js' using a specified input file. This command highlights the typical parameters required for simulating a mapping rule execution in a staging environment.

```shell
docker run --rm --volume /home/runjs/isvaop-config:/var/isvaop/config --volume /home/runjs/input:/var/isvaop/input/ icr.io/ivia/ivia-oidc-provider:24.12 /app/runjs premappingrule isvaop_premap.js input.json
```

--------------------------------

### Run IVIAOP Docker Container with Bind Mount

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/deployment-docker

This command starts the IVIAOP container, detaches it to run in the background, publishes ports for external access, and mounts a local directory containing configuration files into the container. It also streams container logs. This requires Docker to be installed and the specified volume path to exist with configuration files.

```shell
[demouser@demovm ~]$ docker run --hostname isvaop-test --name isvaop-test \
    --detach \
    --publish 8436:8436 \
    --volume /home/demouser/isvaop-test:/var/isvaop/config/ \
    icr.io/ivia/ivia-oidc-provider:25.06
    
## Logs are streamed to container stdout
[demouser@demovm ~]$ docker logs -f isvaop-test
```

--------------------------------

### Install gpg2 on Debian-based Systems

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/containers

Installs the gpg2 package on Debian-based Linux distributions using apt-get. Ensure gpg2 version 2.1 or later is installed for compatibility.

```shell
[demouser@demovm ~]$ sudo apt-get install gnupg2 -y
```

--------------------------------

### Start Docker Compose Services

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/deployment-docker-compose

This command starts the services defined in your `docker-compose.yml` file in detached mode (in the background). Ensure you are in the directory containing your `docker-compose.yml` file.

```shell
[demouser@demovm ~]$ docker-compose up -d
```

--------------------------------

### Client Registration GET Request (cURL)

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/federation-longlivedrat

This cURL command demonstrates a GET request made to a client. It includes headers for authorization and cookies.

```curl
curl --location 'https://www.myidp.ibm.com/mga/sps/oauth/oauth20/register/OIDCDefinition?client_id=CRVvHu4ZZEhPLvhkbE4G' \
--header 'Authorization: Bearer Pxk9wOKtH95uJhdCcaF8' \
--header 'Cookie: AMWEBJCT!%2Fmga!JSESSIONID=0000JjCjNKyD3-wkK4-mPMoX-he:5d1a27c9-e88c-475f-ad78-d60cf6c07aa7:211d1a84-9b7f-41c6-8886-093ef5aad12b; PD-S-SESSION-ID=1_2_0_1n1NVWIFD6UV+MNtBI+bqrfGFxipCm31dUzTGyZpKhVj1PgO' \
--data ''
```

--------------------------------

### YAML: JWKS Configuration Example

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/yaml_config

Provides an example of how to configure JSON Web Key Set (JWKS) settings in a YAML file for IBM Security Verify Access. This includes specifying keystores for signing and encryption operations.

```yaml
jwks:                                                       # JSON Web Key Set (JWKS) Settings
  signing_keystore: signing_keystore                         # Keystore name containing keys related to JWT signing/signature validation.
  encryption_keystore: encryption_keystore                      # Keystore name containing keys related to JWT encryption/decryption.

```

--------------------------------

### Install gpg2 on RPM-based Systems

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/containers

Installs the gpg2 package on RPM-based Linux distributions using dnf. Ensure gpg2 version 2.1 or later is installed for compatibility.

```shell
[demouser@demovm ~]$ sudo dnf install gnupg2 -y
```

--------------------------------

### Example Kubernetes ConfigMap with Top-Level Configuration (YAML)

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/deployment-k8s

An example YAML configuration file for a Kubernetes ConfigMap, specifying version, server settings (SSL, pages), logging level, secrets, template macros, and SSL configurations. It demonstrates referencing secrets and configmaps using annotations.

```yaml
version: 24.08
server:
  ssl:
    key: 'secret:isvaop-keystores/httpserverkey.pem'
    certificate: 'secret:isvaop-keystores/httpservercert.pem'
  pages:
    type: zip
    content: 'configmap:isvaop-templates/templates.zip'
logging:
  level: debug
secrets:
  obf_key: 'secret:isvaop-obf/obf_key'
  enc_key: 'secret:isvaop-obf/private.pem'
template_macros:
  user_macros:
    - name
    - family_name
    - given_name
    - display_name
  request_macros:
    - authorization_details
    - claims
    - user_code
    - state
ssl:
  certificate:
    - ks:rt_profile_keys
  disable_hostname_verification: true
definition:
  id: 1
  name: OIDC Definition
  grant_types:
    - authorization_code
    - implicit
    - password
    - client_credentials
    - refresh_token
    - 'urn:openid:params:grant-type:ciba'
    - urn:ietf:params:oauth:grant-type:jwt-bearer
  access_policy_id: default_policy
  pre_mappingrule_id: pretoken
  post_mappingrule_id: posttoken
  base_url: 'https://auth.isvaop.com:445'
```

--------------------------------

### Attribute Source Definitions Example - YAML

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/yaml_attributesource-attributesources

This YAML snippet illustrates the definition of various attribute sources within IBM Verify Access. It includes examples for 'value', 'credential', and 'ldap' types, showcasing their respective configuration parameters like ID, name, type, and specific settings for LDAP.

```yaml
attribute_sources:
  - id: 1
    name: display_name
    type: value
    value: anonymous
  - id: 2
    name: age
    type: credential
    value: AZN_CRED_AGE
  - id: 3
    name: surname
    type: ldap
    value: sn
    scope: subtree
    filter: (cn={AZN_CRED_PRINCIPAL_NAME})
    selector: nickname,gender,sn
    srv_conn: ldap
    baseDN: dc=ibm,dc=com
```

--------------------------------

### Directory Structure for OIDC Provider Configuration

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/helloworld-docker

This snippet illustrates the expected directory structure for the OpenID Connect (OIDC) Provider configuration. It shows the main configuration files that are combined when the container starts.

```text
/var/isvaop/config
 |
 - provider.yml
 - storage.yml
 - rules.yml
 - clients.yml
 - keystore.yml
```

--------------------------------

### Extended Sample JSON Input for IBM Security Verify Access

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/tasks-runjs

This JSON snippet provides a more comprehensive example of the input structure, including additional userinfo claims, ID token details, and various context attributes used in OAuth flows.

```json
{
  "clientID": "client01",
  "claimjson": {
    "userinfo": {
      "given_name": {
        "essential": true
      },
      "nickname": null,
      "email": {
        "essential": true
      },
      "email_verified": {
        "essential": true
      },
      "picture": null,
      "http://example.info/claims/groups": null
    },
    "id_token": {
      "auth_time": {
        "essential": true
      },
      "acr": {
        "values": [
          "urn:mace:incommon:iap:silver"
        ]
      }
    }
  },
  "stsuujson": {
    "uid": "john",
    "attributeContainer": [
      {
        "name": "AUTHENTICATION_LEVEL",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          "1"
        ]
      },
      {
        "name": "AZN_CRED_AUTH_EPOCH_TIME",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          "1689835718"
        ]
      },
      {
        "name": "exp",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          1689839302
        ]
      },
      {
        "name": "iat",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          1689835719
        ]
      },
      {
        "name": "jti",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          "757f585a-26c9-11ee-a674-0a5d59d77e68"
        ]
      },
      {
        "name": "name",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          "john"
        ]
      },
      {
        "name": "nbf",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          1689835582
        ]
      },
      {
        "name": "sub",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          "john"
        ]
      },
      {
        "name": "uid",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          "john"
        ]
      }
    ],
    "contextAttributes": [
      {
        "name": "claims",
        "type": "urn:ibm:names:ITFIM:oauth:body:param",
        "values": [
          {
            "userinfo": {
              "openbanking_intent_id": {
                "value": "edbade6a-d194-4552-8efb-8c078ab605dd",
                "essential": true
              }
            },
            "id_token": {
              "openbanking_intent_id": {
                "value": "edbade6a-d194-4552-8efb-8c078ab605dd",
                "essential": true
              }
            }
          }
        ]
      },
      {
        "name": "client_assertion_alg",
        "type": "urn:ibm:names:ITFIM:oauth:body:param",
        "values": [
          "PS256"
        ]
      },
      {
        "name": "client_assertion_type",
        "type": "urn:ibm:names:ITFIM:oauth:body:param",
        "values": [
          "urn:ietf:params:oauth:client-assertion-type:jwt-bearer"
        ]
      },
      {
        "name": "client_id",
        "type": "urn:ibm:names:ITFIM:oauth:body:param",
        "values": [
          "client_ksa02"
        ]
      },
      {
        "name": "codeChallengeExist",
        "type": "urn:ibm:names:ITFIM:oauth:body:param",
        "values": [
          true
        ]
      },
      {
        "name": "code_challenge_method",
        "type": "urn:ibm:names:ITFIM:oauth:body:param",
        "values": [
          "S256"
        ]
      },
      {
        "name": "content-length",
        "type": "urn:ibm:names:ITFIM:oauth:body:param",
        "values": [
          "59"
        ]
      },
      {
        "name": "origin",
        "type": "urn:ibm:names:ITFIM:oauth:body:param",
        "values": [

```

--------------------------------

### Session Management Example in JavaScript

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/js_access_policy

Demonstrates how to manage user session attributes in JavaScript. It shows setting a session attribute, retrieving it, and comparing it to user input to determine access decisions. Session attributes are useful for maintaining state across requests, even after redirections.

```javascript
var guessedNumber = context.getRequest().getParameter("user_guess");
if (guessedNumber == undefined || guessedNumber == null) { // Challenge user
  context.getSession().setAttribute("storedNumber", 75);
  ...
  context.setDecision(Decision.challenge(handler)); // send challenge handler to guess the storedNumber
} else {
  var storedNumber = context.getSession().removeAttribute("storedNumber"); // load number
  if (storedNumber == guessedNumber) { // guessed correctly, allow it
    context.setDecision(Decision.allow());
  } else {
    ...
    context.setDecision(Decision.deny(handler)); // send deny response
  }
}
```

--------------------------------

### Unzip and Copy Starter Kit Contents

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/helloworld-docker

These shell commands show how to unzip a starter kit archive and then copy its contents into the 'IVIAOP_Volume' directory. This action populates the directory with essential configuration files.

```shell
[demouser@demovm ~]$ unzip config_starter_kit.zip -d config_starter_kit
[demouser@demovm ~]$ cp -r config_starter_kit/* IVIAOP_Volume
```

--------------------------------

### Docker Compose for IVIAOP Service

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/deployment-docker-compose

This YAML configuration defines a Docker Compose setup for the IBM Verify Identity Access OIDC Provider. It specifies the image to use, sets the hostname, maps the HTTPS port, and mounts a local directory for configuration into the container. This is a quick start example.

```yaml
services:
    
    verify-access-oidc-provider:
        image: icr.io/ivia/ivia-oidc-provider:25.06
        hostname: verify-access-oidc-provider
        ports:
            - 8436:8436
        volumes:
            - /var/isvaop-test/config:/var/isvaop/config/
```

--------------------------------

### Install gpg2 on MacOS Systems

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/containers

Installs the gpg2 package on MacOS using the Homebrew package manager. Ensure gpg2 version 2.1 or later is installed for compatibility.

```shell
[demouser@demovm ~]$ brew install gpg2
```

--------------------------------

### HttpClientV2 POST Method Documentation

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/util_http_diff

Details the compatible `httpPost` methods within the `com.ibm.security.access.httpclient.HttpClientV2` class, outlining parameters and return types.

```APIDOC
## POST /api/v1/httpPost

### Description
This endpoint supports various overloads of the `httpPost` method for making HTTP POST requests. It allows for customization of request parameters, headers, authentication, and SSL/TLS configurations.

### Method
POST

### Endpoint
`/api/v1/httpPost`

### Parameters
#### Path Parameters
None

#### Query Parameters
None

#### Request Body
This method does not inherently define a request body schema, but parameters within the call can specify body content or data to be sent.

- **urlstr** (String) - Required - The URL to which the POST request is sent.
- **headers** (Headers) - Optional - Custom headers to include in the request.
- **params** (Parameters) - Optional - Parameters to be included in the request.
- **body** (String) - Optional - The raw request body content.
- **httpsTrustStore** (String) - Optional - Path to the HTTPS trust store.
- **basicAuthUsername** (String) - Optional - Username for basic authentication.
- **basicAuthPassword** (String) - Optional - Password for basic authentication.
- **clientKeyStore** (String) - Optional - Path to the client key store.
- **clientKeyAlias** (String) - Optional - Alias for the client key.
- **protocol** (String) - Optional - The protocol to use for the request (e.g., 'TLSv1.2').
- **throwException** (boolean) - Optional - Whether to throw an exception on failure.
- **timeout** (int) - Optional - Request timeout in milliseconds.
- **sendDataAsJson** (boolean) - Optional - Whether to send data as JSON.
- **proxyServer** (String) - Optional - The proxy server to use for the request.

### Request Example
```json
{
  "urlstr": "https://example.com/api/data",
  "headers": {"Content-Type": "application/json"},
  "body": "{\"key\": \"value\"}",
  "sendDataAsJson": true
}
```

### Response
#### Success Response (200)
- **status** (int) - The HTTP status code of the response.
- **body** (String) - The response body.
- **headers** (Headers) - The response headers.

#### Response Example
```json
{
  "status": 200,
  "body": "{\"message\": \"Success\"}",
  "headers": {"Content-Type": "application/json"}
}
```
```

--------------------------------

### Run Mapping Rule Simulator (runjs) using Docker

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/runjs

This command demonstrates how to invoke the runjs utility via Docker to simulate a mapping rule. It requires mounting configuration and input volumes, specifying the rule type, mapping rule name, and optionally an input JSON file. The utility is intended for staging environments only.

```shell
docker run --rm --volume <configuration_volume>:/var/isvaop/config --volume <input_volume>:/var/isvaop/input/ icr.io/ivia/ivia-oidc-provider:24.12 /app/runjs <type> <mappingrule_name> <input_json>
```

--------------------------------

### HttpClientV2 - GET Request

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/util_http

Sends an HTTP GET request to the specified URL.

```APIDOC
## GET /url

### Description
Send HTTP GET request to the specified URL.

### Method
GET

### Endpoint
`/url`

### Parameters
#### Query Parameters
- **url** (string) - Yes - Valid HTTP URL.
- **headers** ([Headers](#)) - No - Extra HTTP headers.
- **httpsTrustStore** (string) - No - The truststore to use. If an HTTPS connection is needed and this method is set to `null`, the default truststore that is specified in the provider configs is used.
- **basicAuthUsername** (string) - No - Basic authorization header username.
- **basicAuthPassword** (string) - No - Basic authorization header password.
- **clientKeyStore** (string) - No - Client keystore. If `null`, client certificate authorization is disabled.
- **clientKeyAlias** (string) - No - Client key alias. If `null`, client certificate authorization is disabled.
- **protocol** (string) - No - Not used. This method is a mockup parameter for Verify Identity Access compatibility.
- **throwExec** (Boolean) - No - Not used. This method is a mockup parameter for Verify Identity Access compatibility.
- **timeout** (int) - No - Request timeout in seconds. A value of 0 results in a no connection timeout. If set to a value that is less than 0, the timeout is set to 5 seconds.
- **proxyServer** (string) - No - The full name of the proxy server to use. For example, https://proxy.com:443. Set to `null` if a proxy server is not needed.

### Request Example
```js
// Example usage not directly provided for GET, refer to general example.
// HttpClientV2.httpGet(url, headers, httpsTrustStore, basicAuthUsername, basicAuthPassword, clientKeyStore, clientKeyAlias, protocol, throwExec, timeout, proxyServer);
```

### Response
#### Success Response (200)
- **HttpResponse** ([HttpResponse](#)) - Description of the HTTP response.
```

--------------------------------

### Download Image with Skopeo

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/containers

Uses the skopeo command to copy a container image from a remote registry to a local directory. This is the first step in verifying the image signature, preparing the image content for validation.

```shell
skopeo copy docker://<image-tag> dir:<image-dir>

[demouser@demovm ~]$ sudo skopeo copy \
    docker://icr.io/isva/verify-access-oidc-provider:23.03 \
    dir:/home/demouser/tmp/container
```

--------------------------------

### HttpClientV2 PATCH Method Documentation

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/util_http_diff

Details the compatible `httpPatch` methods within the `com.ibm.security.access.httpclient.HttpClientV2` class, outlining parameters and return types.

```APIDOC
## PATCH /api/v1/httpPatch

### Description
This endpoint supports various overloads of the `httpPatch` method for making HTTP PATCH requests. It allows for customization of request parameters, headers, authentication, and SSL/TLS configurations.

### Method
PATCH

### Endpoint
`/api/v1/httpPatch`

### Parameters
#### Path Parameters
None

#### Query Parameters
None

#### Request Body
This method does not inherently define a request body schema, but parameters within the call can specify body content or data to be sent.

- **urlstr** (String) - Required - The URL to which the PATCH request is sent.
- **headers** (Headers) - Optional - Custom headers to include in the request.
- **params** (Parameters) - Optional - Parameters to be included in the request.
- **body** (String) - Optional - The raw request body content.
- **httpsTrustStore** (String) - Optional - Path to the HTTPS trust store.
- **basicAuthUsername** (String) - Optional - Username for basic authentication.
- **basicAuthPassword** (String) - Optional - Password for basic authentication.
- **clientKeyStore** (String) - Optional - Path to the client key store.
- **clientKeyAlias** (String) - Optional - Alias for the client key.
- **protocol** (String) - Optional - The protocol to use for the request (e.g., 'TLSv1.2').
- **throwException** (boolean) - Optional - Whether to throw an exception on failure.
- **timeout** (int) - Optional - Request timeout in milliseconds.
- **sendDataAsJson** (boolean) - Optional - Whether to send data as JSON.
- **proxyServer** (String) - Optional - The proxy server to use for the request.

### Request Example
```json
{
  "urlstr": "https://example.com/api/resource/123",
  "headers": {"Content-Type": "application/json"},
  "body": "{\"field\": \"new_value\"}",
  "sendDataAsJson": true
}
```

### Response
#### Success Response (200)
- **status** (int) - The HTTP status code of the response.
- **body** (String) - The response body.
- **headers** (Headers) - The response headers.

#### Response Example
```json
{
  "status": 200,
  "body": "{\"message\": \"Resource updated\"}",
  "headers": {"Content-Type": "application/json"}
}
```
```

--------------------------------

### Revoke Tokens (cURL)

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/tasks-tokenexchange

Examples of revoking tokens using cURL. The first example revokes only the device_secret and tokens from the authorization code flow. The second example revokes device_secret, authorization code flow tokens, and token exchange flow tokens by including the 'deleteAllTokens: true' header.

```curl
curl --location 'https://isvaop.ibm.com:445/isvaop/oauth2/revoke' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=tokenGenerated' \
--data-urlencode 'client_secret=asfasdfawqdewq' \
--data-urlencode 'token=PJEef6mv4z9uxdXrns7HpEOnuhPwxPRFA46d8TjXwjQ.zUlg_vF6Ag1P9ndm8EhS7Mpyd4Jd-gMgJk357lv2yvy_N2yOaieIqO7fIh5AzASmCZ0Ujmp87obPnkYT13y-sQ'
```

```curl
curl --location 'https://isvaop.ibm.com:445/isvaop/oauth2/revoke' \
--header 'deleteAllTokens: true' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=tokenGenerated' \
--data-urlencode 'client_secret=asfasdfawqdewq' \
--data-urlencode 'token=PJEef6mv4z9uxdXrns7HpEOnuhPwxPRFA46d8TjXwjQ.zUlg_vF6Ag1P9ndm8EhS7Mpyd4Jd-gMgJk357lv2yvy_N2yOaieIqO7fIh5AzASmCZ0Ujmp87obPnkYT13y-sQ'
```

--------------------------------

### Shell: Run IBM Verify Access OIDC Provider Docker Container

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/helloworld-docker

This shell command demonstrates how to run the IBM Verify Access OIDC Provider Docker container. It specifies the container name, published port, volume mapping for configuration files, and the image to use.

```shell
[demouser@demovm ~]$ docker run --hostname isvaop-test --name isvaop-test \
  --publish 8436:8436 \
  --volume /home/IVIAOP_Volume:/var/isvaop/config \
  icr.io/ivia/ivia-oidc-provider:25.06
```

--------------------------------

### OAuthMappingExtUtils - API Method Differences

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/util_oauth_diff

Details the differences in supported methods between `OAuthMappingExtUtils` and `com.tivoli.am.fim.trustserver.sts.utilities.OAuthMappingExtUtils`.

```APIDOC
## OAuthMappingExtUtils API Method Differences

### `OAuthMappingExtUtils` vs `com.tivoli.am.fim.trustserver.sts.utilities.OAuthMappingExtUtils`

#### Constructors

Not applicable.

#### Supported Methods

*   `associate`:
    *   `associate(java.lang.String stateID, java.lang.String attrKey, java.lang.String attrValue)` is supported.
    *   `associate(java.lang.String stateID, java.lang.String attrKey, java.lang.String attrValue, boolean sensitive, boolean readonly)` is **NOT** supported.
*   `disassociate`
*   `getAssociation`
*   `getAssociationKeys`: Refer to [List Type Differences](#list-type-differences) for return type differences.
*   `retrieveAllAssociations`: Refer to [Map Type Differences](#map-type-differences) for return type differences.
*   `batchCreate`: Refer to [Map Type Differences](#map-type-differences) for input argument type differences.
*   `batchUpdate`: Refer to [Map Type Differences](#map-type-differences) for input argument type differences.
*   `batchDelete`
*   `throwSTSException`
*   `throwSTSUserMessageException`
*   `throwSTSCustomUserPageException`
*   `throwSTSCustomUserMessageException`
*   `throwSTSInvalidGrantMessageException`
*   `throwSTSAccessDeniedMessageException`

#### Unsupported Methods

*   `createClient`
*   `createTokenElement`
*   `deleteAllTokensForUser`
*   `deleteClient`
*   `deleteGrant`
*   `deleteHashedToken`
*   `deleteToken`
*   `deleteTokens`
*   `extractIssuer`
*   `generateRandomString`
*   `getActiveToken`
*   `getActiveTokens`
*   `getAllActiveTokensForUser`
*   `getAllTokensForUser`
*   `getCertificateChain`
*   `getCertificateThumbprint`
*   `getCertificateThumbprint_S256`
*   `getClient`
*   `getClientsByCompanyName`
*   `getClientsByContactPerson`
*   `getClientsByEmail`
*   `getDefinition`
*   `getDefinitionByID`
*   `getEmptyMap`
*   `getGrants`
*   `getToken`
*   `getTokens`
*   `httpGet`
*   `httpPost`
*   `isFapiCompliantByDefinitionID`
*   `isOidcCompliantByDefinitionID`
*   `parseSTSUUToJson`
*   `retrieveActor`
*   `retrieveAllAssociations`
*   `SHA256Sum`
*   `SHA384Sum`
*   `SHA512Sum`
*   `storeJwtActor`
*   `updateClient`
*   `updateToken`
```

--------------------------------

### Make HTTP POST Request using HttpClientV2

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/util_http

Demonstrates how to make an HTTP POST request using the HttpClientV2 utility. It shows how to construct headers and payloads using Headers and Parameters objects or a raw string. Error handling is included.

```javascript
let header = new Headers();
header.addHeader("Content-Type", "application/json");
header.addHeader("Accept-Language", "ja");

let payload = new Parameters();
payload.addParameter("scope", ["openid", "profile", "email"])
payload.addParameter("intent-id", "5298SFFLS735L");

// use Parameters to construct payload
let rsp = HttpClientV2.httpPost("https://www.externalconsent.org", headers, payload, "rt_profile", null, null, null, null, null, null, 5, true, null);
if (rsp.hasError()) {
    // handle error...
} else {
    // process response
}

// use string as payload
let rsp2 = HttpClientV2.httpPost("https://www.externalconsent.org", headers, "string payload", "rt_profile", null, null, null, null, null, null, 5, false, null);
if (rsp.hasError()) {
    // handle error...
} else {
    // process response
}
```

--------------------------------

### HttpClientV2: HTTP GET Request

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/util_http

Sends an HTTP GET request to a specified URL. This function can include headers, truststores, basic authentication credentials, client keystores, and proxy server configurations. It returns an HttpResponse object.

```javascript
HttpClientV2.httpGet(url, headers, httpsTrustStore, basicAuthUsername, basicAuthPassword, clientKeyStore, clientKeyAlias, protocol, throwExec, timeout, proxyServer)
```

--------------------------------

### LDAP Server Connection Configuration Example (YAML)

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/yaml_config

An example of how to configure an LDAP server connection. This includes specifying the connection name, type, host details, credentials, SSL settings, and connection pool parameters. Note that passwords should be obfuscated for security.

```yaml
server_connections:
  - name: ldap_staging
    type: ldap
    hosts:
      - hostname: openldap
        hostport: 636
    credential:
      bind_dn: cn=root,secAuthority=Default
      bind_password: 'OBF:gJDSuqEFmORCR2Uw3FsAmFKomjYLmhMwdDG2XoUxtQ0='
    ssl:
      certificate:
        - ks:ldap_keys
      mutual_auth:
        key: ks:rt_profile_keys/ldap
        certificate: ks:rt_profile_keys/ldap
        ca:
          - ks:rt_profile_keys/ca
      disable_hostname_verification: false
    conn_settings:
      max_pool_size: 50
      connect_timeout: 3
      aged_timeout: 5
```

--------------------------------

### Create and Copy ISVAOP Signing Keys

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/helloworld-docker

These shell commands first create a subdirectory for 'isvaop_signing' within the keystore directory and then copy signing-related keys into it. This setup is essential for signing tokens and other security-related operations.

```shell
[demouser@demovm ~]$ mkdir  ~/IVIAOP_Volume/keystore/isvaop_signing
[demouser@demovm ~]$ cp https_keys/* ~/IVIAOP_Volume/keystore/isvaop_signing/
```

--------------------------------

### JWT Bearer Token Request Example

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/tasks-jwtbearer

This section provides an example of a cURL request to obtain a JWT bearer token. It demonstrates the necessary headers and form-urlencoded data, including client credentials and the JWT assertion.

```APIDOC
## POST /isvaop/oauth2/token

### Description
Obtains an access token using the JWT Bearer grant type.

### Method
POST

### Endpoint
`https://isvaop.ibm.com:445/isvaop/oauth2/token`

### Parameters
#### Query Parameters
None

#### Request Body
- **client_id** (string) - Required - The client ID for authentication.
- **client_secret** (string) - Required - The client secret for authentication (used when `token_endpoint_auth_method` is `client_secret_post`).
- **grant_type** (string) - Required - Must be `urn:ietf:params:oauth:grant-type:jwt-bearer`.
- **assertion** (string) - Required - The JWT assertion.

### Request Example
```curl
--location 'https://isvaop.ibm.com:445/isvaop/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=client01jwtbearerconf' \
--data-urlencode 'client_secret=asfasdfawqdewq' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer' \
--data-urlencode 'assertion=eyJhbGciOiJQUzI1NiIsInR5cCI6Imp3dCIsImtpZCI6Imp3dGJlYXJlciJ9.eyJzdWIiOiJwZXRlciIsImF1ZCI6Imh0dHBzOi8vd3d3Lm15aWRwLmlibS5jb20vaXN2YW9wL29hdXRoMi90b2tlbiIsImp0aSI6ImY2MjcyYTMwLWJmMWUtMTFlZS1iYWM3LTI3YzYzNTI2NDU4YyIsImlzcyI6Imh0dHBzOi8vd3d3LmlibS5jb20iLCJpYXQiOjE3MDY1ODUwMTksImV4cCI6MTcwNjU4NTYxOX0.GnPhvx9MjafK3OTBmazbNuBBI5zJH5CEeephxwUD9lG3FnsCCU4x6H42Svr1NZ5APOhhCGmVJg7byG8OB159uHUMeo96suUttLDgnbawJSfwr7kmGYhWtIiWBTDQi_YGX0jR9Nsn33nn2OVnDbWRDE7c6Qxav06hbp3TWCsqR8l8_0aQJAV4OV2TXFXtyLjNfUxP43nphOlaNpSSvzEvpcpXKfKqsFgMnY_BR12p4qIBLSWRXpYOQTJLj66jvaPccQ8MtJEgOCertWctCIn5inl48_Rw5LLVc6J9MZAxBHnxQkfsHNs0OTEOsTZEBFZVFvMWb0Ajv2TQcxUPEZNE6xvy7DYW2qHfWkrh5yctu4-WgIgoz3yhuU3CR_JwMoBrwo6F4qyVnIhFHpUt5JQ-RdKTuZUwIIrISFHwelzRr_g_B884vP-K5Fb_pg5F7nJHQHXpfed5CIxLdPiM8vYkwXGRXJpj7HksYCmbr_akiupbpnG7hmvnEcBeuV8Y4Td-8eF_qetRGkOWCNJ2C9j48BIoAC0gSmzYn_mH4maMMh2TXlNHHFNT6wkNS2JDCJlMb5WwZ-4KWXx2VgRdbwp8HtPupGxuYdhGluGmWLo1uqZuNpbFS5LnqBAa3YrfBmkjRAnWuGTeSPe3rnyZ8VqUltWAeRRTRA_3_S3EY42IlS0'
```

### Response
#### Success Response (200)
- **access_token** (string) - The access token.
- **token_type** (string) - The type of token (e.g., Bearer).
- **expires_in** (integer) - The lifetime in seconds of the access token.

#### Response Example
```json
{
  "access_token": "your_access_token",
  "token_type": "Bearer",
  "expires_in": 3600
}
```
```

--------------------------------

### Build Custom IVIAOP Docker Image

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/deployment-docker

This Dockerfile demonstrates how to create a new Docker image that includes the IVIAOP container and custom configuration files. The configuration files are copied from a local 'data' directory into the container's configuration path. This requires Docker to be installed and the 'data' directory to be present.

```dockerfile
##
## You can build this image by issuing the following command:
##          docker build -t acme-isvaop:1.0 $PWD
##

## The container is based on the IVIAOP container.
FROM icr.io/ivia/ivia-oidc-provider:25.06

## Copy the configuration files from the data directory
## to the docker image.
COPY data/. /var/isvaop/config/


## Some labels which will be associated with the image.
LABEL maintainer="isvaop@acme.com" \
    vendor="ACME"
```

--------------------------------

### Install Instana Agent using Helm Chart

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/references-monitoring

Installs the Instana agent on a Kubernetes platform using a Helm chart. This command requires the Instana agent key, download key, endpoint host, and port, along with cluster and zone names.

```bash
helm install instana-agent \
   --repo https://agents.instana.io/helm \
   --namespace instana-agent \
   --create-namespace \
   --set agent.key=QHAvLwgRSH11111zGGGnTA \
   --set agent.downloadKey=QHAvLwgRSH11111zGGGnTA \
   --set agent.endpointHost=ingress-test.instana.io \
   --set agent.endpointPort=443 \
   --set cluster.name='IVIAOP' \
   --set zone.name='jp-tok' \
   instana-agent
```

--------------------------------

### Sample JSON Input for IBM Security Verify Access

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/tasks-runjs

This JSON snippet demonstrates the expected input format, including client ID, claim definitions for user info and ID tokens, and STS Universal User attributes.

```json
{
  "clientID": "client01",
  "claimjson": {
    "userinfo": {
      "given_name": {
        "essential": true
      }
    },
    "id_token": {
      "auth_time": {
        "essential": true
      }
    }
  },
  "stsuujson": {
    "uid": "john",
    "attributeContainer": [
      {
        "name": "AUTHENTICATION_LEVEL",
        "type": "urn:ibm:names:ITFIM:5.1:accessmanager",
        "values": [
          "1"
        ]
      }
    ],
    "contextAttributes": [
      {
        "name": "client_assertion_alg",
        "type": "urn:ibm:names:ITFIM:oauth:body:param",
        "values": [
          "PS256"
        ]
      }
    ]
  }
}
```

--------------------------------

### Token Exchange Request Example (cURL)

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/tasks-tokenexchange

An example cURL command to perform a token exchange request. This demonstrates the necessary parameters like client ID, secret, grant type, subject token, and actor token for exchanging tokens.

```curl
curl --location 'https://isvaop.ibm.com:445/isvaop/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=clientTokenExchange' \
--data-urlencode 'client_secret=asfasdfawqdewq' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'subject_token=_RFAfJNeB6H30IfDW1udc271ytq5BG5WwFSTvacNG1g.Oyr-LMYFrGXn9NrLPcTKOvAisGRGYUbtoyLkyD-BZCfNSgbW-EnWpAzRHZXTzMioGK2e9HcM0668nXATCStHWg' \
--data-urlencode 'subject_token_type=urn:ietf:params:oauth:token-type:access_token' \
--data-urlencode 'actor_token=JFQu9BDahuciIVICnLcmTkeMJeng92p38IKD--fsYmo._-ZQpBn6FP-BxraacU0snZdlm4ndnIBPmRHZcWixnleUmJfDhxladSAJMKLidW9-QX4DC1KwsPvX_f16_Keh8g' \
--data-urlencode 'actor_token_type=urn:ietf:params:oauth:token-type:access_token'
```

--------------------------------

### Install Dynatrace Operator and Configure Secrets

Source: https://docs.verify.ibm.com/ibm-security-verify-access/docs/references-monitoring

A sequence of kubectl commands to install the Dynatrace operator on a Kubernetes platform. It includes creating a namespace, applying the operator manifest, waiting for the webhook pod to be ready, and creating a secret with Dynatrace API and data ingest tokens.

```shell
$kubectl create namespace dynatrace
$kubectl apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.0.0/kubernetes.yaml
$kubectl apply -f csi.yaml 
$kubectl -n dynatrace wait pod --for=condition=ready --selector=app.kubernetes.io/name=dynatrace-operator,app.kubernetes.io/component=webhook --timeout=300s
$kubectl -n dynatrace create secret generic dynakube --from-literal="apiToken=<apiToken>" --from-literal="dataIngestToken=<dataIngestToken>"
$kubectl apply -f cloudnative.yaml
```
Tokens:
Raw