From 80e24b10ed377733f876f81ccb0d4edf01c967c7 Mon Sep 17 00:00:00 2001 From: Brian Rosenberg Date: Thu, 30 Nov 2023 13:31:06 -0500 Subject: [PATCH 1/4] Initial info for oidc callbacks --- docs/docs/OpenID-Connect-Guide.md | 23 ++++++++++ docs/site/OpenID-Connect-Guide/index.html | 23 ++++++++++ docs/site/index.html | 2 +- docs/site/search/search_index.json | 9 +++- docs/site/sitemap.xml | 54 +++++++++++------------ 5 files changed, 81 insertions(+), 30 deletions(-) diff --git a/docs/docs/OpenID-Connect-Guide.md b/docs/docs/OpenID-Connect-Guide.md index 8673a0fa181c..7aed18db9080 100644 --- a/docs/docs/OpenID-Connect-Guide.md +++ b/docs/docs/OpenID-Connect-Guide.md @@ -124,6 +124,7 @@ docker run -p 9090:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin - Capability config: - "Client authentication" must be enabled. - "Standard flow" must be enabled. + - "Service accounts roles" must be enabled. - Login settings: - Set "Valid redirect URIs" to `http://localhost:8080/workflow-manager/login/oauth2/code/provider` @@ -189,3 +190,25 @@ included as a bearer token in REST requests to Workflow Manager. For example: ```bash curl -H "Authorization: Bearer " http://localhost:8080/workflow-manager/rest/actions ``` + + +### Use OAuth when sending job complete callbacks and when posting to TiesDb. +1\. Create a client for the callback receiver or TiesDb: + +- Use the "Clients" menu to create a new client. +- Capability config: + - The client needs to have "Client authentication" and "Service accounts roles" enabled. + +2\. Create a client role: + +- Use the "Roles" tab to add a role to the client that was just created. + +3\. Add the role to the Workflow Manager's client: + +- Go to the client details page for the client created for Workflow Manager. +- Go to the "Service accounts roles" tab. +- Click "Assign role". +- Change "Filter by realm roles" to "Filter by clients". +- Assign the role created in step 2. + +4\. Run jobs with the `CALLBACK_USE_OIDC` or `TIES_DB_USE_OIDC` job properties set. diff --git a/docs/site/OpenID-Connect-Guide/index.html b/docs/site/OpenID-Connect-Guide/index.html index 18322833b060..dbfde7f547fd 100644 --- a/docs/site/OpenID-Connect-Guide/index.html +++ b/docs/site/OpenID-Connect-Guide/index.html @@ -345,6 +345,7 @@

Example with Keycloak

  • Capability config:
    • "Client authentication" must be enabled.
    • "Standard flow" must be enabled.
      • +
    • "Service accounts roles" must be enabled.
  • Login settings:
      @@ -412,6 +413,28 @@

      Test REST authentication

      included as a bearer token in REST requests to Workflow Manager. For example:

      curl -H "Authorization: Bearer <access-token>" http://localhost:8080/workflow-manager/rest/actions
      +

      Use OAuth when sending job complete callbacks and when posting to TiesDb.

      +

      1. Create a client for the callback receiver or TiesDb:

      +
        +
      • Use the "Clients" menu to create a new client.
        • +
      • Capability config:
          +
        • The client needs to have "Client authentication" and "Service accounts roles" enabled.
          • +
        +
        • +
      +

      2. Create a client role:

      +
        +
      • Use the "Roles" tab to add a role to the client that was just created.
        • +
      +

      3. Add the role to the Workflow Manager's client:

      +
        +
      • Go to the client details page for the client created for Workflow Manager.
        • +
      • Go to the "Service accounts roles" tab.
        • +
      • Click "Assign role".
        • +
      • Change "Filter by realm roles" to "Filter by clients".
        • +
      • Assign the role created in step 2.
        • +
      +

      4. Run jobs with the CALLBACK_USE_OIDC or TIES_DB_USE_OIDC job properties set.

      diff --git a/docs/site/index.html b/docs/site/index.html index a71256d2ad7a..790ae038cd31 100644 --- a/docs/site/index.html +++ b/docs/site/index.html @@ -388,5 +388,5 @@

      Overview

      diff --git a/docs/site/search/search_index.json b/docs/site/search/search_index.json index dae91c3dffd8..3390313a907d 100644 --- a/docs/site/search/search_index.json +++ b/docs/site/search/search_index.json @@ -262,7 +262,7 @@ }, { "location": "/OpenID-Connect-Guide/index.html", - "text": "NOTICE:\n This software (or technical data) was produced for the U.S. Government under contract,\nand is subject to the Rights in Data-General Clause 52.227-14, Alt. IV (DEC 2007). Copyright 2023\nThe MITRE Corporation. All Rights Reserved.\n\n\nOpenID Connect Overview\n\n\nWorkflow Manager can use an OpenID Connect (OIDC) provider to handle authentication for users of\nthe web UI and clients of the REST API.\n\n\nConfiguration\n\n\nIn order to use OIDC, Workflow Manager must first be registered with OIDC provider. The exact\nprocess for this varies by provider. As part of the registration process, a client ID and client\nsecret should be provided. Those values should be set in the \nOIDC_CLIENT_ID\n and\n\nOIDC_CLIENT_SECRET\n environment variables. During the registration process the provider will\nlikely request a redirect URI. The redirect URI should be set to the base URI for Workflow Manager\nwith \n/login/oauth2/code/provider\n appended.\n\n\nThe documentation for the OIDC provider should specify the base URI a client should use to\nauthenticate users. The URI should be set in the \nOIDC_ISSUER_URI\n environment variable. To verify\nthe URI is correct, check that the JSON discovery document is returned when sending an HTTP GET\nrequest to the URI with \n/.well-known/openid-configuration\n appended.\n\n\nAfter a user or REST client authenticates with the OIDC provider, Workflow Manager will check for a\nclaim with a specific value to determine if the user is authorized to access Workflow Manager and\nwith what role. The \nOIDC_USER_CLAIM_NAME\n and \nOIDC_ADMIN_CLAIM_NAME\n environment variables\nspecify the name of the claim that must be present. The \nOIDC_USER_CLAIM_VALUE\n and\n\nOIDC_ADMIN_CLAIM_VALUE\n environment variables specify the required value of the claim.\n\n\nIf Workflow Manager is configured to use OIDC, then the component services must also be configured\nto use OIDC. The component services will use OIDC if either the \nOIDC_JWT_ISSUER_URI\n or\n\nOIDC_ISSUER_URI\n environment variables are set on the component service. When a component service\nis configured to use OIDC, the \nOIDC_CLIENT_ID\n and \nOIDC_CLIENT_SECRET\n environment variables are\nused to specify the client ID and secret that will be used during component registration.\n\n\nWorkflow Manager Environment Variables\n\n\n\n\nOIDC_ISSUER_URI\n (Required): URI for the OIDC provider that will be used to authenticate users\n through the web UI. If \nOIDC_JWT_ISSUER_URI\n is not set, \nOIDC_ISSUER_URI\n will also be used to\n authenticate REST clients. The OIDC configuration endpoint must exist at the value of\n \nOIDC_ISSUER_URI\n with \n/.well-known/openid-configuration\n appended.\n\n\nOIDC_JWT_ISSUER_URI\n (Optional): Works the same way as \nOIDC_ISSUER_URI\n, except that the\n configuration will only be used to authenticate REST clients. When not provided,\n \nOIDC_ISSUER_URI\n will be used. This would be used when the authentication provider's endpoint\n for user authentication is different from the endpoint for authentication of REST clients.\n\n\nOIDC_CLIENT_ID\n (Required): The client ID that Workflow Manager will use to authenticate with\n the OIDC provider.\n\n\nOIDC_CLIENT_SECRET\n (Required): The client secret Workflow Manager will use to authenticate\n with the OIDC provider.\n\n\nOIDC_USER_CLAIM_NAME\n (Optional): Specifies the name of the claim from the authentication token\n that is required for a user or REST client to be granted access to Workflow Manager with the\n \nUSER\n role.\n\n\nOIDC_USER_CLAIM_VALUE\n (Optional): Specifies the required value of the claim specified in\n \nOIDC_USER_CLAIM_NAME\n. If the claim is a list, only one of the values in the list must match.\n\n\nOIDC_ADMIN_CLAIM_NAME\n (Optional): Specifies the name of the claim from the authentication token\n that is required for a user or REST client to be granted access to Workflow Manager with the\n \nADMIN\n role.\n\n\nOIDC_ADMIN_CLAIM_VALUE\n (Optional): Specifies the required value of the claim specified in\n \nOIDC_ADMIN_CLAIM_NAME\n. If the claim is a list, only one of the values in the list must match.\n\n\nOIDC_SCOPES\n (Optional): A comma-separated list of the scopes to be requested from the OIDC\n provider when authenticating a user through the web UI. The OIDC specification requires one of\n the scopes to be \nopenid\n, so if this environment variable is omitted or \nopenid\n is not in the\n list, it will be automatically added.\n\n\nOIDC_USER_NAME_ATTR\n (Optional): The name of the claim containing the user name. Defaults to\n \nsub\n.\n\n\nOIDC_REDIRECT_URI\n (Optional): Specifies the URL the user's browser will be redirected to after\n logging in to the OIDC provider. If provided, the URL must end in \n/login/oauth2/code/provider\n.\n This would generally be used when the host name that Workflow Manager uses to connect to the\n OIDC provider is different from the OIDC provider's public host name. The value can use the\n \ntemplate variables supported by Spring.\n\n\n\n\nComponent Environment Variables\n\n\n\n\nOIDC_JWT_ISSUER_URI\n or \nOIDC_ISSUER_URI\n (Required): URI for the OIDC provider that will be used\n to authenticate REST clients. The OIDC configuration endpoint must exist at the value of this\n environment variable with \n/.well-known/openid-configuration\n appended. If both environment\n variables are provided, \nOIDC_JWT_ISSUER_URI\n will be used. If \nOIDC_JWT_ISSUER_URI\n is set on\n Workflow Manager, it should be set to the same value on the component services. If\n \nOIDC_JWT_ISSUER_URI\n is not set on Workflow Manager, \nOIDC_ISSUER_URI\n should be set to the\n same value on Workflow Manager and the component services. When either environment variable is\n set, the \nWFM_USER\n and \nWFM_PASSWORD\n environment variables are ignored.\n\n\nOIDC_CLIENT_ID\n (Required): The client ID that the component service will use when registering\n the component with Workflow Manager.\n\n\nOIDC_CLIENT_SECRET\n (Required): The client secret that the component service will use when\n registering the component with Workflow Manager.\n\n\n\n\nExample with Keycloak\n\n\nThe following example explains how to test Workflow Manager with Keycloak as the OIDC provider.\nIt is just an example and should not be used in production.\n\n\n1. Get the Docker gateway IP address by running the command below. It will be used in later steps.\n\n\ndocker network inspect --format '{{(index .IPAM.Config 0).Gateway}}' bridge\n\n\n\n2. Start Keycloak in development mode using the command below. Do not start Workflow Manager yet.\n The values for the OIDC environment variables are dependent on how you set up Keycloak in the\n following steps.\n\n\ndocker run -p 9090:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin \\\n quay.io/keycloak/keycloak:21.1.1 start-dev\n\n\n\n3. Go to \nhttp://localhost:9090/admin\n in a browser and login with username \nadmin\n and\n password \nadmin\n.\n\n\n4. Create a new realm:\n\n\n\n\nCreate a new realm using the drop down box in upper left that says \"master\".\n\n\nUse the realm name you entered and the gateway IP address from step 1 to set Workflow\n Manager and the component services' \nOIDC_ISSUER_URI\n environment variable to:\n \nhttp://:9090/realms/\n\n\n\n\n5. Create the client that Workflow Manager will use to authenticate users:\n\n\n\n\nUse the \"Clients\" link in the left menu to create a new client.\n\n\nGeneral Settings:\n\n\nThe \"Client type\" needs to be set to \"OpenID Connect\".\n\n\nEnter a \"Client ID\".\n\n\nSet Workflow Manager's \nOIDC_CLIENT_ID\n environment variable to the client ID you entered.\n\n\n\n\n\n\nCapability config:\n\n\n\"Client authentication\" must be enabled.\n\n\n\"Standard flow\" must be enabled.\n\n\n\n\n\n\nLogin settings:\n\n\nSet \"Valid redirect URIs\" to\n \nhttp://localhost:8080/workflow-manager/login/oauth2/code/provider\n\n\nSet \"Valid post logout redirect URIs\" to \nhttp://localhost:8080/workflow-manager\n\n\n\n\n\n\nSet Workflow Manager's \nOIDC_CLIENT_SECRET\n environment variable to the \"Client secret\" in the\n \"Credentials\" tab.\n\n\n\n\n6. Create a Keycloak role that maps to a Workflow Manager role:\n\n\n\n\nUse the \"Realm roles\" link in the left menu to create a new role.\n\n\nIf the Keycloak role should make the user an \nADMIN\n in Workflow Manager, set Workflow\n Manager's \nOIDC_ADMIN_CLAIM_VALUE\n to the role name you just entered. If it should be a\n \nUSER\n, then set the \nOIDC_USER_CLAIM_VALUE\n environment variable.\n\n\nOnly one of \nOIDC_ADMIN_CLAIM_VALUE\n and \nOIDC_USER_CLAIM_VALUE\n need to be set. If you would\n like to set up both roles repeat this step.\n\n\n\n\n7. Include the Keycloak role(s) in the access token:\n\n\n\n\nIn the \"Client scopes\" menu add a mapper to the \"roles\" scope.\n\n\nUse the \"groups\" predefined mapper.\n\n\nThe default name \"Token Claim Name\" is \"groups\". This can be changed.\n\n\nIf you created an \nADMIN\n role in step 6 set \nOIDC_ADMIN_CLAIM_NAME\n to the value in\n \"Token Claim Name\". If you created a \nUSER\n role, do the same for \nOIDC_USER_CLAIM_NAME\n.\n\n\n\n\n8. Optionally, set Workflow Manager's \nOIDC_USER_NAME_ATTR\n to \npreferred_username\n to display the\n user name instead of the ID.\n\n\n9. Create Users:\n\n\n\n\nAfter creating a user, set a password in the \"Credentials\" tab.\n\n\nUse the \"Role mapping\" tab to add the user to one of roles created in step 6.\n\n\n\n\n10. Add Component Registration REST client:\n\n\n\n\nUse the \"Clients\" menu to create a new client.\n\n\nCapability config:\n\n\nThe client needs to have \"Client authentication\" and \"Service accounts roles\" enabled.\n\n\nUse the \"Service account roles\" tab to add the client to one of the roles created in step 6.\n\n\n\n\n\n\nSet the component services' \nWFM_USER\n environment variable to the client ID you entered.\n\n\nSet component services' \nWFM_PASSWORD\n environment variable to the \"Client secret\" in the\n \"Credentials\" tab.\n\n\n\n\n11. Add external REST clients:\n\n\n\n\nUse the \"Clients\" menu to create a new client.\n\n\nCapability config:\n\n\nThe client needs to have \"Client authentication\" and \"Service accounts roles\" enabled.\n\n\nUse the \"Service account roles\" tab to add the client to one of the roles created in step 6.\n\n\n\n\n\n\n\n\n12. Start Workflow Manager. When you initially navigate to Workflow Manager, you will be\n redirected to the Keycloak log in page. You can log in using the users created in step 9.\n\n\nTest REST authentication\n\n\nUsing the Docker gateway IP address from step 1, the client ID and secret from step 11, and the\nrealm name from step 4, run the following command:\n\n\ncurl -d grant_type=client_credentials -u ':' 'http://:9090/realms//protocol/openid-connect/token'\n\n\n\nThe response JSON will contain a token in the \n\"access_token\"\n property. That token needs to be\nincluded as a bearer token in REST requests to Workflow Manager. For example:\n\n\ncurl -H \"Authorization: Bearer \" http://localhost:8080/workflow-manager/rest/actions", + "text": "NOTICE:\n This software (or technical data) was produced for the U.S. Government under contract,\nand is subject to the Rights in Data-General Clause 52.227-14, Alt. IV (DEC 2007). Copyright 2023\nThe MITRE Corporation. All Rights Reserved.\n\n\nOpenID Connect Overview\n\n\nWorkflow Manager can use an OpenID Connect (OIDC) provider to handle authentication for users of\nthe web UI and clients of the REST API.\n\n\nConfiguration\n\n\nIn order to use OIDC, Workflow Manager must first be registered with OIDC provider. The exact\nprocess for this varies by provider. As part of the registration process, a client ID and client\nsecret should be provided. Those values should be set in the \nOIDC_CLIENT_ID\n and\n\nOIDC_CLIENT_SECRET\n environment variables. During the registration process the provider will\nlikely request a redirect URI. The redirect URI should be set to the base URI for Workflow Manager\nwith \n/login/oauth2/code/provider\n appended.\n\n\nThe documentation for the OIDC provider should specify the base URI a client should use to\nauthenticate users. The URI should be set in the \nOIDC_ISSUER_URI\n environment variable. To verify\nthe URI is correct, check that the JSON discovery document is returned when sending an HTTP GET\nrequest to the URI with \n/.well-known/openid-configuration\n appended.\n\n\nAfter a user or REST client authenticates with the OIDC provider, Workflow Manager will check for a\nclaim with a specific value to determine if the user is authorized to access Workflow Manager and\nwith what role. The \nOIDC_USER_CLAIM_NAME\n and \nOIDC_ADMIN_CLAIM_NAME\n environment variables\nspecify the name of the claim that must be present. The \nOIDC_USER_CLAIM_VALUE\n and\n\nOIDC_ADMIN_CLAIM_VALUE\n environment variables specify the required value of the claim.\n\n\nIf Workflow Manager is configured to use OIDC, then the component services must also be configured\nto use OIDC. The component services will use OIDC if either the \nOIDC_JWT_ISSUER_URI\n or\n\nOIDC_ISSUER_URI\n environment variables are set on the component service. When a component service\nis configured to use OIDC, the \nOIDC_CLIENT_ID\n and \nOIDC_CLIENT_SECRET\n environment variables are\nused to specify the client ID and secret that will be used during component registration.\n\n\nWorkflow Manager Environment Variables\n\n\n\n\nOIDC_ISSUER_URI\n (Required): URI for the OIDC provider that will be used to authenticate users\n through the web UI. If \nOIDC_JWT_ISSUER_URI\n is not set, \nOIDC_ISSUER_URI\n will also be used to\n authenticate REST clients. The OIDC configuration endpoint must exist at the value of\n \nOIDC_ISSUER_URI\n with \n/.well-known/openid-configuration\n appended.\n\n\nOIDC_JWT_ISSUER_URI\n (Optional): Works the same way as \nOIDC_ISSUER_URI\n, except that the\n configuration will only be used to authenticate REST clients. When not provided,\n \nOIDC_ISSUER_URI\n will be used. This would be used when the authentication provider's endpoint\n for user authentication is different from the endpoint for authentication of REST clients.\n\n\nOIDC_CLIENT_ID\n (Required): The client ID that Workflow Manager will use to authenticate with\n the OIDC provider.\n\n\nOIDC_CLIENT_SECRET\n (Required): The client secret Workflow Manager will use to authenticate\n with the OIDC provider.\n\n\nOIDC_USER_CLAIM_NAME\n (Optional): Specifies the name of the claim from the authentication token\n that is required for a user or REST client to be granted access to Workflow Manager with the\n \nUSER\n role.\n\n\nOIDC_USER_CLAIM_VALUE\n (Optional): Specifies the required value of the claim specified in\n \nOIDC_USER_CLAIM_NAME\n. If the claim is a list, only one of the values in the list must match.\n\n\nOIDC_ADMIN_CLAIM_NAME\n (Optional): Specifies the name of the claim from the authentication token\n that is required for a user or REST client to be granted access to Workflow Manager with the\n \nADMIN\n role.\n\n\nOIDC_ADMIN_CLAIM_VALUE\n (Optional): Specifies the required value of the claim specified in\n \nOIDC_ADMIN_CLAIM_NAME\n. If the claim is a list, only one of the values in the list must match.\n\n\nOIDC_SCOPES\n (Optional): A comma-separated list of the scopes to be requested from the OIDC\n provider when authenticating a user through the web UI. The OIDC specification requires one of\n the scopes to be \nopenid\n, so if this environment variable is omitted or \nopenid\n is not in the\n list, it will be automatically added.\n\n\nOIDC_USER_NAME_ATTR\n (Optional): The name of the claim containing the user name. Defaults to\n \nsub\n.\n\n\nOIDC_REDIRECT_URI\n (Optional): Specifies the URL the user's browser will be redirected to after\n logging in to the OIDC provider. If provided, the URL must end in \n/login/oauth2/code/provider\n.\n This would generally be used when the host name that Workflow Manager uses to connect to the\n OIDC provider is different from the OIDC provider's public host name. The value can use the\n \ntemplate variables supported by Spring.\n\n\n\n\nComponent Environment Variables\n\n\n\n\nOIDC_JWT_ISSUER_URI\n or \nOIDC_ISSUER_URI\n (Required): URI for the OIDC provider that will be used\n to authenticate REST clients. The OIDC configuration endpoint must exist at the value of this\n environment variable with \n/.well-known/openid-configuration\n appended. If both environment\n variables are provided, \nOIDC_JWT_ISSUER_URI\n will be used. If \nOIDC_JWT_ISSUER_URI\n is set on\n Workflow Manager, it should be set to the same value on the component services. If\n \nOIDC_JWT_ISSUER_URI\n is not set on Workflow Manager, \nOIDC_ISSUER_URI\n should be set to the\n same value on Workflow Manager and the component services. When either environment variable is\n set, the \nWFM_USER\n and \nWFM_PASSWORD\n environment variables are ignored.\n\n\nOIDC_CLIENT_ID\n (Required): The client ID that the component service will use when registering\n the component with Workflow Manager.\n\n\nOIDC_CLIENT_SECRET\n (Required): The client secret that the component service will use when\n registering the component with Workflow Manager.\n\n\n\n\nExample with Keycloak\n\n\nThe following example explains how to test Workflow Manager with Keycloak as the OIDC provider.\nIt is just an example and should not be used in production.\n\n\n1. Get the Docker gateway IP address by running the command below. It will be used in later steps.\n\n\ndocker network inspect --format '{{(index .IPAM.Config 0).Gateway}}' bridge\n\n\n\n2. Start Keycloak in development mode using the command below. Do not start Workflow Manager yet.\n The values for the OIDC environment variables are dependent on how you set up Keycloak in the\n following steps.\n\n\ndocker run -p 9090:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin \\\n quay.io/keycloak/keycloak:21.1.1 start-dev\n\n\n\n3. Go to \nhttp://localhost:9090/admin\n in a browser and login with username \nadmin\n and\n password \nadmin\n.\n\n\n4. Create a new realm:\n\n\n\n\nCreate a new realm using the drop down box in upper left that says \"master\".\n\n\nUse the realm name you entered and the gateway IP address from step 1 to set Workflow\n Manager and the component services' \nOIDC_ISSUER_URI\n environment variable to:\n \nhttp://:9090/realms/\n\n\n\n\n5. Create the client that Workflow Manager will use to authenticate users:\n\n\n\n\nUse the \"Clients\" link in the left menu to create a new client.\n\n\nGeneral Settings:\n\n\nThe \"Client type\" needs to be set to \"OpenID Connect\".\n\n\nEnter a \"Client ID\".\n\n\nSet Workflow Manager's \nOIDC_CLIENT_ID\n environment variable to the client ID you entered.\n\n\n\n\n\n\nCapability config:\n\n\n\"Client authentication\" must be enabled.\n\n\n\"Standard flow\" must be enabled.\n\n\n\"Service accounts roles\" must be enabled.\n\n\n\n\n\n\nLogin settings:\n\n\nSet \"Valid redirect URIs\" to\n \nhttp://localhost:8080/workflow-manager/login/oauth2/code/provider\n\n\nSet \"Valid post logout redirect URIs\" to \nhttp://localhost:8080/workflow-manager\n\n\n\n\n\n\nSet Workflow Manager's \nOIDC_CLIENT_SECRET\n environment variable to the \"Client secret\" in the\n \"Credentials\" tab.\n\n\n\n\n6. Create a Keycloak role that maps to a Workflow Manager role:\n\n\n\n\nUse the \"Realm roles\" link in the left menu to create a new role.\n\n\nIf the Keycloak role should make the user an \nADMIN\n in Workflow Manager, set Workflow\n Manager's \nOIDC_ADMIN_CLAIM_VALUE\n to the role name you just entered. If it should be a\n \nUSER\n, then set the \nOIDC_USER_CLAIM_VALUE\n environment variable.\n\n\nOnly one of \nOIDC_ADMIN_CLAIM_VALUE\n and \nOIDC_USER_CLAIM_VALUE\n need to be set. If you would\n like to set up both roles repeat this step.\n\n\n\n\n7. Include the Keycloak role(s) in the access token:\n\n\n\n\nIn the \"Client scopes\" menu add a mapper to the \"roles\" scope.\n\n\nUse the \"groups\" predefined mapper.\n\n\nThe default name \"Token Claim Name\" is \"groups\". This can be changed.\n\n\nIf you created an \nADMIN\n role in step 6 set \nOIDC_ADMIN_CLAIM_NAME\n to the value in\n \"Token Claim Name\". If you created a \nUSER\n role, do the same for \nOIDC_USER_CLAIM_NAME\n.\n\n\n\n\n8. Optionally, set Workflow Manager's \nOIDC_USER_NAME_ATTR\n to \npreferred_username\n to display the\n user name instead of the ID.\n\n\n9. Create Users:\n\n\n\n\nAfter creating a user, set a password in the \"Credentials\" tab.\n\n\nUse the \"Role mapping\" tab to add the user to one of roles created in step 6.\n\n\n\n\n10. Add Component Registration REST client:\n\n\n\n\nUse the \"Clients\" menu to create a new client.\n\n\nCapability config:\n\n\nThe client needs to have \"Client authentication\" and \"Service accounts roles\" enabled.\n\n\nUse the \"Service account roles\" tab to add the client to one of the roles created in step 6.\n\n\n\n\n\n\nSet the component services' \nWFM_USER\n environment variable to the client ID you entered.\n\n\nSet component services' \nWFM_PASSWORD\n environment variable to the \"Client secret\" in the\n \"Credentials\" tab.\n\n\n\n\n11. Add external REST clients:\n\n\n\n\nUse the \"Clients\" menu to create a new client.\n\n\nCapability config:\n\n\nThe client needs to have \"Client authentication\" and \"Service accounts roles\" enabled.\n\n\nUse the \"Service account roles\" tab to add the client to one of the roles created in step 6.\n\n\n\n\n\n\n\n\n12. Start Workflow Manager. When you initially navigate to Workflow Manager, you will be\n redirected to the Keycloak log in page. You can log in using the users created in step 9.\n\n\nTest REST authentication\n\n\nUsing the Docker gateway IP address from step 1, the client ID and secret from step 11, and the\nrealm name from step 4, run the following command:\n\n\ncurl -d grant_type=client_credentials -u ':' 'http://:9090/realms//protocol/openid-connect/token'\n\n\n\nThe response JSON will contain a token in the \n\"access_token\"\n property. That token needs to be\nincluded as a bearer token in REST requests to Workflow Manager. For example:\n\n\ncurl -H \"Authorization: Bearer \" http://localhost:8080/workflow-manager/rest/actions\n\n\n\nUse OAuth when sending job complete callbacks and when posting to TiesDb.\n\n\n1. Create a client for the callback receiver or TiesDb:\n\n\n\n\nUse the \"Clients\" menu to create a new client.\n\n\nCapability config:\n\n\nThe client needs to have \"Client authentication\" and \"Service accounts roles\" enabled.\n\n\n\n\n\n\n\n\n2. Create a client role:\n\n\n\n\nUse the \"Roles\" tab to add a role to the client that was just created.\n\n\n\n\n3. Add the role to the Workflow Manager's client:\n\n\n\n\nGo to the client details page for the client created for Workflow Manager.\n\n\nGo to the \"Service accounts roles\" tab.\n\n\nClick \"Assign role\".\n\n\nChange \"Filter by realm roles\" to \"Filter by clients\".\n\n\nAssign the role created in step 2.\n\n\n\n\n4. Run jobs with the \nCALLBACK_USE_OIDC\n or \nTIES_DB_USE_OIDC\n job properties set.", "title": "OpenID Connect Guide" }, { @@ -287,7 +287,7 @@ }, { "location": "/OpenID-Connect-Guide/index.html#example-with-keycloak", - "text": "The following example explains how to test Workflow Manager with Keycloak as the OIDC provider.\nIt is just an example and should not be used in production. 1. Get the Docker gateway IP address by running the command below. It will be used in later steps. docker network inspect --format '{{(index .IPAM.Config 0).Gateway}}' bridge 2. Start Keycloak in development mode using the command below. Do not start Workflow Manager yet.\n The values for the OIDC environment variables are dependent on how you set up Keycloak in the\n following steps. docker run -p 9090:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin \\\n quay.io/keycloak/keycloak:21.1.1 start-dev 3. Go to http://localhost:9090/admin in a browser and login with username admin and\n password admin . 4. Create a new realm: Create a new realm using the drop down box in upper left that says \"master\". Use the realm name you entered and the gateway IP address from step 1 to set Workflow\n Manager and the component services' OIDC_ISSUER_URI environment variable to:\n http://:9090/realms/ 5. Create the client that Workflow Manager will use to authenticate users: Use the \"Clients\" link in the left menu to create a new client. General Settings: The \"Client type\" needs to be set to \"OpenID Connect\". Enter a \"Client ID\". Set Workflow Manager's OIDC_CLIENT_ID environment variable to the client ID you entered. Capability config: \"Client authentication\" must be enabled. \"Standard flow\" must be enabled. Login settings: Set \"Valid redirect URIs\" to\n http://localhost:8080/workflow-manager/login/oauth2/code/provider Set \"Valid post logout redirect URIs\" to http://localhost:8080/workflow-manager Set Workflow Manager's OIDC_CLIENT_SECRET environment variable to the \"Client secret\" in the\n \"Credentials\" tab. 6. Create a Keycloak role that maps to a Workflow Manager role: Use the \"Realm roles\" link in the left menu to create a new role. If the Keycloak role should make the user an ADMIN in Workflow Manager, set Workflow\n Manager's OIDC_ADMIN_CLAIM_VALUE to the role name you just entered. If it should be a\n USER , then set the OIDC_USER_CLAIM_VALUE environment variable. Only one of OIDC_ADMIN_CLAIM_VALUE and OIDC_USER_CLAIM_VALUE need to be set. If you would\n like to set up both roles repeat this step. 7. Include the Keycloak role(s) in the access token: In the \"Client scopes\" menu add a mapper to the \"roles\" scope. Use the \"groups\" predefined mapper. The default name \"Token Claim Name\" is \"groups\". This can be changed. If you created an ADMIN role in step 6 set OIDC_ADMIN_CLAIM_NAME to the value in\n \"Token Claim Name\". If you created a USER role, do the same for OIDC_USER_CLAIM_NAME . 8. Optionally, set Workflow Manager's OIDC_USER_NAME_ATTR to preferred_username to display the\n user name instead of the ID. 9. Create Users: After creating a user, set a password in the \"Credentials\" tab. Use the \"Role mapping\" tab to add the user to one of roles created in step 6. 10. Add Component Registration REST client: Use the \"Clients\" menu to create a new client. Capability config: The client needs to have \"Client authentication\" and \"Service accounts roles\" enabled. Use the \"Service account roles\" tab to add the client to one of the roles created in step 6. Set the component services' WFM_USER environment variable to the client ID you entered. Set component services' WFM_PASSWORD environment variable to the \"Client secret\" in the\n \"Credentials\" tab. 11. Add external REST clients: Use the \"Clients\" menu to create a new client. Capability config: The client needs to have \"Client authentication\" and \"Service accounts roles\" enabled. Use the \"Service account roles\" tab to add the client to one of the roles created in step 6. 12. Start Workflow Manager. When you initially navigate to Workflow Manager, you will be\n redirected to the Keycloak log in page. You can log in using the users created in step 9.", + "text": "The following example explains how to test Workflow Manager with Keycloak as the OIDC provider.\nIt is just an example and should not be used in production. 1. Get the Docker gateway IP address by running the command below. It will be used in later steps. docker network inspect --format '{{(index .IPAM.Config 0).Gateway}}' bridge 2. Start Keycloak in development mode using the command below. Do not start Workflow Manager yet.\n The values for the OIDC environment variables are dependent on how you set up Keycloak in the\n following steps. docker run -p 9090:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin \\\n quay.io/keycloak/keycloak:21.1.1 start-dev 3. Go to http://localhost:9090/admin in a browser and login with username admin and\n password admin . 4. Create a new realm: Create a new realm using the drop down box in upper left that says \"master\". Use the realm name you entered and the gateway IP address from step 1 to set Workflow\n Manager and the component services' OIDC_ISSUER_URI environment variable to:\n http://:9090/realms/ 5. Create the client that Workflow Manager will use to authenticate users: Use the \"Clients\" link in the left menu to create a new client. General Settings: The \"Client type\" needs to be set to \"OpenID Connect\". Enter a \"Client ID\". Set Workflow Manager's OIDC_CLIENT_ID environment variable to the client ID you entered. Capability config: \"Client authentication\" must be enabled. \"Standard flow\" must be enabled. \"Service accounts roles\" must be enabled. Login settings: Set \"Valid redirect URIs\" to\n http://localhost:8080/workflow-manager/login/oauth2/code/provider Set \"Valid post logout redirect URIs\" to http://localhost:8080/workflow-manager Set Workflow Manager's OIDC_CLIENT_SECRET environment variable to the \"Client secret\" in the\n \"Credentials\" tab. 6. Create a Keycloak role that maps to a Workflow Manager role: Use the \"Realm roles\" link in the left menu to create a new role. If the Keycloak role should make the user an ADMIN in Workflow Manager, set Workflow\n Manager's OIDC_ADMIN_CLAIM_VALUE to the role name you just entered. If it should be a\n USER , then set the OIDC_USER_CLAIM_VALUE environment variable. Only one of OIDC_ADMIN_CLAIM_VALUE and OIDC_USER_CLAIM_VALUE need to be set. If you would\n like to set up both roles repeat this step. 7. Include the Keycloak role(s) in the access token: In the \"Client scopes\" menu add a mapper to the \"roles\" scope. Use the \"groups\" predefined mapper. The default name \"Token Claim Name\" is \"groups\". This can be changed. If you created an ADMIN role in step 6 set OIDC_ADMIN_CLAIM_NAME to the value in\n \"Token Claim Name\". If you created a USER role, do the same for OIDC_USER_CLAIM_NAME . 8. Optionally, set Workflow Manager's OIDC_USER_NAME_ATTR to preferred_username to display the\n user name instead of the ID. 9. Create Users: After creating a user, set a password in the \"Credentials\" tab. Use the \"Role mapping\" tab to add the user to one of roles created in step 6. 10. Add Component Registration REST client: Use the \"Clients\" menu to create a new client. Capability config: The client needs to have \"Client authentication\" and \"Service accounts roles\" enabled. Use the \"Service account roles\" tab to add the client to one of the roles created in step 6. Set the component services' WFM_USER environment variable to the client ID you entered. Set component services' WFM_PASSWORD environment variable to the \"Client secret\" in the\n \"Credentials\" tab. 11. Add external REST clients: Use the \"Clients\" menu to create a new client. Capability config: The client needs to have \"Client authentication\" and \"Service accounts roles\" enabled. Use the \"Service account roles\" tab to add the client to one of the roles created in step 6. 12. Start Workflow Manager. When you initially navigate to Workflow Manager, you will be\n redirected to the Keycloak log in page. You can log in using the users created in step 9.", "title": "Example with Keycloak" }, { @@ -295,6 +295,11 @@ "text": "Using the Docker gateway IP address from step 1, the client ID and secret from step 11, and the\nrealm name from step 4, run the following command: curl -d grant_type=client_credentials -u ':' 'http://:9090/realms//protocol/openid-connect/token' The response JSON will contain a token in the \"access_token\" property. That token needs to be\nincluded as a bearer token in REST requests to Workflow Manager. For example: curl -H \"Authorization: Bearer \" http://localhost:8080/workflow-manager/rest/actions", "title": "Test REST authentication" }, + { + "location": "/OpenID-Connect-Guide/index.html#use-oauth-when-sending-job-complete-callbacks-and-when-posting-to-tiesdb", + "text": "1. Create a client for the callback receiver or TiesDb: Use the \"Clients\" menu to create a new client. Capability config: The client needs to have \"Client authentication\" and \"Service accounts roles\" enabled. 2. Create a client role: Use the \"Roles\" tab to add a role to the client that was just created. 3. Add the role to the Workflow Manager's client: Go to the client details page for the client created for Workflow Manager. Go to the \"Service accounts roles\" tab. Click \"Assign role\". Change \"Filter by realm roles\" to \"Filter by clients\". Assign the role created in step 2. 4. Run jobs with the CALLBACK_USE_OIDC or TIES_DB_USE_OIDC job properties set.", + "title": "Use OAuth when sending job complete callbacks and when posting to TiesDb." + }, { "location": "/Media-Segmentation-Guide/index.html", "text": "NOTICE:\n This software (or technical data) was produced for the U.S. Government under contract, and is subject to the\nRights in Data-General Clause 52.227-14, Alt. IV (DEC 2007). Copyright 2023 The MITRE Corporation. All Rights Reserved.\n\n\nDetection Chaining\n\n\nThe OpenMPF has the ability to chain detection tasks together in a detection pipeline. As each detection stage in the pipeline completes, the volume of data to be processed in the next stage may be reduced. Generally, any detection tasks executed prior to the final detection task in the pipeline are referred to as preprocessors or filters. For example, consider the following pipeline which demonstrates the use of a motion preprocessor:\n\n\n\n\nIn the pipeline above, the motion preprocessor reduces the volume of data which is passed to the face detector. This is particularly useful when the input media collection contains videos captured by a fixed-location camera. For example, a camera targeting a chokepoint such as a hallway door. The motion preprocessor will filter the input media so that only regions of video containing motion are passed on to the face detector.\n\n\nDetection pipelines may be created with, or without, preprocessors and filters using the Create Custom Pipelines view.\n\n\n\n\nWARNING: Preprocessors and filters may ultimately eliminate the entirety of a media file. When an entire media file is eliminated, none of the subsequent stages in the pipeline will operate on that file. Therefore, it is important to consider the consequences of using preprocessors/filters. For example, when the motion detection receives an image or audio file, its default behavior is to return a response indicating that the file did not contain any motion tracks. If the pipeline continued to face detection then none of the image files would be eligible for that kind of detection.\n\n\n\n\n\"USE_PREPROCESSOR\" Property\n\n\nIn order to mitigate the risk of eliminating useful media files simply because they are not supported by a detector using its default settings, some algorithms expose a \"USE_PREPROCESSOR\" property. When a user creates an action based on a detector with this property, the user may assign this property a nonzero value in order to indicate that the detector should behave as a preprocessor as opposed to a filter. When acting as a preprocessor, a detector will not emit an empty detection set when provided with an unsupported media type, rather it will return a single track spanning the duration of the media file. Thus, when configured with the \"USE_PREPROCESSOR\" setting, the motion detector will not prevent images from passing on to the next stage in the pipeline, for example.\n\n\nSegmenting Media\n\n\nThe OpenMPF allows users to configure video segmenting properties for actions in a pipeline. Audio files (which do not have the concept of \"frames\") and image files (which are treated like single-frame videos) are not affected by these properties.\n\n\nSegmenting is performed before a detection action in order to split work across the available detection services running on the various nodes in the OpenMPF cluster. In general, each instance of a detection service can process one video segment at a time. Multiple services can process separate segments at the same time, thus enabling parallel processing. There are two fundamental segmenting scenarios:\n\n\n\n\nSegmenting must be performed on a video which has not passed through a preprocessor or filter.\n\n\nSegmenting must be performed on a video which has passed through a preprocessor or filter.\n\n\n\n\nIn the first scenario the segmenting logic is less complex. The segmenter will create a supersegment corresponding to the entire length of the video (in frames), and it will then divide the supersegment into segments which respect the provided \"TARGET_SEGMENT_LENGTH\" and \"MIN_SEGMENT_LENGTH\" properties.\n\n\nIn the second scenario the segmenting logic is more complex. The segmenter first examines the start and stop times associated with all of the overlapping tracks produced by the previous detection action in the pipeline and proceeds to merge those intervals and segment the result. The goal is to generate a minimum number of segments that don't include unnecessary frames (frames that don't belong to any tracks). For example:\n\n\n\n\n\"TARGET_SEGMENT_LENGTH\" Property\n\n\nThis property indicates the preferred number of frames which will be provided to the detection component. For example, a value of \"100\" indicates that the input video should be split into 100-frame segments. Note that the properties \"MIN_SEGMENT_LENGTH\" and \"MIN_GAP_BETWEEN_SEGMENTS\" may ultimately cause segments to vary from the preferred segment size.\n\n\n\"MIN_SEGMENT_LENGTH\" Property\n\n\nIf a segment length is less than this value, the segment will be merged into the segment that precedes it. If no segment precedes it, the short segment will stand on its own. Short segments are not discarded.\n\n\nExample 1: Adjacent Segment Present\n\n\n\n\n\n\nIn this example, a preprocessor has completed and produced a single track.\n\n\nThe next detection action specifies the following parameters:\n\n\n\"TARGET_SEGMENT_LENGTH\" = 100\n\n\n\"MIN_SEGMENT_LENGTH\" = 75\n\n\n\n\n\n\nThree segments are initially produced from the input track with lengths corresponding to 100 frames, 100 frames, and 50 frames.\n\n\nSince segment 3 is not at least the minimum specified segment length, it is merged with segment 2.\n\n\nUltimately, two segments are produced.\n\n\n\n\nExample 2: No Adjacent Segment\n\n\n\n\n\n\nIn this example, a preprocessor has completed and produced two non-overlapping tracks.\n\n\nThe next detection action specifies the following parameters:\n\n\n\"TARGET_SEGMENT_LENGTH\" = 100\n\n\n\"MIN_SEGMENT_LENGTH\" = 75\n\n\n\"MIN_GAP_BETWEEN_SEGMENTS\" = 50\n\n\n\n\n\n\nThe segmenter begins by merging any segments which are less than \"MIN_GAP_BETWEEN_SEGMENTS\" apart. There are none.\n\n\nThe segmenter then splits the existing segments using the \"MIN_SEGMENT_LENGTH\" and \"TARGET_SEGMENT_LENGTH\" values.\n\n\nThe segmenter iterates through each segment produced. If the segment satisfies the minimum length constraint, it moves to the next segment.\n\n\nWhen it reaches the third segment and finds the length of 50 frames is not at least the minimum length, it merges that segment with the previous adjacent segment.\n\n\nWhen it reaches the final segment and finds that the length of 25 frames is not at least the minimum length, it creates a short segment since there is no adjacent preceding segment to merge it with.\n\n\n\n\n\n\nUltimately, three segments are produced.\n\n\n\n\n\"MIN_GAP_BETWEEN_SEGMENTS\" Property\n\n\nThis property is important to pipelines which contain preprocessors or filters and controls the minimum gap which must appear between consecutive segments. The purpose of this property is to prevent scenarios where a preprocessor or filter produces a large number of short segments separated by only a few frames. By merging the segments together prior to performing further segmentation, the number of work units produced by the segmenting plan can be reduced, thereby reducing pipeline execution time.\n\n\nConsider the following diagram, which further illustrates the purpose of this property:\n\n\n\n\n\n\nThe user submits a video to a pipeline containing a motion preprocessor followed by another extractor (e.g., face).\n\n\nThe video is initially split into segments using the properties provided by the motion preprocessor. Specifically, the preprocessor action specifies the following parameters and four segments are produced:\n\n\n\"TARGET_SEGMENT_LENGTH\" = \"250\"\n\n\n\"MIN_SEGMENT_LENGTH\" = \"150\"\n\n\n\"MERGE_TRACKS\" = \"true\"\n\n\n\n\n\n\nThe segments are submitted to the motion preprocessor, and five distinct and non-overlapping tracks are returned based on the frames of the segments in which motion is detected.\n\n\nBecause the \"MERGE_TRACKS\" property is set to \"true\", tracks are merged across segment boundaries if applicable.\n This rule is applied to each pair of tracks that are only one frame apart (adjacent). Consequently, only three\n tracks are ultimately derived from the video. (The number of tracks is reduced from five to three between the\n \"Preprocessor\" and \"Track Merger\" phases of the diagram.) When two tracks are merged, the confidence value will be\n set to the maximum confidence value of the two tracks and their track properties will be merged. If the two tracks\n both have a track property with the same name but different values, the values will be concatenated with a\n semicolon as the separator.\n\n\nThe non-overlapping tracks are then used to form the video segments for the next detection action. This action specifies the following parameters:\n\n\n\"TARGET_SEGMENT_LENGTH\" = \"75\"\n\n\n\"MIN_SEGMENT_LENGTH\" = \"26\"\n\n\n\"MIN_GAP_BETWEEN_SEGMENTS\" = \"100\"\n\n\n\n\n\n\nThe segmenting logic merges tracks which are less than \"MIN_GAP_BETWEEN_SEGMENTS\" frames apart into one long segment. Once all tracks have been merged, each track is segmented with respect to the provided \"TARGET_SEGMENT_LENGTH\" and \"MIN_SEGMENT_LENGTH\" properties. Ultimately, ten segments are produced. (Track #1 and Track #2 in the \"Track Merger\" phase of the diagram are combined, which is why Segment #3 in the \"Segmenter\" phase of the diagram includes the 25 frames that span the gap between those two tracks.)", diff --git a/docs/site/sitemap.xml b/docs/site/sitemap.xml index fc59088946eb..f4c4852bb52e 100644 --- a/docs/site/sitemap.xml +++ b/docs/site/sitemap.xml @@ -2,137 +2,137 @@ /index.html - 2023-11-29 + 2023-11-30 daily /Release-Notes/index.html - 2023-11-29 + 2023-11-30 daily /License-And-Distribution/index.html - 2023-11-29 + 2023-11-30 daily /Acknowledgements/index.html - 2023-11-29 + 2023-11-30 daily /Install-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Admin-Guide/index.html - 2023-11-29 + 2023-11-30 daily /User-Guide/index.html - 2023-11-29 + 2023-11-30 daily /OpenID-Connect-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Media-Segmentation-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Feed-Forward-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Derivative-Media-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Object-Storage-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Markup-Guide/index.html - 2023-11-29 + 2023-11-30 daily /TiesDb-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Trigger-Guide/index.html - 2023-11-29 + 2023-11-30 daily /REST-API/index.html - 2023-11-29 + 2023-11-30 daily /Component-API-Overview/index.html - 2023-11-29 + 2023-11-30 daily /Component-Descriptor-Reference/index.html - 2023-11-29 + 2023-11-30 daily /CPP-Batch-Component-API/index.html - 2023-11-29 + 2023-11-30 daily /Python-Batch-Component-API/index.html - 2023-11-29 + 2023-11-30 daily /Java-Batch-Component-API/index.html - 2023-11-29 + 2023-11-30 daily /GPU-Support-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Contributor-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Development-Environment-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Node-Guide/index.html - 2023-11-29 + 2023-11-30 daily /Workflow-Manager-Architecture/index.html - 2023-11-29 + 2023-11-30 daily /CPP-Streaming-Component-API/index.html - 2023-11-29 + 2023-11-30 daily \ No newline at end of file From cfcbf8a9f8c34bca403d67640746892ae2657f23 Mon Sep 17 00:00:00 2001 From: Brian Rosenberg Date: Thu, 30 Nov 2023 13:37:05 -0500 Subject: [PATCH 2/4] Fix step 1 --- docs/docs/OpenID-Connect-Guide.md | 1 + docs/site/OpenID-Connect-Guide/index.html | 1 + docs/site/index.html | 2 +- docs/site/search/search_index.json | 4 ++-- 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/docs/OpenID-Connect-Guide.md b/docs/docs/OpenID-Connect-Guide.md index 7aed18db9080..04771dd68c05 100644 --- a/docs/docs/OpenID-Connect-Guide.md +++ b/docs/docs/OpenID-Connect-Guide.md @@ -198,6 +198,7 @@ curl -H "Authorization: Bearer " http://localhost:8080/workflow-ma - Use the "Clients" menu to create a new client. - Capability config: - The client needs to have "Client authentication" and "Service accounts roles" enabled. +- Configure the callback receiver or TiesDb with the client ID and secret. 2\. Create a client role: diff --git a/docs/site/OpenID-Connect-Guide/index.html b/docs/site/OpenID-Connect-Guide/index.html index dbfde7f547fd..70746e9ff75a 100644 --- a/docs/site/OpenID-Connect-Guide/index.html +++ b/docs/site/OpenID-Connect-Guide/index.html @@ -421,6 +421,7 @@

    • +
  • Configure the callback receiver or TiesDb with the client ID and secret.

    • 2. Create a client role: