WebADE Access

The GETOK application aims to reduce the barriers to setting up applications in WebADE, obtaining WebADE Service Clients, and setting up roles and permissions. The existing process for this onboarding is described below in "Existing Process for Obtaining WebADE Service Client".

Access to WebADE services through GETOK

If access to a WebADE service is needed, an application development team using GETOK can request to have their application acronym granted special permissions to use WebADE.
There are currently 2 of these special permissions:

• WEBADE_PERMISSION - The application can grant access to the common services in WebADE that are currently supported by GETOK.
• WEBADE_PERMISSION_NROS_DMS - The application can grant access to a special scope in DMS that allows access to all NROS documents in WCC through DMS. This role must be approved by the NROS data custodian before going forward.

In order to apply a permission, the role named above will need to be granted to one of the groups that the user belongs to in keycloak. As well the acronym must have the flags enabled in the GETOK database.

Existing Process for Obtaining WebADE Service Client

Prerequisites

• The new application being built has its acronym approved and an approved IRS entry.
• JIRA and Bitbucket projects are created for the new application. These can be requested via an ITREQUESTS JIRA ticket.

Set up desired application configuration

WebADE application configuration is controlled by POSTing JSON files (known as webade-cfg) to the WEBADE-API. This pocess is idempotent, in that this config file will always set the current state of a WebADE application configuration to what is POSTed at that time.

This configuration JSON can be fetched again via a GET on the same API endpoint.

The application configuration for the new app and service client can be created as a bare-bones webade-cfg. An example is presented below.

{
    "@type": "http://webade.gov.bc.ca/applicationConfiguration",
    "applicationAcronym": "GETOK",
    "custodianNumber": 0,
    "applicationName": "Get Webade Token",
    "applicationDescription": "Description here",
    "applicationObjectPrefix": null,
    "enabledInd": true,
    "distributeTypeCd": null,
    "managementEnabledInd": false,
    "applicationVersion": null,
    "reportedWebadeVersion": null,
    "actions": [
    ],
    "wdePreferences": [
    ],
    "applicationPreferences": [],
    "globalPreferences": [],
    "defaultUserPreferences": [],
    "profiles": [
    ],
    "serviceClients": [
        {
            "accountName": "GETOK_SERVICE",
            "secret": "#{service.client.GETOK_SERVICE.password}",
            "oauthScopes": [],
            "oauthGrantTypes": [],
            "oauthRedirectUrls": [],
            "oauthAccessTokenValidity": null,
            "oauthRefreshTokenValidity": null,
            "oauthAdditionalInformation": "{\"autoapprove\":\"true\"}",
            "authorizations": [
            ]
        }
    ],
    "groupAuthorizations": []
}

The applicationAcronym and accountName fields would correspond to the new app being added. The secret field is described in the "SDK Config setup" section below.

Add webade-cfg and structure to Bitbucket project

In the Bitbucket project for

SDK Config setup

The current process for filling variables into deployed components occurs during the Jenkins job promotion process. Components have variables marked with #{}, that correspond to values that are configured in a shared Bitbucket repository called SDK Config.

Repository link: sdk-config

These variables can map to static values, or other placerholder variables that Jenkins can resolve at promotion time.

For purposes of including the service client secret, this would correspond to a stored password in a Jenkins Credential. The credential can keep different values based on which environment the promotion is occuring against (example: INT, TEST, PROD).

SDK Config can keep sets of configuration in a heirarchical structure, including environmental and component defaults, but that is out of the scope of this document. For these purposes, just the map from the placeholder in the application configuration to the Jenkins Credential is required, and since Jenkins can vary this per environment it can just be added in a default file.

The current convention is that SDK config properties go into master under the folder for the relevant application acronym.

For this GETOK application example, the following file was created

getok-webade-cfg.properties
at
https://apps.nrs.gov.bc.ca/int/stash/projects/SDK/repos/sdk-config/browse/GETOK/

This name corresponds to the Bitbucket repository where the application configuration JSON is stored. The contents are as below

target-slave-name=wii2
deployer.class=ca.bc.gov.nrs.cd.util.RestDeployer

service.client.GETOK_SERVICE.password=${GETOK_SERVICE.password}

GETOK_SERVICE corresponds with the name of the Jenkins Credential (and .password is the password field).