Running the sample files on the sample server

You can work on the preconfigured sample files for OpenID Connect and run on the Liberty sample server to check your configuration.

Before you begin

You make sure that the sample server is operational, and back up the original files before you configure.

  1. Start the sample server. For more information about the sample server, see Using the sample server.
  2. Connect to the Decision Center Business console, and the Rule Execution Server console by using basic authentication. Click some features in the consoles to verify the Operational Decision Manager applications work.
  3. Stop the sample server.
  4. Back up your Liberty configuration files.

The preconfigured sample files are in the <ODM_InstallDir>/shared/oidc directory.

Tip: Put your OpenID Connect Provider URLs and credentials together in any text file so that you can easily access the information.

Step 1: Customizing the sample files

Procedure

  1. Copy all of the sample XML files to the <WLP_HOME>/usr/servers/<server_name> directory:
    • server.xml
    • tls-datasource.xml
    • filters.xml
    • oidc-liberty.xml
    • oidc-ums.xml
    • oidc-ibmid.xml

    The sample server.xml file is partitioned by the other XML files, that is, the tls-datasource.xml, filters.xml, and oidc-liberty.xml files are included in the server.xml file.

    You can replace the oidc-liberty.xml file with either oidc-ums.xml or oidc-ibmid.xml. You can use only one of the three files. You can delete the other two files when you decide which oidc-<name>.xml file to be used.

  2. Copy the sample jvm.options file to the <WLP_HOME>/usr/servers/<server_name> directory.
  3. Copy the sample mykeystore.jks, mytruststore.jks, and OdmOidcProviders.json files to the <WLP_HOME>/usr/servers/<server_name>/resources/security directory.

    The OdmOidcProviders.json file is loaded by Decision Center by using Java™ resources, so it must be copied into this directory.

    You work on the OdmOidcProvidersRD.json and eclipse.ini files for Rule Designer in Step 5.

  4. Edit server.xml, tls-datasource.xml, and the oidc-<name>.xml of your choice by using your URLs and credentials.

    For more information about the server.xml file, see Configuring Relying Parties in the Liberty server.

  5. Edit the jvm.options file. Use one of the three blocks in the file, and remove the two other blocks.

    For more information about the jvm.options file, see Passing parameters and registering the truststore and Passing parameters to the Decision Center Business console.

  6. Update the mykeystore.jks and mytruststore.jks files and the associated password.

    The keystore contains zero entry, and it must contain the alias to the Operational Decision Manager server certificate.

    The truststore contains zero entry, and it must contain the certificate for the OpenID Connect server (for authentication) and for Rule Execution Server (for deployment from Decision Center to Rule Execution Server).

Step 2: Protecting the hosted transparent decision service WAR file

Procedure

  1. Follow the steps that are described in Configuring the hosted transparent decision service.
  2. Copy the protected DecisionService.war file to the <WLP_HOME>/usr/servers/<server_name>/apps directory.

Step 3: Testing the login to the Operational Decision Manager servers

Procedure

  1. Start the Operational Decision Manager server by using the following command: 
    <WLP_HOME>/bin/server start <server_name>
    Note: Do not use the shortcut or scripts that are provided by the sample server to start the server.
  2. Access the Operational Decision Manager applications by using the following URLs: 
    https://localhost:9444/decisioncenter
    https://localhost:9444/decisioncenter
    https://localhost:9444/res
    Note: You must access these applications by using HTTPS.

    These URLs assume that you have registered the redirect URI in your OpenID Connect Provider by using these URLs.

  3. Verify the certificate in each application, and then verify the OpenID Connect single sign-on (SSO) works.

Step 4: Configuring Decision Center for deployment

Procedure

  1. Stop the server.
  2. Edit the <WLP_HOME>/usr/servers/<server_name>/resources/security/OdmOidcProviders.json file and put your URLs and credentials.

    For more information about the JSON file, see Defining OpenID Connect Providers for Decision Center.

  3. Start the server.
  4. Upload the OdmOidcProviders.json file in Decision Center.

    For more information about uploading the JSON file, see Selecting an OpenID Connect Provider in the Decision Center Business console.

  5. Create a server by using OpenID Connect.
    You can now do the following actions:
    • Deploy a decision service project to Rule Execution Server by using OpenID Connect
    • Run a test suite with Decision Runner by using OpenID Connect
    • Run a simulation with Decision Runner by using OpenID Connect

Step 5: Configuring Rule Designer

Procedure

  1. Edit the sample OdmOidcProvidersRD.json file.

    For more information about the JSON file, see Defining OpenID Connect Providers for Rule Designer.

  2. Edit the sample eclipse.ini file and copy it in the directory where the eclipse.ini is located for Rule Designer.

    For more information about the eclipse.ini file, see Passing parameters to Rule Designer.

  3. Prepare or copy the truststore file. This file must contain the entries for OpenID Connect Provider, Decision Center (for synchronization), and Rule Execution Server (for deployment).
  4. Start Rule Designer and test the connections.

    For more information about selecting an OpenID Connect Provider, see Selecting an OpenID Connect Provider in Rule Designer.

    You can now do the following actions:
    • Synchronize with Decision Center.
    • Deploy a decision service project to Rule Execution Server by using OpenID Connect

Step 6: Invoking APIs with a bearer header

About this task

When you invoke Decision Center API or Rule Execution Server decision service API, you must attach the access token in the bearer header.

The same access token is also required for running the Ant tasks or using the Swagger user interface.

Procedure

Run the following script that uses the password flow to obtain a token: 
curl -k -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" \
     -d "scope=openid&grant_type=password&client_id=${client_id}&client_secret=${client_secret}&username=${username}&password=${password}" \
     ${token_url}
Placeholder Description
${client_id} The client ID
${client_secret} The client secret
${username} The username of the account (the resource owner) to obtain the access token
${password} The password of the account (the resource owner) to obtain the access token
${token_url} The token URL

The access token is valid for a defined duration, generally 2 hours. The client application is responsible to renew the token by using the refresh token or another password flow.

Then, the access token is attached in the HTTP request bearer header as shown in this example:

Authorization: Bearer <access_token>