From d5484f78d46978f444ea185bdbc947ee984693aa Mon Sep 17 00:00:00 2001 From: Laurent GRATEAU Date: Fri, 20 Oct 2023 10:22:31 +0200 Subject: [PATCH] Azuread privatekeyjwt (#161) * Update README.md * Update README_FINE_GRAIN_PERMISSION.md * Update README_FINE_GRAIN_PERMISSION.md * https://jsw.ibm.com/browse/DBACLD-97311 * Update README.md * SiaSin review * SiaSin review * Update README.md * https://jsw.ibm.com/browse/DBACLD-110090 * Update README.md * first private_key_jwt doc * Update README_WITH_PRIVATE_KEY_JWT.md * Rule Designer Update * new images * Azure AD rename in Microsoft Entra ID * Update README.md * Update README.md * Update README.md * Update README_WITH_PRIVATE_KEY_JWT.md * Update README_WITH_CLIENT_SECRET.md * Update README_WITH_PRIVATE_KEY_JWT.md * Update README_WITH_CLIENT_SECRET.md * First Review (#159) * First Review * Finalize change in the menu * Update README.md * Update README_WITH_PRIVATE_KEY_JWT.md * Update README_WITH_PRIVATE_KEY_JWT.md * Update README_WITH_PRIVATE_KEY_JWT.md * Update README_WITH_PRIVATE_KEY_JWT.md * new script --------- Co-authored-by: Mathias Mouly --- authentication/AzureAD/README.md | 544 ++---------------- .../AzureAD/README_WITH_CLIENT_SECRET.md | 506 ++++++++++++++++ .../AzureAD/README_WITH_PRIVATE_KEY_JWT.md | 468 +++++++++++++++ authentication/AzureAD/azuread-odm-script.zip | Bin 7608 -> 11935 bytes .../generateTemplateForPrivateKeyJWT.sh | 78 +++ .../AzureAD/images/AddRDCallback.png | Bin 0 -> 376433 bytes authentication/AzureAD/images/AddURI.png | Bin 127132 -> 361779 bytes .../OdmOidcProviders.json | 14 + .../openIdParameters.properties | 8 + .../openIdWebSecurity.xml | 26 + .../webSecurity.xml | 70 +++ 11 files changed, 1217 insertions(+), 497 deletions(-) create mode 100644 authentication/AzureAD/README_WITH_CLIENT_SECRET.md create mode 100644 authentication/AzureAD/README_WITH_PRIVATE_KEY_JWT.md create mode 100755 authentication/AzureAD/generateTemplateForPrivateKeyJWT.sh create mode 100644 authentication/AzureAD/images/AddRDCallback.png create mode 100644 authentication/AzureAD/templates_for_privatekeyjwt/OdmOidcProviders.json create mode 100644 authentication/AzureAD/templates_for_privatekeyjwt/openIdParameters.properties create mode 100644 authentication/AzureAD/templates_for_privatekeyjwt/openIdWebSecurity.xml create mode 100644 authentication/AzureAD/templates_for_privatekeyjwt/webSecurity.xml diff --git a/authentication/AzureAD/README.md b/authentication/AzureAD/README.md index 228ee3a7..3dc7b11e 100644 --- a/authentication/AzureAD/README.md +++ b/authentication/AzureAD/README.md @@ -1,36 +1,40 @@ -# Configuration of ODM with Azure AD +# Configuration of ODM with Microsoft Entra ID -- [What is Azure AD?](#what-is-azure-ad) -- [About this task](#about-this-task) -- [ODM OpenID flows](#odm-openid-flows) -- [Prerequisites](#prerequisites) -- [Log into the Azure AD instance](#log-into-the-azure-ad-instance) -- [Manage groups and users](#manage-groups-and-users) -- [Set up an application](#set-up-an-application) -- [Prepare your environment for the ODM installation](#prepare-your-environment-for-the-odm-installation) -- [Install your ODM Helm release](#install-your-odm-helm-release) -- [Complete post-deployment tasks](#complete-post-deployment-tasks) +- [Configuration of ODM with Microsoft Entra ID](#configuration-of-odm-with-microsoft-entra-id) +- [Introduction](#introduction) + - [What is Microsoft Entra ID?](#what-is-microsoft-entra-id) + - [About this task](#about-this-task) + - [ODM OpenID flows](#odm-openid-flows) + - [Prerequisites](#prerequisites) + - [Create a Microsoft Entra ID account](#create-a-microsoft-entra-id-account) +- [Configure a Microsoft Entra ID instance for ODM Part 1](#configure-a-microsoft-entra-id-instance-for-odm-part-1) + - [Log into the Microsoft Entra ID instance](#log-into-the-microsoft-entra-id-instance) + - [Manage groups and users](#manage-groups-and-users) + - [Choose the way to set up your application](#choose-the-way-to-set-up-your-application) +- [License](#license) # Introduction -In the context of the Operational Decision Manager (ODM) on Certified Kubernetes offering, ODM for production can be configured with an external OpenID Connect server (OIDC provider), such as the Azure AD cloud service. +In the context of the Operational Decision Manager (ODM) on Certified Kubernetes offering, ODM for production can be configured with an external OpenID Connect server (OIDC provider), such as the Microsoft Entra ID cloud service. -## What is Azure AD? +## What is Microsoft Entra ID? -Azure Active Directory ([Azure AD](https://azure.microsoft.com/en-us/services/active-directory/#overview)), is an enterprise identity service that provides single sign-on, multifactor authentication, and conditional access. This is the service that we use in this article. +Microsoft Entra ID is the [new name for Azure AD](https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/new-name). + +[Microsoft Entra ID](https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id#overview), is an enterprise identity service that provides single sign-on, multifactor authentication, and conditional access. This is the service that we use in this article. ## About this task -You need to create a number of secrets before you can install an ODM instance with an external OIDC provider such as the Azure AD service, and use web application single sign-on (SSO). The following diagram shows the ODM services with an external OIDC provider after a successful installation. +You need to create a number of secrets before you can install an ODM instance with an external OIDC provider such as the Microsoft Entra ID service, and use web application single sign-on (SSO). The following diagram shows the ODM services with an external OIDC provider after a successful installation. ![ODM web application SSO](images/diag_azuread_interaction.jpg) -The following procedure describes how to manually configure ODM with an Azure AD service. +The following procedure describes how to manually configure ODM with an Microsoft Entra ID service. ## ODM OpenID flows @@ -38,9 +42,9 @@ OpenID Connect is an authentication standard built on top of OAuth 2.0. It adds Terminology: -- **OpenID provider** — The authorization server that issues the ID token. In this case, Azure AD is the OpenID provider. +- **OpenID provider** — The authorization server that issues the ID token. In this case, Microsoft Entra ID is the OpenID provider. - **end user** — The end user whose details are contained in the ID token. -- **relying party** — The client application that requests the ID token from Azure AD. +- **relying party** — The client application that requests the ID token from Microsoft Entra ID. - **ID token** — The token that is issued by the OpenID provider and contains information about the end user in the form of claims. - **claim** — A piece of information about the end user. @@ -50,11 +54,11 @@ The Authorization Code flow is best used by server-side apps in which the source The Client Credentials flow is intended for server-side (AKA "confidential") client applications with no end user, which normally describes machine-to-machine communication. The application must be server-side because it must be trusted with the client secret, and since the credentials are hard-coded, it cannot be used by an actual end user. It involves a single, authenticated request to the token endpoint which returns an access token. -![Azure AD Client Credential Flow](images/ClientCredential.png) (© Microsoft) +![Microsoft Entra ID Client Credential Flow](/images/AzureAD/ClientCredential.png) (© Microsoft) The Microsoft identity platform supports the OAuth 2.0 Resource Owner Password Credentials (ROPC) grant, which allows an application to sign in the user by directly handling their password. Microsoft recommends you do not use the ROPC flow. In most scenarios, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks which are not present in other flows. You should only use this flow when other more secure flows cannot be used. -![Azure AD Password Flow](images/PasswordFlow.png) (© Microsoft) +![Microsoft Entra ID Password Flow](/images/AzureAD/PasswordFlow.png) (© Microsoft) ## Prerequisites @@ -66,11 +70,11 @@ You need the following elements: - Access to a CNCF Kubernetes cluster - An admin Azure AD account -### Create an Azure AD account +### Create a Microsoft Entra ID account -If you do not own an Azure AD account, you can sign up for a [free Azure AD developer account](https://azure.microsoft.com/en-us/services/active-directory/) +If you do not own an Microsoft Entra ID account, you can sign up for a [free Microsoft Entra ID developer account](https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id) -# Configure an Azure AD instance for ODM (Part 1) +# Configure a Microsoft Entra ID instance for ODM (Part 1) In this section, we explain how to: @@ -78,9 +82,9 @@ In this section, we explain how to: - Set up an application - Configure the default Authorization server -## Log into the Azure AD instance +## Log into the Microsoft Entra ID instance -After activating your account by email, you should have access to your Aure AD instance. [Sign in to Azure](https://portal.azure.com/#home). +After activating your account by email, you should have access to your Microsoft Entra ID instance. [Sign in to Azure](https://portal.azure.com/#home). ## Manage groups and users @@ -114,7 +118,7 @@ After activating your account by email, you should have access to your Aure AD i * In Assignments fill in: * Click on Add group and select odm-admin - * Click **Review + create** and then **Create**. + * Click **Review + create ** and then **Create or Invite**. ![New User Basics](images/NewUserBasics.png) ![New User Assignments](images/NewUserAssignments.png) @@ -128,487 +132,33 @@ After activating your account by email, you should have access to your Aure AD i Repeat this step for each user that you want to add. -## Set up an application - -1. Create the *ODM application*. - - In **Azure Active Directory** / **App registration**, click **New Registration**: - - * Name: **ODM Application** - * Supported account types / Who can use this application or access this API?: select `Accounts in this organizational directory only (Default Directory only - Single tenant)` - * Click **Register** - - ![New Web Application](images/RegisterApp.png) - -2. Retrieve Tenant and Client information. - - In **Azure Active Directory** / **App Registration**, select **ODM Application** and click **Overview**: - - * Application (client) ID: **Client ID**. It will be referenced as `CLIENT_ID` in the next steps. - * Directory (tenant) ID: **Your Tenant ID**. It will be referenced as `TENANT_ID` in the next steps. - - ![Tenant ID](/images/AzureAD/GetTenantID.png) - -3. Generate an OpenID client secret. - - In **Azure Active Directory** / **App registrations**, select **ODM Application**: - - * From the Overview page, click on the link Client credentials: **Add a certificate or secret** or on the **Manage / Certificates & secrets** tab - * Click + New Client Secret - * Description: `For ODM integration` - * Click Add - - * Take note of the **Value**. It will be referenced as `CLIENT_SECRET` in the next steps. - - >Important: This client secret can not be revealed later. If you forgot to take note of it, you'll have to create another one. - -4. Add Claims. - - In **Azure Active Directory** / **App registrations**, select **ODM Application**, and in **Manage / Token Configuration**: - - * Add Optional Email ID Claim - * Click +Add optional claim - * Select ID - * Check Email - * Click Add - - * Add Optional Email Access Claim - * Click +Add optional claim - * Select Access - * Check Email - * Click Add - - * Turn on Microsoft Graph email permission - * Check Turn on the Microsoft Graph email permission - * Click Add - - * Add Group Claim - * Click +Add groups claim - * Check Security Groups - * Click Add - -5. Create a custom claim named "identity" - - To allow ODM rest-api to use the password flow with email as user identifier and the client-credentials flow with client_id as user identifier, we need to create a new claim named "identity" that will take the relevant value according to the flow: - - In **Azure Active Directory** / **Enterprise applications**, select **ODM Application**, and in **Manage / Single sign-on**: - - * Click on Edit of the "Attributes & Claims" section - * Click + Add new claim - * Name: identity - * Fill 2 Claim conditions in the exact following order: - 1. User Type: Any / Scope Groups: 0 / Source: Attribute / Value: - 2. User Type: Members / Scope Groups: 0 / Source: Attribute / Value: user.mail - -6. API Permissions. - - In **Azure Active Directory** / **App Registration**, select **ODM Application**, and then click **API Permissions**. - - * Click Grant Admin Consent for Default Directory - -7. Manifest change. - - In **Azure Active Directory** / **App Registration**, select **ODM Application**, and then click **Manifest**. - - As explained in [accessTokenAcceptedVersion attribute explanation](https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-app-manifest#accesstokenacceptedversion-attribute), change the value to 2. - - ODM OpenID Liberty configuration needs version 2.0 for the issuerIdentifier. See the [openIdWebSecurity.xml](templates/openIdWebSecurity.xml) file. - - - It is also necessary to set **acceptMappedClaims** to true to manage claims. Without this setting, you get the exception **AADSTS50146: This application is required to be configured with an application-specific signing key. It is either not configured with one, or the key has expired or is not yet valid.** when requesting a token. - - - Then, click Save. - -8. Check the configuration. - - Download the [azuread-odm-script.zip](azuread-odm-script.zip) file to your machine and unzip it in your working directory. This .zip file contains scripts and templates to verify and set up ODM. - - 8.1 Verify the Client Credential Token - - You can request an access token using the Client-Credentials flow to verify the token format. - This token is used for the deployment between Decision Center and the Decision Server console: - - ```shell - $ ./get-client-credential-token.sh -i -x -n - ``` - - Where: - - - *TENANT_ID* and *CLIENT_ID* have been obtained from 'Retrieve Tenant and Client information' section. - - *CLIENT_SECRET* is listed in your ODM Application, section **General** / **Client Credentials** - - You should get a token and by introspecting its value with [this online tool](https://jwt.ms) or with some [JWT cli](https://github.com/mike-engel/jwt-cli) you should get: - - **Token header** - ```json - { - "typ": "JWT", - "alg": "RS256", - "kid": "-KI3Q9nNR7bRofxmeZoXqbHZGew" - } - ``` - - **Token claims** - ```json - { - "aud": "", - "identity": "", - ... - "iss": "https://login.microsoftonline.com//v2.0", - ... - "ver": "2.0" - } - ``` - - - *ver*: should be 2.0. otherwise you should verify the previous step **Manifest change** - - *aud*: should be your CLIENT_ID - - *iss*: should end with 2.0. otherwise you should verify the previous step **Manifest change** - - 8.2 Verify the Client Password Token. - - To check that it has been correctly taken into account, you can request an ID token using the Client password flow. - - This token is used for the invocation of the ODM components like Decision Center, Decision Servcer console, and the invocation of the Decision Server Runtime REST API. - - ```shell - $ ./get-user-password-token.sh -i -x -n -u -p - ``` - - Where: - - - *TENANT_ID* and *CLIENT_ID* have been obtained from 'Retrieve Tenant and Client information' section. - - *CLIENT_SECRET* is listed in your ODM Application, section **General** / **Client Credentials** - - *USERNAME* and *PASSWORD* have been created from 'Create at least one user that belongs to this new group.' section. - - By introspecting the token value with this online tool [https://jwt.ms](https://jwt.ms), you should get: - - ```json - { - "aud": "", - ... - "iss": "https://login.microsoftonline.com//v2.0", - ... - "email": "", - "identity": "", - "groups": [ - "" - ], - ... - "ver": "2.0" - } - ``` - - Verify: - - *aud*: should be your CLIENT_ID - - *email*: should be present. Otherwise you should verify the creation of your user and fill the Email field. - - *groups*: should contain your GROUP_ID - - *iss*: should end with 2.0. Otherwise you should verify the previous step **Manifest change** - - *ver*: should be 2.0. Otherwise you should verify the previous step **Manifest change** - - > If this command failed, try to log in to the [Azure portal](https://portal.azure.com/). You may have to enable 2FA and/or change the password for the first time. - -# Deploy ODM on a container configured with Azure AD (Part 2) - -## Prepare your environment for the ODM installation - -### Create a secret to use the Entitled Registry - -1. To get your entitlement key, log in to [MyIBM Container Software Library](https://myibm.ibm.com/products-services/containerlibrary) with the IBMid and password that are associated with the entitled software. - - In the **Container software library** tile, verify your entitlement on the **View library** page, and then go to **Get entitlement key** to retrieve the key. - -2. Create a pull secret by running a `kubectl create secret` command. - - ```shell - $ kubectl create secret docker-registry icregistry-secret \ - --docker-server=cp.icr.io \ - --docker-username=cp \ - --docker-password="" \ - --docker-email= - ``` - - Where: - - - *API_KEY_GENERATED* is the entitlement key from the previous step. Make sure you enclose the key in double-quotes. - - *USER_EMAIL* is the email address associated with your IBMid. - - > Note: The **cp.icr.io** value for the docker-server parameter is the only registry domain name that contains the images. You must set the *docker-username* to **cp** to use an entitlement key as *docker-password*. - -3. Make a note of the secret name so that you can set it for the **image.pullSecrets** parameter when you run a helm install of your containers. The **image.repository** parameter is later set to *cp.icr.io/cp/cp4a/odm*. - -### Create secrets to configure ODM with Azure AD - -1. Create a secret with the Azure AD Server certificate. - - To allow ODM services to access the Azure AD Server, it is mandatory to provide the Azure AD Server certificate. - You can create the secret as follows: - - ```shell - keytool -printcert -sslserver login.microsoftonline.com -rfc > microsoft.crt - kubectl create secret generic ms-secret --from-file=tls.crt=microsoft.crt - ``` - - Introspecting the Azure AD login.microsoftonline.com certificate, you can see it has been signed by the Digicert Root CA authorithy. - - So we will also add the DigiCert Global Root CA from [this page](https://www.digicert.com/kb/digicert-root-certificates.htm): - - ```shell - curl --silent --remote-name https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem - kubectl create secret generic digicert-secret --from-file=tls.crt=DigiCertGlobalRootCA.crt.pem - ``` - -2. Generate the ODM configuration file for Azure AD. - - If you have not yet done so, download the [azuread-odm-script.zip](azuread-odm-script.zip) file to your machine. This archive contains the [script](generateTemplate.sh) and the content of the [templates](templates) directory. - - The [script](generateTemplate.sh) allows you to generate the necessary configuration files. - Generate the files with the following command: - - ```shell - ./generateTemplate.sh -i -x -n -g [-a ] - ``` - - Where: - - *TENANT_ID* and *CLIENT_ID* have been obtained from [previous step](#retrieve-tenant-and-client-information) - - *CLIENT_SECRET* is listed in your ODM Application, section **General** / **Client Credentials** - - *GROUP_ID* is the ODM Admin group created in a [previous step](#manage-group-and-user) (*odm-admin*) - - *SSO_DOMAIN* is the domain name of your SSO. If your AzureAD is connected to another SSO, you should add the SSO domain name in this parameter. If your user has been declared as explained in step **Create at least one user that belongs to this new group**, you can omit this parameter. - - The following four files are generated into the `output` directory: - - - webSecurity.xml contains the mapping between Liberty J2EE ODM roles and Azure AD groups and users: - * All ODM roles are given to the GROUP_ID group - * rtsAdministrators/resAdministrators/resExecutors ODM roles are given to the CLIENT_ID (which is seen as a user) to manage the client-credentials flow - - openIdWebSecurity.xml contains two openIdConnectClient Liberty configurations: - * For web access to the Decision Center an Decision Server consoles using userIdentifier="email" with the Authorization Code flow - * For the rest-api call using userIdentifier="aud" with the client-credentials flow - - openIdParameters.properties configures several features like allowed domains, logout, and some internal ODM OpenId features - - OdmOidcProviders.json configures the client-credentials OpenId provider used by the Decision Center server configuration to connect Decision Center to the Decision Server console and Decision Center to the Decision Runner - -3. Create the Azure AD authentication secret. - - ```shell - kubectl create secret generic azuread-auth-secret \ - --from-file=OdmOidcProviders.json=./output/OdmOidcProviders.json \ - --from-file=openIdParameters.properties=./output/openIdParameters.properties \ - --from-file=openIdWebSecurity.xml=./output/openIdWebSecurity.xml \ - --from-file=webSecurity.xml=./output/webSecurity.xml - ``` - -## Install your ODM Helm release - -### Add the public IBM Helm charts repository - - ```shell - helm repo add ibm-helm https://raw.githubusercontent.com/IBM/charts/master/repo/ibm-helm - helm repo update - ``` - -### Check that you can access the ODM chart - - ```shell - helm search repo ibm-odm-prod - NAME CHART VERSION APP VERSION DESCRIPTION - ibm-helm/ibm-odm-prod 23.1.0 8.12.0.0 IBM Operational Decision Manager - ``` - -### Run the `helm install` command - -You can now install the product. We will use the PostgreSQL internal database and disable the data persistence (`internalDatabase.persistence.enabled=false`) to avoid any platform complexity concerning persistent volume allocation. - -#### a. Installation on OpenShift using Routes - - See the [Preparing to install](https://www.ibm.com/docs/en/odm/8.12.0?topic=production-preparing-install-operational-decision-manager) documentation for additional information. - - ```shell - helm install my-odm-release ibm-helm/ibm-odm-prod \ - --set image.repository=cp.icr.io/cp/cp4a/odm --set image.pullSecrets=icregistry-secret \ - --set oidc.enabled=true \ - --set license=true \ - --set internalDatabase.persistence.enabled=false \ - --set customization.trustedCertificateList='{ms-secret,digicert-secret}' \ - --set customization.authSecretRef=azuread-auth-secret \ - --set internalDatabase.runAsUser='' --set customization.runAsUser='' --set service.enableRoute=true - ``` - -#### b. Installation using Ingress - - Refer to the following documentation to install an NGINX Ingress Controller on: - - [Microsoft Azure Kubernetes Service](../../platform/azure/README.md#create-a-nginx-ingress-controller) - - [Amazon Elastic Kubernetes Service](../../platform/eks/README-NGINX.md) - - [Google Kubernetes Engine](../../platform/gcloud/README_NGINX.md) - - When the NGINX Ingress Controller is ready, you can install the ODM release with: - - ``` - helm install my-odm-release ibm-helm/ibm-odm-prod \ - --set image.repository=cp.icr.io/cp/cp4a/odm --set image.pullSecrets=icregistry-secret \ - --set oidc.enabled=true \ - --set license=true \ - --set internalDatabase.persistence.enabled=false \ - --set customization.trustedCertificateList='{ms-secret,digicert-secret}' \ - --set customization.authSecretRef=azuread-auth-secret \ - --set service.ingress.enabled=true \ - --set service.ingress.annotations={"kubernetes.io/ingress.class: nginx"\,"nginx.ingress.kubernetes.io/backend-protocol: HTTPS"} - ``` - -> **Note** -> By default, NGINX does not enable sticky session. If you want to use sticky session to connect to DC, refer to [Using sticky session for Decision Center connection](../../contrib/sticky-session/README.md) - -## Complete post-deployment tasks - -### Register the ODM redirect URLs - -1. Get the ODM endpoints. - - Refer to the [documentation](https://www.ibm.com/docs/en/odm/8.12.0?topic=tasks-configuring-external-access) to retrieve the endpoints. - For example, on OpenShift you can get the route names and hosts with: - - ```shell - kubectl get routes --no-headers --output custom-columns=":metadata.name,:spec.host" - ``` - - You get the following hosts: - - ``` - my-odm-release-odm-dc-route - my-odm-release-odm-dr-route - my-odm-release-odm-ds-console-route - my-odm-release-odm-ds-runtime-route - ``` - - Using an Ingress, the endpoint is the address of the ODM ingress and is the same for all components. You can get it with: - - ```shell - kubectl get ingress my-odm-release-odm-ingress - ``` - - You get the following ingress address: - - ``` - NAME CLASS HOSTS ADDRESS PORTS AGE - my-odm-release-odm-ingress * 80 14d - ``` - -3. Register the redirect URIs into your Azure AD application. - - The redirect URIs are built the following way: - - Using Routes: - - Decision Center redirect URI: `https:///decisioncenter/openid/redirect/odm` - - Decision Runner redirect URI: `https:///DecisionRunner/openid/redirect/odm` - - Decision Server Console redirect URI: `https:///res/openid/redirect/odm` - - Decision Server Runtime redirect URI: `https:///DecisionService/openid/redirect/odm` - - Rule Designer redirect URI: `https://127.0.0.1:9081/oidcCallback` - - Using Ingress: - - Decision Center redirect URI: `https:///decisioncenter/openid/redirect/odm` - - Decision Runner redirect URI: `https:///DecisionRunner/openid/redirect/odm` - - Decision Server Console redirect URI: `https:///res/openid/redirect/odm` - - Decision Server Runtime redirect URI: `https:///DecisionService/openid/redirect/odm` - - Rule Designer redirect URI: `https://127.0.0.1:9081/oidcCallback` - - From the Azure console, in **Azure Active Directory** / **App Registrations** / **ODM Application**: - - - Click`Add Redirect URIs link` - - Click `Add Platform` - - Select `Web` - - `Redirect URIs` Add the Decision Center redirect URI that you got earlier (`https:///decisioncenter/openid/redirect/odm` -- don't forget to replace with your actual host name!) - - Check Access Token and ID Token - - Click Configure - - Click Add URI Link - - Repeat the previous steps for all other redirect URIs. - - - Click **Save** at the bottom of the page. - ![Add URI](images/AddURI.png) - -### Access the ODM services - -Well done! You can now connect to ODM using the endpoints you got [earlier](#register-the-odm-redirect-url) and log in as an ODM admin with the account you created in [the first step](#manage-group-and-user). - ->Note: Logout in ODM components using Azure AD authentication raises an error for the time being. This is a known issue. We recommend to use a private window in your browser to log in, so that logout is done just by closing this window. - -### Set up Rule Designer - -To be able to securely connect your Rule Designer to the Decision Server and Decision Center services that are running in Certified Kubernetes, you need to establish a TLS connection through a security certificate in addition to the OpenID configuration. - -1. Get the following configuration files: - - * `https:///decisioncenter/assets/truststore.jks` - * `https:///decisioncenter/assets/OdmOidcProvidersRD.json` - Where *DC_HOST* is the Decision Center endpoint. - -2. Copy the `truststore.jks` and `OdmOidcProvidersRD.json` files to your Rule Designer installation directory next to the `eclipse.ini` file. - -3. Edit your `eclipse.ini` file and add the following lines at the end: - - ``` - -Dcom.ibm.rules.studio.oidc.synchro.scopes=/.default - -Dcom.ibm.rules.studio.oidc.res.scopes=/.default - -Djavax.net.ssl.trustStore=/truststore.jks - -Djavax.net.ssl.trustStorePassword=changeme - -Dcom.ibm.rules.authentication.oidcconfig=/OdmOidcProvidersRD.json - ``` - - Where: - - *changeme* is the fixed password to be used for the default truststore.jks file. - - *ECLIPSEINITDIR* is the Rule Designer installation directory next to the eclipse.ini file. - -4. Restart Rule Designer. - -For more information, refer to the [documentation](https://www.ibm.com/docs/en/odm/8.12.0?topic=designer-importing-security-certificate-in-rule). - -### Getting Started with IBM Operational Decision Manager for Containers - -Get hands-on experience with IBM Operational Decision Manager in a container environment by following this [Getting started tutorial](https://github.com/DecisionsDev/odm-for-container-getting-started/blob/master/README.md). - -### Calling the ODM Runtime Service - -To manage ODM runtime call on the next steps, we used the [Loan Validation Decision Service project](https://github.com/DecisionsDev/odm-for-container-getting-started/blob/master/Loan%20Validation%20Service.zip) - -Import the **Loan Validation Service** in Decision Center connected using *myodmuser*@YOURDOMAIN created at step 2 - -![Import project](../Keycloak/images/import_project.png) - -Deploy the **Loan Validation Service** production_deployment ruleapps using the **production deployment** deployment configuration in the Deployments>Configurations tab. - -![Deploy project](../Keycloak/images/deploy_project.png) - -You can retrieve the payload.json from the ODM Decision Server Console or use [the provided payload](payload.json). - -As explained in the ODM on Certified Kubernetes documentation [Configuring user access with OpenID](https://www.ibm.com/docs/en/odm/8.12.0?topic=access-configuring-user-openid), we advise to use basic authentication for the ODM runtime call for performance reasons and to avoid the issue of token expiration and revocation. +## Choose the way to set up your application -You can realize a basic authentication ODM runtime call the following way: +Client credentials are used in the context of authentication in systems that utilize OAuth 2.0, a common protocol for secure authorization. These credentials are typically used by a client application (like a web or mobile app) to prove its identity to an authorization server in order to obtain access tokens for making API requests. There are two ways to use client credentials in Microfoft Entra ID: with a private key (often referred to as client certificates) and with a secret (usually referred to as a client secret). - ```shell -$ curl -H "Content-Type: application/json" -k --data @payload.json \ - -H "Authorization: Basic b2RtQWRtaW46b2RtQWRtaW4=" \ - https:///DecisionService/rest/production_deployment/1.0/loan_validation_production/1.0 -``` +[Client Credentials with a Secret](README_WITH_CLIENT_SECRET.md) (Client Secret): -Where b2RtQWRtaW46b2RtQWRtaW4= is the base64 encoding of the current username:password odmAdmin:odmAdmin + * In this method, the client application is issued a client ID and a client secret during the registration process with the authorization server. + * The client includes its client ID and client secret in its requests to the authorization server to authenticate itself. + * The authorization server verifies the client's identity by checking if the provided client ID and client secret match the values it has on record for that client. + * This method is less secure compared to client certificates because the secret can potentially be intercepted if not properly protected, although it's still widely used and can be secure when managed correctly. + * It's often used in simpler or less security-sensitive applications. -But if you want to execute a bearer authentication ODM runtime call using the Client Credentials flow, you have to get a bearer access token: +[Client Credentials with a Private Key](README_WITH_PRIVATE_KEY_JWT.md) (Client Certificates): -```shell -$ curl -k -X POST -H "Content-Type: application/x-www-form-urlencoded" \ - -d 'client_id=&scope=%2F.default&client_secret=&grant_type=client_credentials' \ - 'https://login.microsoftonline.com//oauth2/v2.0/token' -``` + * In this method, the client application is issued a public-private key pair, similar to how SSL/TLS certificates work. + * The client application signs its requests to the authorization server with its private key and provides the public key as part of the client registration process. + * The public key is used by the authorization server to verify the signature of the client's request. + * This method is considered highly secure because it relies on strong cryptography and doesn't involve sharing a shared secret. + It's often used in more security-critical scenarios. -And use the retrieved access token in the following way: - ```shell -$ curl -H "Content-Type: application/json" -k --data @payload.json \ - -H "Authorization: Bearer " \ - https:///DecisionService/rest/production_deployment/1.0/loan_validation_production/1.0 -``` +In summary, the main difference between client credentials with a private key and a client secret is the method of authentication and the level of security. Client certificates use a public-private key pair for authentication and are generally considered more secure, while client secrets use a shared secret and are less secure but simpler to configure. The choice between them depends on the security requirements and the specific use case of the client application. -# Troubleshooting +If you are unsure about which option to choose, take the time to read [this article explaining the comparison](https://www.ubisecure.com/access-management/private_key_jwt-or-client_secret) . -If you encounter any issue, have a look at the [common troubleshooting explanation](../README.md#Troubleshooting) # License [Apache 2.0](/LICENSE) + diff --git a/authentication/AzureAD/README_WITH_CLIENT_SECRET.md b/authentication/AzureAD/README_WITH_CLIENT_SECRET.md new file mode 100644 index 00000000..de3a6611 --- /dev/null +++ b/authentication/AzureAD/README_WITH_CLIENT_SECRET.md @@ -0,0 +1,506 @@ +# Set up a Microsoft Entra ID application using a client secret + + + +- [Set up a Microsoft Entra ID application using a client secret](#set-up-an-microsoft-entra-id-application-using-a-client-secret) +- [Deploy ODM on a container configured with Microsoft Entra ID Part 2](#deploy-odm-on-a-container-configured-with-microsoft-entra-id-part-2) + - [Prepare your environment for the ODM installation](#prepare-your-environment-for-the-odm-installation) + - [Create a secret to use the Entitled Registry](#create-a-secret-to-use-the-entitled-registry) + - [Create secrets to configure ODM with Microsoft Entra ID](#create-secrets-to-configure-odm-with-microsoft-entra-id) + - [Install your ODM Helm release](#install-your-odm-helm-release) + - [Add the public IBM Helm charts repository](#add-the-public-ibm-helm-charts-repository) + - [Check that you can access the ODM chart](#check-that-you-can-access-the-odm-chart) + - [Run the helm install command](#run-the-helm-install-command) + - [a. Installation on OpenShift using Routes](#a-installation-on-openshift-using-routes) + - [b. Installation using Ingress](#b-installation-using-ingress) + - [Complete post-deployment tasks](#complete-post-deployment-tasks) + - [Register the ODM redirect URLs](#register-the-odm-redirect-urls) + - [Access the ODM services](#access-the-odm-services) + - [Set up Rule Designer](#set-up-rule-designer) + - [Getting Started with IBM Operational Decision Manager for Containers](#getting-started-with-ibm-operational-decision-manager-for-containers) + - [Calling the ODM Runtime Service](#calling-the-odm-runtime-service) +- [Troubleshooting](#troubleshooting) +- [License](#license) + + + +1. Create the *ODM application*. + + In **Azure Active Directory** / **App registration**, click **New Registration**: + + * Name: **ODM Application** + * Supported account types / Who can use this application or access this API?: select `Accounts in this organizational directory only (Default Directory only - Single tenant)` + * Click **Register** + + ![New Web Application](/images/AzureAD/RegisterApp.png) + +2. Retrieve Tenant and Client information. + + In **Azure Active Directory** / **App Registration**, select **ODM Application** and click **Overview**: + + * Application (client) ID: **Client ID**. It will be referenced as `CLIENT_ID` in the next steps. + * Directory (tenant) ID: **Your Tenant ID**. It will be referenced as `TENANT_ID` in the next steps. + + ![Tenant ID](/images/AzureAD/GetTenantID.png) + +3. Generate an OpenID client secret. + + In **Azure Active Directory** / **App registrations**, select **ODM Application**: + + * From the Overview page, click on the link Client credentials: **Add a certificate or secret** or on the **Manage / Certificates & secrets** tab + * Click + New Client Secret + * Description: `For ODM integration` + * Click Add + + * Take note of the **Value**. It will be referenced as `CLIENT_SECRET` in the next steps. + + >Important: This client secret can not be revealed later. If you forgot to take note of it, you'll have to create another one. + +4. Add Claims. + + In **Azure Active Directory** / **App registrations**, select **ODM Application**, and in **Manage / Token Configuration**: + + * Add Optional Email ID Claim + * Click +Add optional claim + * Select ID + * Check Email + * Click Add + + * Add Optional Email Access Claim + * Click +Add optional claim + * Select Access + * Check Email + * Click Add + + * Turn on Microsoft Graph email permission + * Check Turn on the Microsoft Graph email permission + * Click Add + + * Add Group Claim + * Click +Add groups claim + * Check Security Groups + * Click Add + +5. Create a custom claim named "identity" + + To allow ODM rest-api to use the password flow with email as user identifier and the client-credentials flow with client_id as user identifier, we need to create a new claim named "identity" that will take the relevant value according to the flow: + + In **Azure Active Directory** / **Enterprise applications**, select **ODM Application**, and in **Manage / Single sign-on**: + + * Click on Edit of the "Attributes & Claims" section + * Click + Add new claim + * Name: identity + * Fill 2 Claim conditions in the exact following order: + 1. User Type: Any / Scope Groups: 0 / Source: Attribute / Value: + 2. User Type: Members / Scope Groups: 0 / Source: Attribute / Value: user.mail + +6. API Permissions. + + In **Azure Active Directory** / **App Registration**, select **ODM Application**, and then click **API Permissions**. + + * Click Grant Admin Consent for Default Directory + +7. Manifest change. + + In **Azure Active Directory** / **App Registration**, select **ODM Application**, and then click **Manifest**. + + As explained in [accessTokenAcceptedVersion attribute explanation](https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-app-manifest#accesstokenacceptedversion-attribute), change the value to 2. + + ODM OpenID Liberty configuration needs version 2.0 for the issuerIdentifier. See the [openIdWebSecurity.xml](templates/openIdWebSecurity.xml) file. + + It is also necessary to set **acceptMappedClaims** to true to manage claims. Without this setting, you get the exception **AADSTS50146: This application is required to be configured with an application-specific signing key. It is either not configured with one, or the key has expired or is not yet valid.** when requesting a token. + + Then, click Save. + +8. Check the configuration. + + Download the [azuread-odm-script.zip](azuread-odm-script.zip) file to your machine and unzip it in your working directory. This .zip file contains scripts and templates to verify and set up ODM. + + 8.1 Verify the Client Credential Token + + You can request an access token using the Client-Credentials flow to verify the token format. + This token is used for the deployment between Decision Center and the Decision Server console: + + ```shell + $ ./get-client-credential-token.sh -i -x -n + ``` + + Where: + + - *TENANT_ID* and *CLIENT_ID* have been obtained from 'Retrieve Tenant and Client information' section. + - *CLIENT_SECRET* is listed in your ODM Application, section **General** / **Client Credentials** + + You should get a token and by introspecting its value with [this online tool](https://jwt.ms) or with some [JWT cli](https://github.com/mike-engel/jwt-cli) you should get: + + **Token header** + ```json + { + "typ": "JWT", + "alg": "RS256", + "kid": "-KI3Q9nNR7bRofxmeZoXqbHZGew" + } + ``` + + **Token claims** + ```json + { + "aud": "", + "identity": "", + ... + "iss": "https://login.microsoftonline.com//v2.0", + ... + "ver": "2.0" + } + ``` + + - *ver*: should be 2.0. otherwise you should verify the previous step **Manifest change** + - *aud*: should be your CLIENT_ID + - *iss*: should end with 2.0. otherwise you should verify the previous step **Manifest change** + + 8.2 Verify the Client Password Token. + + To check that it has been correctly taken into account, you can request an ID token using the Client password flow. + + This token is used for the invocation of the ODM components like Decision Center, Decision Servcer console, and the invocation of the Decision Server Runtime REST API. + + ```shell + $ ./get-user-password-token.sh -i -x -n -u -p + ``` + + Where: + + - *TENANT_ID* and *CLIENT_ID* have been obtained from 'Retrieve Tenant and Client information' section. + - *CLIENT_SECRET* is listed in your ODM Application, section **General** / **Client Credentials** + - *USERNAME* and *PASSWORD* have been created from 'Create at least one user that belongs to this new group.' section. + + By introspecting the token value with this online tool [https://jwt.ms](https://jwt.ms), you should get: + + ```json + { + "aud": "", + ... + "iss": "https://login.microsoftonline.com//v2.0", + ... + "email": "", + "identity": "", + "groups": [ + "" + ], + ... + "ver": "2.0" + } + ``` + + Verify: + - *aud*: should be your CLIENT_ID + - *email*: should be present. Otherwise you should verify the creation of your user and fill the Email field. + - *groups*: should contain your GROUP_ID + - *iss*: should end with 2.0. Otherwise you should verify the previous step **Manifest change** + - *ver*: should be 2.0. Otherwise you should verify the previous step **Manifest change** + + > If this command failed, try to log in to the [Azure portal](https://portal.azure.com/). You may have to enable 2FA and/or change the password for the first time. + +# Deploy ODM on a container configured with Microsoft Entra ID (Part 2) + +## Prepare your environment for the ODM installation + +### Create a secret to use the Entitled Registry + +1. To get your entitlement key, log in to [MyIBM Container Software Library](https://myibm.ibm.com/products-services/containerlibrary) with the IBMid and password that are associated with the entitled software. + + In the **Container software library** tile, verify your entitlement on the **View library** page, and then go to **Get entitlement key** to retrieve the key. + +2. Create a pull secret by running a `kubectl create secret` command. + + ```shell + $ kubectl create secret docker-registry icregistry-secret \ + --docker-server=cp.icr.io \ + --docker-username=cp \ + --docker-password="" \ + --docker-email= + ``` + + Where: + + - *API_KEY_GENERATED* is the entitlement key from the previous step. Make sure you enclose the key in double-quotes. + - *USER_EMAIL* is the email address associated with your IBMid. + + > Note: The **cp.icr.io** value for the docker-server parameter is the only registry domain name that contains the images. You must set the *docker-username* to **cp** to use an entitlement key as *docker-password*. + +3. Make a note of the secret name so that you can set it for the **image.pullSecrets** parameter when you run a helm install of your containers. The **image.repository** parameter is later set to *cp.icr.io/cp/cp4a/odm*. + +### Create secrets to configure ODM with Microsoft Entra ID + +1. Create a secret with the Microsoft Entra ID Server certificate. + + To allow ODM services to access the Microsoft Entra ID Server, it is mandatory to provide the Microsoft Entra ID Server certificate. + You can create the secret as follows: + + ```shell + keytool -printcert -sslserver login.microsoftonline.com -rfc > microsoft.crt + kubectl create secret generic ms-secret --from-file=tls.crt=microsoft.crt + ``` + + Introspecting the Microsoft Entra ID login.microsoftonline.com certificate, you can see it has been signed by the Digicert Root CA authorithy. + + So we will also add the DigiCert Global Root CA from [this page](https://www.digicert.com/kb/digicert-root-certificates.htm): + + ```shell + curl --silent --remote-name https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem + kubectl create secret generic digicert-secret --from-file=tls.crt=DigiCertGlobalRootCA.crt.pem + ``` + +2. Generate the ODM configuration file for Microsoft Entra ID. + + If you have not yet done so, download the [azuread-odm-script.zip](azuread-odm-script.zip) file to your machine. This archive contains the [script](generateTemplate.sh) and the content of the [templates](templates) directory. + + The [script](generateTemplate.sh) allows you to generate the necessary configuration files. + Generate the files with the following command: + + ```shell + ./generateTemplate.sh -i -x -n -g [-a ] + ``` + + Where: + - *TENANT_ID* and *CLIENT_ID* have been obtained from [previous step](#retrieve-tenant-and-client-information) + - *CLIENT_SECRET* is listed in your ODM Application, section **General** / **Client Credentials** + - *GROUP_ID* is the ODM Admin group created in a [previous step](#manage-group-and-user) (*odm-admin*) + - *SSO_DOMAIN* is the domain name of your SSO. If your AzureAD is connected to another SSO, you should add the SSO domain name in this parameter. If your user has been declared as explained in step **Create at least one user that belongs to this new group**, you can omit this parameter. + + The following four files are generated into the `output` directory: + + - webSecurity.xml contains the mapping between Liberty J2EE ODM roles and Microsoft Entra ID groups and users: + * All ODM roles are given to the GROUP_ID group + * rtsAdministrators/resAdministrators/resExecutors ODM roles are given to the CLIENT_ID (which is seen as a user) to manage the client-credentials flow + - openIdWebSecurity.xml contains two openIdConnectClient Liberty configurations: + * For web access to the Decision Center an Decision Server consoles using userIdentifier="email" with the Authorization Code flow + * For the rest-api call using userIdentifier="aud" with the client-credentials flow + - openIdParameters.properties configures several features like allowed domains, logout, and some internal ODM OpenId features + - OdmOidcProviders.json configures the client-credentials OpenId provider used by the Decision Center server configuration to connect Decision Center to the Decision Server console and Decision Center to the Decision Runner + +3. Create the Microsoft Entra ID authentication secret. + + ```shell + kubectl create secret generic azuread-auth-secret \ + --from-file=OdmOidcProviders.json=./output/OdmOidcProviders.json \ + --from-file=openIdParameters.properties=./output/openIdParameters.properties \ + --from-file=openIdWebSecurity.xml=./output/openIdWebSecurity.xml \ + --from-file=webSecurity.xml=./output/webSecurity.xml + ``` + +## Install your ODM Helm release + +### Add the public IBM Helm charts repository + + ```shell + helm repo add ibm-helm https://raw.githubusercontent.com/IBM/charts/master/repo/ibm-helm + helm repo update + ``` + +### Check that you can access the ODM chart + + ```shell + helm search repo ibm-odm-prod + NAME CHART VERSION APP VERSION DESCRIPTION + ibm-helm/ibm-odm-prod 23.1.0 8.12.0.0 IBM Operational Decision Manager + ``` + +### Run the `helm install` command + +You can now install the product. We will use the PostgreSQL internal database and disable the data persistence (`internalDatabase.persistence.enabled=false`) to avoid any platform complexity concerning persistent volume allocation. + +#### a. Installation on OpenShift using Routes + + See the [Preparing to install](https://www.ibm.com/docs/en/odm/8.12.0?topic=production-preparing-install-operational-decision-manager) documentation for additional information. + + ```shell + helm install my-odm-release ibm-helm/ibm-odm-prod \ + --set image.repository=cp.icr.io/cp/cp4a/odm --set image.pullSecrets=icregistry-secret \ + --set oidc.enabled=true \ + --set license=true \ + --set internalDatabase.persistence.enabled=false \ + --set customization.trustedCertificateList='{ms-secret,digicert-secret}' \ + --set customization.authSecretRef=azuread-auth-secret \ + --set internalDatabase.runAsUser='' --set customization.runAsUser='' --set service.enableRoute=true + ``` + +#### b. Installation using Ingress + + Refer to the following documentation to install an NGINX Ingress Controller on: + - [Microsoft Azure Kubernetes Service](../../platform/azure/README.md#create-a-nginx-ingress-controller) + - [Amazon Elastic Kubernetes Service](../../platform/eks/README-NGINX.md) + - [Google Kubernetes Engine](../../platform/gcloud/README_NGINX.md) + + When the NGINX Ingress Controller is ready, you can install the ODM release with: + + ``` + helm install my-odm-release ibm-helm/ibm-odm-prod \ + --set image.repository=cp.icr.io/cp/cp4a/odm --set image.pullSecrets=icregistry-secret \ + --set oidc.enabled=true \ + --set license=true \ + --set internalDatabase.persistence.enabled=false \ + --set customization.trustedCertificateList='{ms-secret,digicert-secret}' \ + --set customization.authSecretRef=azuread-auth-secret \ + --set service.ingress.enabled=true \ + --set service.ingress.annotations={"kubernetes.io/ingress.class: nginx"\,"nginx.ingress.kubernetes.io/backend-protocol: HTTPS"} + ``` + +> **Note** +> By default, NGINX does not enable sticky session. If you want to use sticky session to connect to DC, refer to [Using sticky session for Decision Center connection](../../contrib/sticky-session/README.md) + +## Complete post-deployment tasks + +### Register the ODM redirect URLs + +1. Get the ODM endpoints. + + Refer to the [documentation](https://www.ibm.com/docs/en/odm/8.12.0?topic=tasks-configuring-external-access) to retrieve the endpoints. + For example, on OpenShift you can get the route names and hosts with: + + ```shell + kubectl get routes --no-headers --output custom-columns=":metadata.name,:spec.host" + ``` + + You get the following hosts: + + ``` + my-odm-release-odm-dc-route + my-odm-release-odm-dr-route + my-odm-release-odm-ds-console-route + my-odm-release-odm-ds-runtime-route + ``` + + Using an Ingress, the endpoint is the address of the ODM ingress and is the same for all components. You can get it with: + + ```shell + kubectl get ingress my-odm-release-odm-ingress + ``` + + You get the following ingress address: + + ``` + NAME CLASS HOSTS ADDRESS PORTS AGE + my-odm-release-odm-ingress * 80 14d + ``` + +3. Register the redirect URIs into your Microsoft Entra ID application. + + The redirect URIs are built the following way: + + Using Routes: + - Decision Center redirect URI: `https:///decisioncenter/openid/redirect/odm` + - Decision Runner redirect URI: `https:///DecisionRunner/openid/redirect/odm` + - Decision Server Console redirect URI: `https:///res/openid/redirect/odm` + - Decision Server Runtime redirect URI: `https:///DecisionService/openid/redirect/odm` + - Rule Designer redirect URI: `https://127.0.0.1:9081/oidcCallback` + + Using Ingress: + - Decision Center redirect URI: `https:///decisioncenter/openid/redirect/odm` + - Decision Runner redirect URI: `https:///DecisionRunner/openid/redirect/odm` + - Decision Server Console redirect URI: `https:///res/openid/redirect/odm` + - Decision Server Runtime redirect URI: `https:///DecisionService/openid/redirect/odm` + - Rule Designer redirect URI: `https://127.0.0.1:9081/oidcCallback` + + From the Azure console, in **Azure Active Directory** / **App Registrations** / **ODM Application**: + + - Click`Add Redirect URIs link` + - Click `Add Platform` + - Select `Web` + - `Redirect URIs` Add the Decision Center redirect URI that you got earlier (`https:///decisioncenter/openid/redirect/odm` -- don't forget to replace with your actual host name!) + - Check Access Token and ID Token + - Click Configure + - Click Add URI Link + - Repeat the previous steps for all other redirect URIs. + + - Click **Save** at the bottom of the page. + ![Add URI](/images/AzureAD/AddURI.png) + +### Access the ODM services + +Well done! You can now connect to ODM using the endpoints you got [earlier](#register-the-odm-redirect-url) and log in as an ODM admin with the account you created in [the first step](#manage-group-and-user). + +>Note: Logout in ODM components using Microsoft Entra ID authentication raises an error for the time being. This is a known issue. We recommend to use a private window in your browser to log in, so that logout is done just by closing this window. + +### Set up Rule Designer + +To be able to securely connect your Rule Designer to the Decision Server and Decision Center services that are running in Certified Kubernetes, you need to establish a TLS connection through a security certificate in addition to the OpenID configuration. + +1. Get the following configuration files: + + * `https:///decisioncenter/assets/truststore.jks` + * `https:///decisioncenter/assets/OdmOidcProvidersRD.json` + Where *DC_HOST* is the Decision Center endpoint. + +2. Copy the `truststore.jks` and `OdmOidcProvidersRD.json` files to your Rule Designer installation directory next to the `eclipse.ini` file. + +3. Edit your `eclipse.ini` file and add the following lines at the end: + + ``` + -Dcom.ibm.rules.studio.oidc.synchro.scopes=/.default + -Dcom.ibm.rules.studio.oidc.res.scopes=/.default + -Djavax.net.ssl.trustStore=/truststore.jks + -Djavax.net.ssl.trustStorePassword=changeme + -Dcom.ibm.rules.authentication.oidcconfig=/OdmOidcProvidersRD.json + ``` + + Where: + - *changeme* is the fixed password to be used for the default truststore.jks file. + - *ECLIPSEINITDIR* is the Rule Designer installation directory next to the eclipse.ini file. + +4. Restart Rule Designer. + +For more information, refer to the [documentation](https://www.ibm.com/docs/en/odm/8.12.0?topic=designer-importing-security-certificate-in-rule). + +### Getting Started with IBM Operational Decision Manager for Containers + +Get hands-on experience with IBM Operational Decision Manager in a container environment by following this [Getting started tutorial](https://github.com/DecisionsDev/odm-for-container-getting-started/blob/master/README.md). + +### Calling the ODM Runtime Service + +To manage ODM runtime call on the next steps, we used the [Loan Validation Decision Service project](https://github.com/DecisionsDev/odm-for-container-getting-started/blob/master/Loan%20Validation%20Service.zip) + +Import the **Loan Validation Service** in Decision Center connected using *myodmuser*@YOURDOMAIN created at step 2 + +![Import project](/images/Keycloak/import_project.png) + +Deploy the **Loan Validation Service** production_deployment ruleapps using the **production deployment** deployment configuration in the Deployments>Configurations tab. + +![Deploy project](/images/Keycloak/deploy_project.png) + +You can retrieve the payload.json from the ODM Decision Server Console or use [the provided payload](payload.json). + +As explained in the ODM on Certified Kubernetes documentation [Configuring user access with OpenID](https://www.ibm.com/docs/en/odm/8.12.0?topic=access-configuring-user-openid), we advise to use basic authentication for the ODM runtime call for performance reasons and to avoid the issue of token expiration and revocation. + +You can realize a basic authentication ODM runtime call the following way: + + ```shell +$ curl -H "Content-Type: application/json" -k --data @payload.json \ + -H "Authorization: Basic b2RtQWRtaW46b2RtQWRtaW4=" \ + https:///DecisionService/rest/production_deployment/1.0/loan_validation_production/1.0 +``` + +Where b2RtQWRtaW46b2RtQWRtaW4= is the base64 encoding of the current username:password odmAdmin:odmAdmin + +But if you want to execute a bearer authentication ODM runtime call using the Client Credentials flow, you have to get a bearer access token: + +```shell +$ curl -k -X POST -H "Content-Type: application/x-www-form-urlencoded" \ + -d 'client_id=&scope=%2F.default&client_secret=&grant_type=client_credentials' \ + 'https://login.microsoftonline.com//oauth2/v2.0/token' +``` + +And use the retrieved access token in the following way: + + ```shell +$ curl -H "Content-Type: application/json" -k --data @payload.json \ + -H "Authorization: Bearer " \ + https:///DecisionService/rest/production_deployment/1.0/loan_validation_production/1.0 +``` + +# Troubleshooting + +If you encounter any issue, have a look at the [common troubleshooting explanation](../README.md#Troubleshooting) + +# License + +[Apache 2.0](/LICENSE) diff --git a/authentication/AzureAD/README_WITH_PRIVATE_KEY_JWT.md b/authentication/AzureAD/README_WITH_PRIVATE_KEY_JWT.md new file mode 100644 index 00000000..e00149c7 --- /dev/null +++ b/authentication/AzureAD/README_WITH_PRIVATE_KEY_JWT.md @@ -0,0 +1,468 @@ + +# Introduction +OpenID Client Credentials with a private key is a robust and secure way for client applications to authenticate themselves when interacting with OpenID Connect providers. This method involves the use of a public-private key pair, similar to SSL/TLS certificates, to verify the client's identity. The private key is securely held by the client, while the public key is registered with the authorization server. + +For additional information regarding the implement in Liberty, please refer to this [link](https://openliberty.io/blog/2023/09/19/23.0.0.9.html#jwt). + +# Set up a Microsoft Entra ID application using a private key JWT + + + +- [Set up a Microsoft Entra ID application using a private key JWT](#set-up-a-microsoft-entra-id-application-using-a-private-key-jwt) +- [Deploy ODM on a container configured with Microsoft Entra ID Part 2](#deploy-odm-on-a-container-configured-with-microsoft-entra-id-part-2) + - [Prepare your environment for the ODM installation](#prepare-your-environment-for-the-odm-installation) + - [Create a secret to use the Entitled Registry](#create-a-secret-to-use-the-entitled-registry) + - [Create secrets to configure ODM with Microsoft Entra ID](#create-secrets-to-configure-odm-with-microsoft-entra-id) + - [Install your ODM Helm release](#install-your-odm-helm-release) + - [Add the public IBM Helm charts repository](#add-the-public-ibm-helm-charts-repository) + - [Check that you can access the ODM chart](#check-that-you-can-access-the-odm-chart) + - [Run the helm install command](#run-the-helm-install-command) + - [a. Installation on OpenShift using Routes](#a-installation-on-openshift-using-routes) + - [b. Installation using Ingress](#b-installation-using-ingress) + - [Complete post-deployment tasks](#complete-post-deployment-tasks) + - [Register the ODM redirect URLs](#register-the-odm-redirect-urls) + - [Access the ODM services](#access-the-odm-services) + - [Set up Rule Designer](#set-up-rule-designer) + - [Getting Started with IBM Operational Decision Manager for Containers](#getting-started-with-ibm-operational-decision-manager-for-containers) + - [Calling the ODM Runtime Service](#calling-the-odm-runtime-service) +- [Troubleshooting](#troubleshooting) +- [License](#license) + + + +1. Create the *ODM application*. + + In **Identity** / **Applications** / **App registration**, click **New Registration**: + + * Name: **ODM Application** + * Supported account types / Who can use this application or access this API?: select `Accounts in this organizational directory only (Default Directory only - Single tenant)` + * Click **Register** + + ![New Web Application](/images/AzureAD/RegisterApp.png) + +2. Retrieve Tenant and Client information. + + In **Identity** / **Applications** / **App Registration**, select **ODM Application** and click **Overview**: + + * Application (client) ID: **Client ID**. It will be referenced as `CLIENT_ID` in the next steps. + * Directory (tenant) ID: **Your Tenant ID**. It will be referenced as `TENANT_ID` in the next steps. + + ![Tenant ID](/images/AzureAD/GetTenantID.png) + +3. Register a public certificate. + + To manage private key JWT authentication, you need a private certificate (.key file) and a public certificate (.crt file), which should be registered on the ODM client side (RP) application. On the Microsoft Entra ID (OP) side, you are required to register the public certificate. + + If you don't have a trusted certificate, you can utilize OpenSSL and other cryptography and certificate management libraries to generate a certificate file and a private key, define the domain name, and set the expiration date. The following command will create a self-signed certificate (.crt file) and a private key (.key file) that will accept the domain name myodmcompany.com. + The expiration is set to 1000 days: + + ```shell + $ openssl req -x509 -nodes -days 1000 -newkey rsa:2048 -keyout myodmcompany.key \ + -out myodmcompany.crt -subj "/CN=myodmcompany.com/OU=it/O=myodmcompany/L=Paris/C=FR" \ + -addext "subjectAltName = DNS:myodmcompany.com" + ``` + + In **Identity** / **Applications** / **App registrations**, select **ODM Application**: + + * From the Overview page, click on the link Client credentials: **Add a certificate or secret** or on the **Manage / Certificates & secrets** tab + * Select the **Certificates** tab + * Click on **Upload certificate** + * Select the myodmcompany.crt or your own public file + * Description: `For ODM integration` + * Click Add + +4. Add Claims. + + In **Identity** / **Applications** / **App registrations**, select **ODM Application**, and in **Manage / Token Configuration**: + + * Add Optional Email ID Claim + * Click +Add optional claim + * Select ID + * Check Email + * Click Add + + * Add Optional Email Access Claim + * Click +Add optional claim + * Select Access + * Check Email + * Click Add + + * Turn on Microsoft Graph email permission + * Check Turn on the Microsoft Graph email permission + * Click Add + + * Add Group Claim + * Click +Add groups claim + * Check Security Groups + * Click Add + +5. Create a custom claim named "identity" + + To enable the ODM REST API to utilize both the password flow with email as the user identifier and the client-credentials flow with client_id as the user identifier, we must establish a new claim named "identity" that will dynamically capture the appropriate value based on the chosen flow: + In **Identity** / **Applications** / **Enterprise applications**, select **ODM Application**, and in **Manage / Single sign-on**: + + * Click on Edit of the "Attributes & Claims" section + * Click + Add new claim + * Name: identity + * Fill 2 Claim conditions in the exact following order: + 1. User Type: Any / Scope Groups: 0 / Source: Attribute / Value: + 2. User Type: Members / Scope Groups: 0 / Source: Attribute / Value: user.mail + +6. API Permissions. + + In **Identity** / **Applications** / **App Registration**, select **ODM Application**, and then click **API Permissions**. + + * Click Grant Admin Consent for Default Directory + +7. Manifest change. + + In **Identity** / **Applications** / **App Registration**, select **ODM Application**, and then click **Manifest**. + + As explained in [accessTokenAcceptedVersion attribute explanation](https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-app-manifest#accesstokenacceptedversion-attribute), change the value to 2. + + ODM OpenID Liberty configuration needs version 2.0 for the issuerIdentifier. See the [openIdWebSecurity.xml](templates/openIdWebSecurity.xml) file. + + It is also necessary to set **acceptMappedClaims** to true to manage claims. Without this setting, you get the exception **AADSTS50146: This application is required to be configured with an application-specific signing key. It is either not configured with one, or the key has expired or is not yet valid.** when requesting a token. + + Then, click Save. + +# Deploy ODM on a container configured with Microsoft Entra ID (Part 2) + +## Prepare your environment for the ODM installation + +### Create a secret to use the Entitled Registry + +1. To get your entitlement key, log in to [MyIBM Container Software Library](https://myibm.ibm.com/products-services/containerlibrary) with the IBMid and password that are associated with the entitled software. + + In the **Container software library** tile, verify your entitlement on the **View library** page, and then go to **Get entitlement key** to retrieve the key. + +2. Create a pull secret by running a `kubectl create secret` command. + + ```shell + $ kubectl create secret docker-registry icregistry-secret \ + --docker-server=cp.icr.io \ + --docker-username=cp \ + --docker-password="" \ + --docker-email= + ``` + + Where: + + - *API_KEY_GENERATED* is the entitlement key from the previous step. Make sure you enclose the key in double-quotes. + - *USER_EMAIL* is the email address associated with your IBMid. + + > Note: The **cp.icr.io** value for the docker-server parameter is the only registry domain name that contains the images. You must set the *docker-username* to **cp** to use an entitlement key as *docker-password*. + +3. Make a note of the secret name so that you can set it for the **image.pullSecrets** parameter when you run a helm install of your containers. The **image.repository** parameter is later set to *cp.icr.io/cp/cp4a/odm*. + +### Create secrets to configure ODM with Microsoft Entra ID + +1. Create a secret with the Microsoft Entra ID Server certificate. + + To allow ODM services to access the Microsoft Entra ID Server, it is mandatory to provide the Microsoft Entra ID Server certificate. + You can create the secret as follows: + + ```shell + keytool -printcert -sslserver login.microsoftonline.com -rfc > microsoft.crt + kubectl create secret generic ms-secret --from-file=tls.crt=microsoft.crt + ``` + + Introspecting the Microsoft Entra ID login.microsoftonline.com certificate, you can see it has been signed by the Digicert Root CA authorithy. + + So we will also add the DigiCert Global Root CA from [this page](https://www.digicert.com/kb/digicert-root-certificates.htm): + + ```shell + curl --silent --remote-name https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem + kubectl create secret generic digicert-secret --from-file=tls.crt=DigiCertGlobalRootCA.crt.pem + ``` + +2. Create a secret to provide the private and public certificate to manage the private_key_jwt authentication + + To allow ODM containers to generate a client_assertion, you have to provide them the private and public certificates with the following **myodmcompany** secret. Don't change this name with this tutorial as this name is linked to the openidConnectClient **keyAliasName="myodmcompany"** parameter of the private_key_jwt liberty configuration. + + ```shell + kubectl create secret generic myodmcompany --from-file=tls.key=myodmcompany.key --from-file=tls.crt=myodmcompany.crt + ``` + +3. Generate the ODM configuration file for Microsoft Entra ID. + + If you have not yet done so, download the [azuread-odm-script.zip](azuread-odm-script.zip) file to your machine. This archive contains the [script](generateTemplateForPrivateKeyJWT.sh) and the content of the [templates_for_privatekeyjwt](templates_for_privatekeyjwt) directory. + + The [script](generateTemplateForPrivateKeyJWT.sh) allows you to generate the necessary configuration files. + Generate the files with the following command: + + ```shell + ./generateTemplateForPrivateKeyJWT.sh -i -n -g [-a ] + ``` + + Where: + - *TENANT_ID* and *CLIENT_ID* have been obtained from [previous step](#retrieve-tenant-and-client-information) + - *GROUP_ID* is the ODM Admin group created in a [previous step](#manage-group-and-user) (*odm-admin*) + - *SSO_DOMAIN* is the domain name of your SSO. If your AzureAD is connected to another SSO, you should add the SSO domain name in this parameter. If your user has been declared as explained in step **Create at least one user that belongs to this new group**, you can omit this parameter. + + The following four files are generated into the `output` directory: + + - webSecurity.xml contains the mapping between Liberty J2EE ODM roles and Microsoft Entra ID groups and users: + * All ODM roles are given to the GROUP_ID group + * rtsAdministrators/resAdministrators/resExecutors ODM roles are given to the CLIENT_ID (which is seen as a user) to manage the client-credentials flow + - openIdWebSecurity.xml contains two openIdConnectClient Liberty configurations: + * For web access to the Decision Center an Decision Server consoles using userIdentifier="email" with the Authorization Code flow + * For the rest-api call using userIdentifier="aud" with the client-credentials flow + - openIdParameters.properties configures several features like allowed domains, logout, and some internal ODM OpenId features + - OdmOidcProviders.json configures the client-credentials OpenId provider used by the Decision Center server configuration to connect Decision Center to the Decision Server console and Decision Center to the Decision Runner + +4. Create the Microsoft Entra ID authentication secret. + + ```shell + kubectl create secret generic azuread-auth-secret \ + --from-file=OdmOidcProviders.json=./outputPKeyJWT/OdmOidcProviders.json \ + --from-file=openIdParameters.properties=./outputPKeyJWT/openIdParameters.properties \ + --from-file=openIdWebSecurity.xml=./outputPKeyJWT/openIdWebSecurity.xml \ + --from-file=webSecurity.xml=./outputPKeyJWT/webSecurity.xml + ``` + +## Install your ODM Helm release + +### Add the public IBM Helm charts repository + + ```shell + helm repo add ibm-helm https://raw.githubusercontent.com/IBM/charts/master/repo/ibm-helm + helm repo update + ``` + +### Check that you can access the ODM chart + + ```shell + helm search repo ibm-odm-prod + NAME CHART VERSION APP VERSION DESCRIPTION + ibm-helm/ibm-odm-prod 23.2.0 8.12.0.1 IBM Operational Decision Manager + ``` + +### Run the `helm install` command + +You can now install the product. We will use the PostgreSQL internal database and disable the data persistence (`internalDatabase.persistence.enabled=false`) to avoid any platform complexity concerning persistent volume allocation. + +#### a. Installation on OpenShift using Routes + + See the [Preparing to install](https://www.ibm.com/docs/en/odm/8.12.0?topic=production-preparing-install-operational-decision-manager) documentation for additional information. + + ```shell + helm install my-odm-release ibm-helm/ibm-odm-prod \ + --set image.repository=cp.icr.io/cp/cp4a/odm --set image.pullSecrets=icregistry-secret \ + --set oidc.enabled=true \ + --set license=true \ + --set internalDatabase.persistence.enabled=false \ + --set customization.trustedCertificateList='{ms-secret,digicert-secret}' \ + --set customization.privateCertificateList='{myodmcompany}' \ + --set customization.authSecretRef=azuread-auth-secret \ + --set internalDatabase.runAsUser='' --set customization.runAsUser='' --set service.enableRoute=true + ``` + +#### b. Installation using Ingress + + Refer to the following documentation to install an NGINX Ingress Controller on: + - [Microsoft Azure Kubernetes Service](../../platform/azure/README.md#create-a-nginx-ingress-controller) + - [Amazon Elastic Kubernetes Service](../../platform/eks/README-NGINX.md) + - [Google Kubernetes Engine](../../platform/gcloud/README_NGINX.md) + + When the NGINX Ingress Controller is ready, you can install the ODM release with: + + ``` + helm install my-odm-release ibm-helm/ibm-odm-prod \ + --set image.repository=cp.icr.io/cp/cp4a/odm --set image.pullSecrets=icregistry-secret \ + --set oidc.enabled=true \ + --set license=true \ + --set internalDatabase.persistence.enabled=false \ + --set customization.trustedCertificateList='{ms-secret,digicert-secret}' \ + --set customization.privateCertificateList='{myodmcompany}' \ + --set customization.authSecretRef=azuread-auth-secret \ + --set service.ingress.enabled=true \ + --set service.ingress.annotations={"kubernetes.io/ingress.class: nginx"\,"nginx.ingress.kubernetes.io/backend-protocol: HTTPS"} + ``` + +> **Note** +> By default, NGINX does not enable sticky session. If you want to use sticky session to connect to DC, refer to [Using sticky session for Decision Center connection](../../contrib/sticky-session/README.md) + +## Complete post-deployment tasks + +### Register the ODM redirect URLs + +1. Get the ODM endpoints. + + Refer to the [documentation](https://www.ibm.com/docs/en/odm/8.12.0?topic=tasks-configuring-external-access) to retrieve the endpoints. + For example, on OpenShift you can get the route names and hosts with: + + ```shell + kubectl get routes --no-headers --output custom-columns=":metadata.name,:spec.host" + ``` + + You get the following hosts: + + ``` + my-odm-release-odm-dc-route + my-odm-release-odm-dr-route + my-odm-release-odm-ds-console-route + my-odm-release-odm-ds-runtime-route + ``` + + Using an Ingress, the endpoint is the address of the ODM ingress and is the same for all components. You can get it with: + + ```shell + kubectl get ingress my-odm-release-odm-ingress + ``` + + You get the following ingress address: + + ``` + NAME CLASS HOSTS ADDRESS PORTS AGE + my-odm-release-odm-ingress * 80 14d + ``` + +3. Register the redirect URIs into your Microsoft Entra ID application. + + The redirect URIs are built the following way: + + Using Routes: + - Decision Center redirect URI: `https:///decisioncenter/openid/redirect/odm` + - Decision Runner redirect URI: `https:///DecisionRunner/openid/redirect/odm` + - Decision Server Console redirect URI: `https:///res/openid/redirect/odm` + - Decision Server Runtime redirect URI: `https:///DecisionService/openid/redirect/odm` + + Using Ingress: + - Decision Center redirect URI: `https:///decisioncenter/openid/redirect/odm` + - Decision Runner redirect URI: `https:///DecisionRunner/openid/redirect/odm` + - Decision Server Console redirect URI: `https:///res/openid/redirect/odm` + - Decision Server Runtime redirect URI: `https:///DecisionService/openid/redirect/odm` + + From the Azure console, in **Identity** / **Applications** / **App Registrations** / **ODM Application**: + + - Click`Add Redirect URIs link` + - Click `Add Platform` + - Select `Web` + - `Redirect URIs` Add the Decision Center redirect URI that you got earlier (`https:///decisioncenter/openid/redirect/odm` -- don't forget to replace with your actual host name!) + - Check Access Token and ID Token + - Click Configure + - Click Add URI Link + - Repeat the previous steps for all other redirect URIs. + + - Click **Save** at the bottom of the page. + ![Add URI](/images/AzureAD/AddURI.png) + +4. Register the Rule Designer callback into your Microsoft Entra ID application. + + The ODM Rule Designer will use the [PKCE authorization code flow](https://oauth.net/2/pkce/) to connect to Decision Center and Decision Server Console. + + From the Azure console, in **Identity** / **Applications** / **App Registrations** / **ODM Application**: + + - Click`Add Redirect URIs link` + - Click `Add Platform` + - Select `Mobile and desktop applications` + - `Custom redirect URIs` Add the Rule Designer callback `https://127.0.0.1:9081/oidcCallback` + + - Click **Configure** at the bottom of the page. + ![Add URI](/images/AzureAD/AddRDCallback.png) + +### Access the ODM services + +Well done! You can now connect to ODM using the endpoints you got [earlier](#register-the-odm-redirect-url) and log in as an ODM admin with the account you created in [the first step](#manage-group-and-user). + +>Note: Logout in ODM components using Microsoft Entra ID authentication raises an error for the time being. This is a known issue. We recommend to use a private window in your browser to log in, so that logout is done just by closing this window. + +### Set up Rule Designer + +To be able to securely connect your Rule Designer to the Decision Server and Decision Center services that are running in Certified Kubernetes, you need to establish a TLS connection through a security certificate in addition to the OpenID configuration. + +1. Get the following configuration files: + + * `https:///decisioncenter/assets/truststore.jks` + * `https:///decisioncenter/assets/OdmOidcProvidersRD.json` + Where *DC_HOST* is the Decision Center endpoint. + +2. Copy the `truststore.jks` and `OdmOidcProvidersRD.json` files to your Rule Designer installation directory next to the `eclipse.ini` file. + +3. Edit your `eclipse.ini` file and add the following lines at the end: + + ``` + -Dcom.ibm.rules.studio.oidc.synchro.scopes=/.default + -Dcom.ibm.rules.studio.oidc.res.scopes=/.default + -Djavax.net.ssl.trustStore=/truststore.jks + -Djavax.net.ssl.trustStorePassword=changeme + -Dcom.ibm.rules.authentication.oidcconfig=/OdmOidcProvidersRD.json + ``` + + Where: + - *changeme* is the fixed password to be used for the default truststore.jks file. + - *ECLIPSEINITDIR* is the Rule Designer installation directory next to the eclipse.ini file. + +4. Restart Rule Designer. + +For more information, refer to the [documentation](https://www.ibm.com/docs/en/odm/8.12.0?topic=designer-importing-security-certificate-in-rule). + +### Getting Started with IBM Operational Decision Manager for Containers + +Get hands-on experience with IBM Operational Decision Manager in a container environment by following this [Getting started tutorial](https://github.com/DecisionsDev/odm-for-container-getting-started/blob/master/README.md). + +### Calling the ODM Runtime Service + +To manage ODM runtime call on the next steps, we used the [Loan Validation Decision Service project](https://github.com/DecisionsDev/odm-for-container-getting-started/blob/master/Loan%20Validation%20Service.zip) + +Import the **Loan Validation Service** in Decision Center connected using *myodmuser*@YOURDOMAIN created at step 2 + +![Import project](/images/Keycloak/import_project.png) + +Deploy the **Loan Validation Service** production_deployment ruleapps using the **production deployment** deployment configuration in the Deployments>Configurations tab. + +![Deploy project](/images/Keycloak/deploy_project.png) + +You can retrieve the payload.json from the ODM Decision Server Console or use [the provided payload](payload.json). + +As explained in the ODM on Certified Kubernetes documentation [Configuring user access with OpenID](https://www.ibm.com/docs/en/odm/8.12.0?topic=access-configuring-user-openid), we advise to use basic authentication for the ODM runtime call for performance reasons and to avoid the issue of token expiration and revocation. + +You can realize a basic authentication ODM runtime call the following way: + + ```shell +$ curl -H "Content-Type: application/json" -k --data @payload.json \ + -H "Authorization: Basic b2RtQWRtaW46b2RtQWRtaW4=" \ + https:///DecisionService/rest/production_deployment/1.0/loan_validation_production/1.0 +``` + +Where b2RtQWRtaW46b2RtQWRtaW4= is the base64 encoding of the current username:password odmAdmin:odmAdmin + +But if you want to execute a bearer authentication ODM runtime call using the Client Credentials flow, you have to get a bearer access token using a client_assertion. + +Before to generate the client_assertion, you need a keystore.jks that will be build using the previously generated myodmcompany.key private key and myodmcompany.crt public key PEM files with the commands: + +```shell +$ openssl pkcs12 -export -out myodmcompany.p12 -inkey myodmcompany.key -in myodmcompany.crt -passout pass:changeme +keytool -importkeystore -srckeystore myodmcompany.p12 -srcstoretype pkcs12 -srcalias 1 -srcstorepass changeme -destkeystore myodmcompany.jks -deststoretype jks -deststorepass changeme -destalias myalias +``` + +Now you can generate the client_assertion following the [ODM documentation](https://www.ibm.com/docs/en/odm/8.12.0?topic=8120-generating-json-web-token-client-assertion). + +```shell +java -cp $DCLIB/jrules-teamserver.jar:$DCLIB/jose4j-0.9.3.jar:$DCLIB/slf4j-api-1.7.25.jar com.ibm.rules.oauth.ClientAssertionHelper -clientId -tokenEndpoint https://login.microsoftonline.com//oauth2/v2.0/token -keyAliasName myalias -keyStorePwd changeme -keyStoreLocation ./myodmcompany.jks +``` + +Now, generate the access token using the client_assertion: + +```shell +$ curl -k -X POST -H "Content-Type: application/x-www-form-urlencoded" \ + -d 'client_id=&scope=%2F.default&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=&grant_type=client_credentials' \ + 'https://login.microsoftonline.com//oauth2/v2.0/token' +``` + +And use the retrieved access token in the following way: + + ```shell +$ curl -H "Content-Type: application/json" -k --data @payload.json \ + -H "Authorization: Bearer " \ + https:///DecisionService/rest/production_deployment/1.0/loan_validation_production/1.0 +``` + +# Troubleshooting + +If you encounter any issue, have a look at the [common troubleshooting explanation](../README.md#Troubleshooting) + +# License + +[Apache 2.0](/LICENSE) diff --git a/authentication/AzureAD/azuread-odm-script.zip b/authentication/AzureAD/azuread-odm-script.zip index 14e45800f9e16a055f25187b05cf961963cc3c86..bd8a47e44b4015dfea30cc37892fc3a6842079a9 100644 GIT binary patch delta 3078 zcma);2T)V#7RM7xfFL1Aq$GeK(gYEB^hhrfLNALTMV5{v^e$%UQUxwmT0oR;5HO&W zr99L{5F4O$1d(E-Xeb(%7u?-h-?-y@bLX4;eKYs|=Y0Qj&TmdTy4~As#j!xBx%;+t5GABFHCRzF4O-uRaH}v+^ zVSV1FNE4GSGtYVfO1aUL>E#=IqDXa8C3^S;NKLu}tP~l#p`s#=Qz}jysMHB==BTY)Qg8F* zq`v3upq9v$@ud~|WSrP94on<0E6}!HS}<q^j{SMVJe{!G;Hi5(x~#w%gWu$H zQz&z*QH@2q)Lwp|<<@)Wq>TI6In#=>(d|)ajp^Mj zhuRCBctY!lrJrE(bnp0wi_gPJ9cU-1``b~!Q>qqRI$lL}Twc0cdCAQ3B7Ux_HT2V! zwYE{77mC6n-IRn4{;65LeUuHsIZW&`gp;#+`}gyh^Ku0d2jT6#CB9#VO!%veH8-;o zi|aGd=Y_?~+H?9~(C8IPT8b@Bl}EYS(DO2HQAUo|#pcaD10?OhCwKJ|;|Vd6OVx?) z8_jQ;lOI(ptA^pd1q3ogt4-dc4>pP8&e2OGJJI>roG^qDS8y*<^~rTYM?akB5*ZaV z0>++=JaR8C3YtgZW-Hgy`z3$t@vF0^qO)|LN+$)EO$6qdJC&Np*-9qA8sU?f$kptt zxU&D0nUtKzN$wwCZW5@DY-PDQH7Z7I-mAVt*3HWzKM+)9*=4dWn>+u|l54TtHo9dR z))>y_Kdd#}qByCk{dP?7lo9#NJkWL0>?Tdul^Y+m5!2d*+lguqU)vSjh9O`1oQnPY zzUy_;$pdgp0hbyBW3m+nc)_j2+SMlNakyIGh-`=oBNGAy0;@X580wB!#B#Cp#JQ4YhJ)@M9`3VrOHN9K4CiOI!W4SrvD@mNGmbeOJNHNSm$-5m=Wp~ux&K7G@&`?+KU8nJn*S_R6SCX4<8iL ztD+L2*org#Sj0)aRNysG_HNQ$Y=gBli1cK504t$?th6S0JqG9bx^gx~s51H!rv>&e zs}$*0m8(clBs%C`1<`M<@;|(qJ1Ro>7xtgMvM^uihT0pd~2&}b~_p^%MV9QuO?SOQ^#EL(exHafRUSl(& zq^D2)l2=7YNGMUF%0vAvkrZ6`k0qv82NU{B9;MDu;a^O ztoue$MoxCUQ@YL3S%I)lO}&*nLAYMB*JG+-LPRuLs_L+3si&aH8#?xW(%oC#o&?#; zLLnoD-#C&*cf=TH!vBVDh6LoFiihLBtB1mkBFz1>BNSUx|6;l$U+nzsy6)eWxhuiV z2DZ)icF-x&JLApac2@p9ey2bG0`=E$6WtR13e!q~$3Fa?v)wz}8HF-3g@T1Gza`um zFylki^AsWknL3xXVtyJ6By%@bTkXaaNw_-lV6GG`z9lG(?7oj$FJ8%w85Ooiwisd9 z^4wmmyxx%V<*IUv4nZXa-Rx{AQZ`OARJF;m4;Yg2>>3+Xtx4`m6~5CA?gVqq;51#= zdKQ~tyMr|vwXFX2C9Z-2w&5kOQ$gO-Hv+`#pbcFX7qV)HN_euZE>uCh&IYKjKdWB7 zX1WH@BnepHW12#STDEwT{+L5W$T^rx4-P@~jYrQDr}`>7CxFCO)(eR3PL(z^yw^C? z;Su9zD~^=tE8mdl?_}v-6_qh8c{(iv@dU*>X~?fYW{+?l(z?7D-#=>xVWEvpSoYNK zhryc_aXquYtBcL;G#DxXGq9Fv+VmIx+B-K0M&6Aqz?eJgHrJ3|gJ|FK(gHQ7tXyOL zSGd)~2YX7zt|Pl*Gac0gBDL#=(acN%q_ii$<$)w=ee6rz&8K_UxAb~%(A@3$W!<3W zxrlIycPR_5bIIpEHmtyr$BT~CX$oW(R2}41sy+H#J~VDBzI`b?!c~>GW&Yg;3%!}F z{{)Y3xUpSy2yHc*K8}TOfk4tfZl*Kg9zR=qxP=D!gha|l;QYRhWz~OzsO1<>I#bIs zXBQaoM!{P8q4LZCD}AHD9L@|>Al=NqpZ)mgJq!ZT>lQ?bf0H2dACn+(fKp>P z4h7T&+!%D&fpP)tSIANXPz+{A0H~li(;;W+UmXXm1(6K)Fu-3>34jYgHNL0q-*HsM zN^sMy_#u1wSm+@f;+HOt()bHVfAi>DH7`2gf21~dROnFc5Kv#$zHjDl)qrC^R-T)M&o+`FPzXps8PW5NWM~ov YPNI|%%ybliKpgbPh@M#;sl(HM0B;jL)&Kwi delta 192 zcmbOqyTf{e0_)~o%AKs6i{-poH=mQ)$hcXTOPh(gxl?v>G><9AQLc9>AiQ}7&qTJ# z&YH=SP4(oM#aJ08pH-Hf+@h&8`J%2I({irKA9Xz@H|t6#D|U)OB1u$C0lbiv8` zTFJ~ig%~EsacfN8tEHp>G&bDKe+I)QMg|5xHU-~d8qW(J1&QXn1xrFb@> diff --git a/authentication/AzureAD/generateTemplateForPrivateKeyJWT.sh b/authentication/AzureAD/generateTemplateForPrivateKeyJWT.sh new file mode 100755 index 00000000..4b71dd83 --- /dev/null +++ b/authentication/AzureAD/generateTemplateForPrivateKeyJWT.sh @@ -0,0 +1,78 @@ +#!/bin/bash +# +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. +# The ASF licenses this file to You under the Apache License, Version 2.0 +# (the "License"); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# +export AZUREAD_CLAIM_GROUPS="groups" +export AZUREAD_CLAIM_LOGIN="loginName" +OUTPUT_DIR=./outputPKeyJWT +TEMPLATE_DIR=./templates_for_privatekeyjwt + +function usage { + cat <