From 73b3c5f4b5afe946de420a45a0929b46b1a19979 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Fri, 17 Nov 2023 22:15:38 +0700 Subject: [PATCH 01/47] docs: multitenancy phase 2 doc wip Signed-off-by: Pat Losoponkul --- .../multitenancy/tenant-onboarding-ext-iam.md | 183 ++++++++++++++++++ .../tenant-onboarding-self-service.md | 1 + docs/docusaurus/sidebars.js | 4 +- 3 files changed, 187 insertions(+), 1 deletion(-) create mode 100644 docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md create mode 100644 docs/docusaurus/multitenancy/tenant-onboarding-self-service.md diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md new file mode 100644 index 0000000000..c5ff93143b --- /dev/null +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -0,0 +1,183 @@ +# Tenant Onboarding with External IAM + +In the [Tenant Onboarding](./tenant-onboarding.md) tutorial, we explored the basic +IAM functionality provided by the agent out of the box. Although it is usable and straightforward, +there are robust and more powerful tools available for handling identity and access management. +The agent has the capability to seamlessly connect with Keycloak as an external IAM system. +The application built on top is able utilize any available OAuth flow configured on Keycloak. +The token issued by Keycloak can then be used for both authentication and authorization within the PRISM Agent. + +The PRISM Agent leverages standard protocols like OIDC and UMA for authentication and resource access management. +The user's identity is established through the OIDC token, and resource permissions can be queried using the RPT (requesting party token). + +## Roles + +In tenant management with external IAM, there are 2 roles: + +1. System administrator +2. Tenant + +## Prerequisites + +1. Keycloak up and running +2. Keycloak is configured as follows + 1. A realm called `my-realm` is created + 2. A client called `prism-agent` under `my-realm` with __authorization__ feature is created. (See [create client instruction](https://www.keycloak.org/docs/latest/authorization_services/index.html#_resource_server_create_client)) + 3. Make sure the `prism-agent` client has __direct access grants__ enabled to simplify login process in this tutorial +3. PRISM Agent up and running +4. PRISM Agent is configured with the following environment variables: + 1. `ADMIN_TOKEN=my-admin-token` + 2. `DEFAULT_WALLET_ENABLED=false` + 3. `KEYCLOAK_ENABLED=true` + 4. `KEYCLOAK_URL=http://localhost:9980` (replace with appropriate value) + 5. `KEYCLOAK_REALM=my-realm` + 6. `KEYCLOAK_CLIENT_ID=prism-agent` + 7. `KEYCLOAK_CLIENT_SECRET=` (replace with appropriate value) + 8. `KEYCLOAK_UMA_AUTO_UPGRADE_RPT=false` + +## Overview + +This is a guide on how to onboard a new tenant from scratch using Keycloak as an external IAM. +This tutorial will illustrate the process of creating a tenant in Keycloak and subsequently +provisioning a wallet resource for the new tenant by the administrator. +The administrator can then create a UMA permission for the wallet giving access to the tenant. + +Once the registration is successful, the tenant can obtain an ID token from Keycloak using any available OAuth flow, +such as the direct access grants (username & password). This ID token typically contains user claims such as username or subject ID. +The tenant can utilize Keycloak's token endpoint to upgrade this token to an RPT (requesting party token), +which is another token containing permissions on permitted resources. +The tenant can access the multi-tenant agent by providing the RPT in the authorization header. + +## Endpoints + +### Agent endpoints +| Endpoint | Description | Role | +|--------------------------------------------|--------------------------------------|---------------| +| `GET /wallets` | List the wallets on PRISM Agent | Administrator | +| `POST /wallets` | Create a new wallet on PRISM Agent | Administrator | +| `POST /wallets/{walletId}/uma-permissions` | Create a uma-permission for a wallet | Administrator | +| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | + +### Keycloak endpoints +| Endpoint | Description | Role | +|-----------------------------------------------------|-------------------------------|---------------| +| `POST /admin/realms/{realm}/users` | Create a new user on Keycloak | Administrator | +| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | All roles | + +## Administrator interactions + +### 1. Check the existing wallets + +When running PRISM Agent using the configurations above, the Agent should start with an empty state. +Listing wallets on it should return empty results. + +```bash +curl -X 'GET' \ + 'http://localhost:8080/prism-agent/wallets' \ + -H 'accept: application/json' \ + -H 'x-admin-api-key: my-admin-token' +``` + +Response Example: + +```json +{ + "self": "/wallets", + "kind": "WalletPage", + "pageOf": "/wallets", + "contents": [] +} +``` + +### 2. Create a new wallet + +The wallet can be created using a `POST /wallets` endpoint. +This wallet is going to act as a container for the tenant's assets (DIDs, VCs, Connections, etc.). +The wallet seed may be provided during the wallet creation or omitted to let the Agent generate one randomly. + + +```bash +curl -X 'POST' \ + 'http://localhost:8080/prism-agent/wallets' \ + -H 'accept: application/json' \ + -H 'x-admin-api-key: my-admin-token' \ + -H 'Content-Type: application/json' \ + -d '{ + "seed": "c9994785ce6d548134020f610b76102ca1075d3bb672a75ec8c9a27a7b8607e3b9b384e43b77bb08f8d5159651ae38b98573f7ecc79f2d7e1f1cc371ce60cf8a", + "name": "my-wallet" + }' +``` + +Response Example: + +```json +{ + "id": "99734c87-5c9d-4697-b5fd-dea4e9590ba7", + "name": "my-wallet", + "createdAt": "2023-01-01T00:00:00Z", + "updatedAt": "2023-01-01T00:00:00Z" +} +``` + +### 3. User registration on Keycloak + +There are multiple ways to complete this step. +The objective is to ensure the user is registered on Keycloak. +Keycloak offers flexibility in configuration, allowing users to self-register, +connect to identity providers, or be manually created by an administrator. +For this tutorial, the user will be manually created using Keycloak admin API for simplicity. + +The first step involves getting an admin token from Keycloak using the admin username and password. +Running the provided command should return the admin access token. + +```bash +curl -X 'POST' \ + 'http://localhost:9980/realms/master/protocol/openid-connect/token' \ + -d "grant_type=password" \ + -d "client_id=admin-cli" \ + -d "username=$KEYCLOAK_ADMIN_USER" \ + -d "password=$KEYCLOAK_ADMIN_PASSWORD" +``` + +Replace the Keycloak variables with appropriate values. + +Example token response (some fields omitted for readability) + +```json +{ + "access_token": "eyJhbGciOi...7ocDHofUDQ", + "refresh_token": "eyJhbGciOi...otsEEi4eQA", + "token_type": "Bearer", + ... +} +``` + +After the admin has obtained an `access_token` from Keycloak, a new user can be created by running this command. + +```bash +curl -X 'POST' \ + 'http://localhost:9980/admin/realms/my-realm/users' \ + -H 'Authorization: Bearer eyJhbGciOi...7ocDHofUDQ' \ + -H 'Content-Type: application/json' \ + --data-raw "{ + \"id\": \"alice\", + \"username\": \"alice\", + \"firstName\": \"Alice\", + \"enabled\": true, + \"credentials\": [{\"value\": \"1234\", \"temporary\": false}] + }" +``` + +Make sure to use the correct `access_token` in the `Authorization` header from the previous command. + +The response should return status `201 Created` indicating the new user is registerd with id `alice` with a password `1234`. + +### 4. Grant the user permission to the wallet + +## Tenant interactions + +### 1. Obtain access token from Keycloak + +### 2. Request RPT (requesting party token) from access token + +### 3. Perform a simple action to verify access to PRISM Agent diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md new file mode 100644 index 0000000000..086bc93869 --- /dev/null +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -0,0 +1 @@ +# Tenant Onboarding Self-Service diff --git a/docs/docusaurus/sidebars.js b/docs/docusaurus/sidebars.js index 388eadb21b..3ee3e28bef 100644 --- a/docs/docusaurus/sidebars.js +++ b/docs/docusaurus/sidebars.js @@ -91,7 +91,9 @@ const sidebars = { type: 'category', label: 'Multi-Tenancy', items: [ - 'multitenancy/tenant-onboarding' + 'multitenancy/tenant-onboarding', + 'multitenancy/tenant-onboarding-ext-iam', + 'multitenancy/tenant-onboarding-self-service', ] } ] From ea82a5706d7163488138a90770ac59c3cd88896f Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Sat, 18 Nov 2023 02:54:28 +0700 Subject: [PATCH 02/47] docs: complete onboarding tut Signed-off-by: Pat Losoponkul --- .../multitenancy/tenant-onboarding-ext-iam.md | 177 +++++++++++++++--- 1 file changed, 156 insertions(+), 21 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index c5ff93143b..7d93bfab0e 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -3,12 +3,12 @@ In the [Tenant Onboarding](./tenant-onboarding.md) tutorial, we explored the basic IAM functionality provided by the agent out of the box. Although it is usable and straightforward, there are robust and more powerful tools available for handling identity and access management. -The agent has the capability to seamlessly connect with Keycloak as an external IAM system. -The application built on top is able utilize any available OAuth flow configured on Keycloak. -The token issued by Keycloak can then be used for both authentication and authorization within the PRISM Agent. +The agent has the capability to seamlessly connect with Keycloak as an external IAM system +allowing the application built on top to utilize available OIDC flow on Keycloak. +The token issued by Keycloak can be used for wallet authorization by the PRISM Agent. The PRISM Agent leverages standard protocols like OIDC and UMA for authentication and resource access management. -The user's identity is established through the OIDC token, and resource permissions can be queried using the RPT (requesting party token). +The user's identity is established through the ID token, and resource permissions can be queried using the RPT (requesting party token). ## Roles @@ -23,7 +23,7 @@ In tenant management with external IAM, there are 2 roles: 2. Keycloak is configured as follows 1. A realm called `my-realm` is created 2. A client called `prism-agent` under `my-realm` with __authorization__ feature is created. (See [create client instruction](https://www.keycloak.org/docs/latest/authorization_services/index.html#_resource_server_create_client)) - 3. Make sure the `prism-agent` client has __direct access grants__ enabled to simplify login process in this tutorial + 3. Make sure the `prism-agent` client has __direct access grants__ enabled to simplify login process for this tutorial 3. PRISM Agent up and running 4. PRISM Agent is configured with the following environment variables: 1. `ADMIN_TOKEN=my-admin-token` @@ -37,13 +37,19 @@ In tenant management with external IAM, there are 2 roles: ## Overview -This is a guide on how to onboard a new tenant from scratch using Keycloak as an external IAM. -This tutorial will illustrate the process of creating a tenant in Keycloak and subsequently +This tutorial illustrates the process of creating a tenant in Keycloak and subsequently provisioning a wallet resource for the new tenant by the administrator. The administrator can then create a UMA permission for the wallet giving access to the tenant. -Once the registration is successful, the tenant can obtain an ID token from Keycloak using any available OAuth flow, -such as the direct access grants (username & password). This ID token typically contains user claims such as username or subject ID. +When setting up UMA permissions on the agent, the wallet resource along with the UMA policy and permission +are created on Keycloak according to a predefined convention. +For greater flexibility in defining custom policy and permission models, +administrators can also manually create these UMA resources (resource, policy, permission) directly on Keycloak +using a set of UMA endpoints called [Protection API](https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_protection_api). +However, using Protection API to manage permissions is out of scope for this tutorial. + +Once the registration is successful, the tenant can obtain an ID token from Keycloak using any available OIDC flow, +such as the direct access grants (username & password). This ID token typically contains user claims such as username and subject ID. The tenant can utilize Keycloak's token endpoint to upgrade this token to an RPT (requesting party token), which is another token containing permissions on permitted resources. The tenant can access the multi-tenant agent by providing the RPT in the authorization header. @@ -59,10 +65,10 @@ The tenant can access the multi-tenant agent by providing the RPT in the authori | `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | ### Keycloak endpoints -| Endpoint | Description | Role | -|-----------------------------------------------------|-------------------------------|---------------| -| `POST /admin/realms/{realm}/users` | Create a new user on Keycloak | Administrator | -| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | All roles | +| Endpoint | Description | Role | +|-----------------------------------------------------|-------------------------------|-----------------------| +| `POST /admin/realms/{realm}/users` | Create a new user on Keycloak | Administrator | +| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Administrator, Tenant | ## Administrator interactions @@ -122,12 +128,12 @@ Response Example: ### 3. User registration on Keycloak There are multiple ways to complete this step. -The objective is to ensure the user is registered on Keycloak. -Keycloak offers flexibility in configuration, allowing users to self-register, -connect to identity providers, or be manually created by an administrator. +The goal is to ensure the user is registered on Keycloak. +Keycloak offers great flexibility, allowing users to self-register, +connect to IDP, or be manually created by an administrator. For this tutorial, the user will be manually created using Keycloak admin API for simplicity. -The first step involves getting an admin token from Keycloak using the admin username and password. +The first step involves getting an admin token from Keycloak using the Keycloak admin username and password. Running the provided command should return the admin access token. ```bash @@ -139,7 +145,7 @@ curl -X 'POST' \ -d "password=$KEYCLOAK_ADMIN_PASSWORD" ``` -Replace the Keycloak variables with appropriate values. +Make sure to replace the Keycloak variables with appropriate values. Example token response (some fields omitted for readability) @@ -147,7 +153,6 @@ Example token response (some fields omitted for readability) { "access_token": "eyJhbGciOi...7ocDHofUDQ", "refresh_token": "eyJhbGciOi...otsEEi4eQA", - "token_type": "Bearer", ... } ``` @@ -157,10 +162,10 @@ After the admin has obtained an `access_token` from Keycloak, a new user can be ```bash curl -X 'POST' \ 'http://localhost:9980/admin/realms/my-realm/users' \ + -v \ -H 'Authorization: Bearer eyJhbGciOi...7ocDHofUDQ' \ -H 'Content-Type: application/json' \ --data-raw "{ - \"id\": \"alice\", \"username\": \"alice\", \"firstName\": \"Alice\", \"enabled\": true, @@ -170,14 +175,144 @@ curl -X 'POST' \ Make sure to use the correct `access_token` in the `Authorization` header from the previous command. -The response should return status `201 Created` indicating the new user is registerd with id `alice` with a password `1234`. +Example response log + +```log +< HTTP/1.1 201 Created +< Referrer-Policy: no-referrer +< X-Frame-Options: SAMEORIGIN +< Strict-Transport-Security: max-age=31536000; includeSubDomains +< X-Content-Type-Options: nosniff +< X-XSS-Protection: 1; mode=block +< Location: http://localhost:9980/admin/realms/my-realm/users/205e04b7-0158-41b0-89c3-f91c3a09f89b +< content-length: 0 +``` + +The response should return status `201 Created` indicating the new user is registerd with username `alice` with a password `1234`. +The user ID can be observed from `Location` header of the response. This ID will be used for creating permission later in this tutorial. + +For in-depth user management, please consult the official Keycloaak administration documentation on [managing users section](https://www.keycloak.org/docs/latest/server_admin/index.html#assembly-managing-users_server_administration_guide). ### 4. Grant the user permission to the wallet +Once the user and wallet have been successfully created, the permissions can be created giving the user access to the wallet. +This action is accomplished by invoking the `POST /wallets/{walletId}/uma-permissions` endpoint on the agent. + +```bash +curl -X 'POST' \ + 'http://localhost:8080/prism-agent/wallets/99734c87-5c9d-4697-b5fd-dea4e9590ba7/uma-permissions' \ + -H 'accept: */*' \ + -H 'x-admin-api-key: my-admin-token' \ + -H 'Content-Type: application/json' \ + -d '{ + "subject": "205e04b7-0158-41b0-89c3-f91c3a09f89b", + }' +``` + +Make sure to use the correct `subject` for the user and the correct `walletId` from the step earlier. +The user ID can be observed from the response header from the previous step or in the __User__ menu in Keycloak Admin UI. + +The response should return status `200 OK` in case of successful permission creation. + ## Tenant interactions +After the user is registered on Keycloak and the required permission is created by admin, +the tenant can log in and utilize the agent by using the token issued by Keycloak. + ### 1. Obtain access token from Keycloak +The first step is to authenticate via Keycloak through any applicable authentication method. +Usually, the tenant will use some frontend application that follows the standard flow for logging in. +For simplicity, a username and password flow will be used in this tutorial. +The administrator has already set up the username and password for the tenant. +The tenant can call Keycloak token endpoint directly with those credentials to get the access token. + +Run the command to log in + +```bash +curl -X 'POST' \ + 'http://localhost:9980/realms/my-realm/protocol/openid-connect/token' \ + -d "grant_type=password" \ + -d "client_id=admin-cli" \ + -d "username=alice" \ + -d "password=1234" +``` + +Note the `client_id` is `admin-cli`. This should be the actual `client_id` of the frontend application that log the user in. +For this tutorial, it is absolutely OK. + +Example token response (some fields omitted for readability) + +```json +{ + "access_token": "eyJhbGciOi...7ocDHofUDQ", + "refresh_token": "eyJhbGciOi...otsEEi4eQA", + ... +} +``` + ### 2. Request RPT (requesting party token) from access token +After the access token is aquired, the next step is to get the RPT token which holds information about the permissions. +The RPT can be requested by running this command + +```bash +curl -X POST \ + 'http://localhost:9980/realms/my-realm/protocol/openid-connect/token' \ + -H "Authorization: Bearer eyJhbGciOi...7ocDHofUDQ" \ + -d "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \ + -d "audience=prism-agent" +``` + +Example token response (some fields omitted for readability) + +```json +{ + "access_token": "eyJhbGciOi...e7H6W8RUvA", + "refresh_token": "eyJhbGciOi...W1_y1AF_YY", + ... +} +``` + +Inspecting the token of the response using this [JWT debugger](https://jwt.io/), there should be a new claims in the JWT payload called `authorization`. + +Example RPT payload (some fields omitted for readability) + +```json +{ + ... + "authorization": { + "permissions": [ + { + "rsid": "99734c87-5c9d-4697-b5fd-dea4e9590ba7", + "rsname": "Resource Name" + }, + ... + ] + }, + ... +} +``` + ### 3. Perform a simple action to verify access to PRISM Agent + +To prove that the tenant can access the wallet, +try listing the DIDs in the wallet using RPT in the `Authorization` header. + +```bash +curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/dids' \ + --header "Authorization: Bearer eyJhbGciOi...e7H6W8RUvA" \ + --header 'Accept: application/json' +``` + +The result should show 200 status with an empty list. +This means that the wallet has been created and it does not contain any DIDs. +Any interactions that the tenant performs should be scoped to only this wallet. + +### A note on RPT + +In this tutorial, there is an additional step for the tenant to request the RPT from the access token before granting access to the wallet. +This aligns with the standard UMA interaction, where the handling of RPT typically occurs on the client side. +To streamline the development experience, the agent has a feature that allows developers to bypass this process. +By setting the variable `KEYCLOAK_UMA_AUTO_UPGRADE_RPT=true`, tenants can utilize the access token +obtained in step 1 directly in the `Authorization` header, eliminating the need for additional RPT request step. From 52a7f2b35bc2e0bb58be42596e240fb44b6f9ed8 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 11:54:26 +0700 Subject: [PATCH 03/47] docs: minor adjustment Signed-off-by: Pat Losoponkul --- .../multitenancy/tenant-migration.md | 0 .../multitenancy/tenant-onboarding-ext-iam.md | 18 ++++++++++-------- docs/docusaurus/sidebars.js | 1 + 3 files changed, 11 insertions(+), 8 deletions(-) create mode 100644 docs/docusaurus/multitenancy/tenant-migration.md diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md new file mode 100644 index 0000000000..e69de29bb2 diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index 7d93bfab0e..4a76b96cc2 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -50,7 +50,7 @@ However, using Protection API to manage permissions is out of scope for this tut Once the registration is successful, the tenant can obtain an ID token from Keycloak using any available OIDC flow, such as the direct access grants (username & password). This ID token typically contains user claims such as username and subject ID. -The tenant can utilize Keycloak's token endpoint to upgrade this token to an RPT (requesting party token), +The tenant can use Keycloak's token endpoint to convert this token to an RPT (requesting party token), which is another token containing permissions on permitted resources. The tenant can access the multi-tenant agent by providing the RPT in the authorization header. @@ -133,7 +133,8 @@ Keycloak offers great flexibility, allowing users to self-register, connect to IDP, or be manually created by an administrator. For this tutorial, the user will be manually created using Keycloak admin API for simplicity. -The first step involves getting an admin token from Keycloak using the Keycloak admin username and password. +The first step involves getting an admin token from Keycloak using the admin username and password. +This token allows the admin to perform operations on Keycloak such as creating a new user. Running the provided command should return the admin access token. ```bash @@ -196,7 +197,7 @@ For in-depth user management, please consult the official Keycloaak administrati ### 4. Grant the user permission to the wallet Once the user and wallet have been successfully created, the permissions can be created giving the user access to the wallet. -This action is accomplished by invoking the `POST /wallets/{walletId}/uma-permissions` endpoint on the agent. +This can be done by invoking the `POST /wallets/{walletId}/uma-permissions` endpoint on the agent. ```bash curl -X 'POST' \ @@ -238,8 +239,8 @@ curl -X 'POST' \ -d "password=1234" ``` -Note the `client_id` is `admin-cli`. This should be the actual `client_id` of the frontend application that log the user in. -For this tutorial, it is absolutely OK. +Special attention on the `client_id`, this should be the actual `client_id` of the frontend application that log the user in. +For this tutorial, it is absolutely OK to use `admin-cli`. Example token response (some fields omitted for readability) @@ -274,7 +275,8 @@ Example token response (some fields omitted for readability) } ``` -Inspecting the token of the response using this [JWT debugger](https://jwt.io/), there should be a new claims in the JWT payload called `authorization`. +Inspecting the token of the response using this [JWT debugger](https://jwt.io/), +there should be a new claim in the JWT payload called `authorization`. Example RPT payload (some fields omitted for readability) @@ -285,7 +287,7 @@ Example RPT payload (some fields omitted for readability) "permissions": [ { "rsid": "99734c87-5c9d-4697-b5fd-dea4e9590ba7", - "rsname": "Resource Name" + "rsname": "" }, ... ] @@ -311,7 +313,7 @@ Any interactions that the tenant performs should be scoped to only this wallet. ### A note on RPT -In this tutorial, there is an additional step for the tenant to request the RPT from the access token before granting access to the wallet. +In this tutorial, there is an additional step for the tenant to request the RPT from the access token. This aligns with the standard UMA interaction, where the handling of RPT typically occurs on the client side. To streamline the development experience, the agent has a feature that allows developers to bypass this process. By setting the variable `KEYCLOAK_UMA_AUTO_UPGRADE_RPT=true`, tenants can utilize the access token diff --git a/docs/docusaurus/sidebars.js b/docs/docusaurus/sidebars.js index 3ee3e28bef..670e4e26c4 100644 --- a/docs/docusaurus/sidebars.js +++ b/docs/docusaurus/sidebars.js @@ -94,6 +94,7 @@ const sidebars = { 'multitenancy/tenant-onboarding', 'multitenancy/tenant-onboarding-ext-iam', 'multitenancy/tenant-onboarding-self-service', + 'multitenancy/tenant-migration', ] } ] From 43e5dd383b50fa6130535d9ed031502e4cdb0712 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 12:59:59 +0700 Subject: [PATCH 04/47] docs: self-service doc wip Signed-off-by: Pat Losoponkul --- .../multitenancy/tenant-onboarding-ext-iam.md | 7 +- .../tenant-onboarding-self-service.md | 103 ++++++++++++++++++ 2 files changed, 106 insertions(+), 4 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index 4a76b96cc2..cfed477712 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -37,14 +37,13 @@ In tenant management with external IAM, there are 2 roles: ## Overview -This tutorial illustrates the process of creating a tenant in Keycloak and subsequently -provisioning a wallet resource for the new tenant by the administrator. +This tutorial illustrates the process of provisioning a wallet resource for the new tenant and subsequently creating a tenant in Keycloak. The administrator can then create a UMA permission for the wallet giving access to the tenant. When setting up UMA permissions on the agent, the wallet resource along with the UMA policy and permission are created on Keycloak according to a predefined convention. -For greater flexibility in defining custom policy and permission models, -administrators can also manually create these UMA resources (resource, policy, permission) directly on Keycloak +For flexibility in defining custom policy and permission models, +administrators can manually create these UMA resources (resource, policy, permission) directly on Keycloak using a set of UMA endpoints called [Protection API](https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_protection_api). However, using Protection API to manage permissions is out of scope for this tutorial. diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 086bc93869..6eba8bae5e 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -1 +1,104 @@ # Tenant Onboarding Self-Service + +In the [Tenant Onboarding with External IAM](./tenant-onboarding-ext-iam.md) tutorial, +we learned how Keycloak helps with user access and how it works together with the agent. +To set things up, the admin has to provision the required resources. +However, relying on the admin for onboarding operation can be restrictive for some use cases. +For example, some tenants might want to onboard on a self-service agent instance without admin intervention. + +By leveraging Keycloak for a self-service agent instance, +users can self-register or link to other Identity Providers (IDPs) to register an account. +Once the account is registered, users can use it to set up their own wallet. +This tutorial will dive into the steps to facilitate this scenario where administrator intervention is not needed. + +## Roles + +In sef-service tenant management with external IAM, there is only 1 role: + +1. Tenant + +## Prerequisites + +1. Keycloak up and running +2. Keycloak is configured as follows + 1. A realm called `my-realm` is created + 2. A client called `prism-agent` under `my-realm` with __authorization__ feature is created. (See [create client instruction](https://www.keycloak.org/docs/latest/authorization_services/index.html#_resource_server_create_client)) + 3. Make sure the `prism-agent` client has __direct access grants__ enabled to simplify login process for this tutorial + 4. Make sure to [allow user self-registration](https://www.keycloak.org/docs/latest/server_admin/index.html#con-user-registration_server_administration_guide). +3. PRISM Agent up and running +4. PRISM Agent is configured with the following environment variables: + 1. `ADMIN_TOKEN=my-admin-token` + 2. `DEFAULT_WALLET_ENABLED=false` + 3. `KEYCLOAK_ENABLED=true` + 4. `KEYCLOAK_URL=http://localhost:9980` (replace with appropriate value) + 5. `KEYCLOAK_REALM=my-realm` + 6. `KEYCLOAK_CLIENT_ID=prism-agent` + 7. `KEYCLOAK_CLIENT_SECRET=` (replace with appropriate value) + 8. `KEYCLOAK_UMA_AUTO_UPGRADE_RPT=true` + +## Overview + +This tutorial demonstrate the process of user self-registration on Keycloak. +Then the users can log in to Keycloak to obtain a token. +When this token is used on the agent for the wallet creation, the agent recognizes it belonging to a tenant and +automatically associate the tenant's permission with the created wallet. + +## Endpoints + +### Agent endpoints +| Endpoint | Description | Role | +|--------------------------------------------|--------------------------------------|---------------| +| `GET /wallets` | List the wallets on PRISM Agent | Tenant | +| `POST /wallets` | Create a new wallet on PRISM Agent | Tenant | +| `POST /wallets/{walletId}/uma-permissions` | Create a uma-permission for a wallet | Tenant | +| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | + +### Keycloak endpoints +| Endpoint | Description | Role | +|-----------------------------------------------------|-------------------------------|-----------------------| +| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Administrator, Tenant | + +## Tenant interactions + +### 1. Self-register account on Keycloak + +Start by registering a new account on Keycloak, accessible through its login page. +Usually this should be available at `http://localhost:9980/realms/my-realm/account/`. + +For detailed instruction on how to register a new user, +please refer to [registering a new user](https://www.keycloak.org/docs/latest/server_admin/index.html#proc-registering-new-user_server_administration_guide) section on the official documentation. + +### 2. Obtain access token from Keycloak + +Once a new account is registered, Keycloak should recognize it, allowing the user to log in and obtain the access token. + +Run this command to log in and get the access token + +```bash +curl -X 'POST' \ + 'http://localhost:9980/realms/my-realm/protocol/openid-connect/token' \ + -d "grant_type=password" \ + -d "client_id=admin-cli" \ + -d "username=alice" \ + -d "password=1234" +``` + +Make sure to use the correct username and password of the user. +Special attention on the `client_id`, this should be the actual `client_id` of the frontend application that log the user in. +For this tutorial, it is absolutely OK to use `admin-cli`. + +Example token response (some fields omitted for readability) + +```json +{ + "access_token": "eyJhbGciOi...7ocDHofUDQ", + "refresh_token": "eyJhbGciOi...otsEEi4eQA", + ... +} +``` + +### 3. Check the existing wallets + +### 4. Create a new wallet + +### 5. Perform a simple action to verify access to PRISM Agent From f0c9437a814a3d612ee9136b192bbb0c6d593540 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 13:53:10 +0700 Subject: [PATCH 05/47] docs: self-service onboarding docs Signed-off-by: Pat Losoponkul --- .../multitenancy/tenant-onboarding-ext-iam.md | 24 +++---- .../tenant-onboarding-self-service.md | 70 ++++++++++++++++++- 2 files changed, 80 insertions(+), 14 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index cfed477712..3c6e7d1510 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -2,13 +2,12 @@ In the [Tenant Onboarding](./tenant-onboarding.md) tutorial, we explored the basic IAM functionality provided by the agent out of the box. Although it is usable and straightforward, -there are robust and more powerful tools available for handling identity and access management. +there are more featureful tools available for handling identity and access management. The agent has the capability to seamlessly connect with Keycloak as an external IAM system -allowing the application built on top to utilize available OIDC flow on Keycloak. -The token issued by Keycloak can be used for wallet authorization by the PRISM Agent. +allowing the application built on top to utilize capabilities that comes with Keycloak. -The PRISM Agent leverages standard protocols like OIDC and UMA for authentication and resource access management. -The user's identity is established through the ID token, and resource permissions can be queried using the RPT (requesting party token). +The PRISM Agent leverages standard protocols like OIDC and UMA for authentication and access management. +The user's identity is established through the ID token, and wallet permissions can be queried using the RPT (requesting party token). ## Roles @@ -50,8 +49,8 @@ However, using Protection API to manage permissions is out of scope for this tut Once the registration is successful, the tenant can obtain an ID token from Keycloak using any available OIDC flow, such as the direct access grants (username & password). This ID token typically contains user claims such as username and subject ID. The tenant can use Keycloak's token endpoint to convert this token to an RPT (requesting party token), -which is another token containing permissions on permitted resources. -The tenant can access the multi-tenant agent by providing the RPT in the authorization header. +which is another token containing permissions information. +The tenant can access the multi-tenant agent by providing the RPT in the `Authorization` header. ## Endpoints @@ -132,7 +131,7 @@ Keycloak offers great flexibility, allowing users to self-register, connect to IDP, or be manually created by an administrator. For this tutorial, the user will be manually created using Keycloak admin API for simplicity. -The first step involves getting an admin token from Keycloak using the admin username and password. +The first step is to get an admin token from Keycloak using the username and password. This token allows the admin to perform operations on Keycloak such as creating a new user. Running the provided command should return the admin access token. @@ -157,7 +156,7 @@ Example token response (some fields omitted for readability) } ``` -After the admin has obtained an `access_token` from Keycloak, a new user can be created by running this command. +After the admin get the `access_token` from Keycloak, a new user can be created by running this command. ```bash curl -X 'POST' \ @@ -274,8 +273,7 @@ Example token response (some fields omitted for readability) } ``` -Inspecting the token of the response using this [JWT debugger](https://jwt.io/), -there should be a new claim in the JWT payload called `authorization`. +Inspecting the token of the response, there should be a new claim in the JWT payload called `authorization`. Example RPT payload (some fields omitted for readability) @@ -302,8 +300,8 @@ try listing the DIDs in the wallet using RPT in the `Authorization` header. ```bash curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/dids' \ - --header "Authorization: Bearer eyJhbGciOi...e7H6W8RUvA" \ - --header 'Accept: application/json' + -H "Authorization: Bearer eyJhbGciOi...e7H6W8RUvA" \ + -H 'Accept: application/json' ``` The result should show 200 status with an empty list. diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 6eba8bae5e..90fc243586 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -83,7 +83,7 @@ curl -X 'POST' \ -d "password=1234" ``` -Make sure to use the correct username and password of the user. +Make sure to use the correct username and password. Special attention on the `client_id`, this should be the actual `client_id` of the frontend application that log the user in. For this tutorial, it is absolutely OK to use `admin-cli`. @@ -99,6 +99,74 @@ Example token response (some fields omitted for readability) ### 3. Check the existing wallets +Right after the account is registered, there should be no permission associated to it. +Listing wallets on it should return empty results. + +```bash +curl -X 'GET' \ + 'http://localhost:8080/prism-agent/wallets' \ + -H "Authorization: Bearer eyJhbGciOi...7ocDHofUDQ" \ + -H 'Accept: application/json' +``` + +Make sure to use the correct `access_token` in the `Authorization` header from the previous command. + +Response Example: + +```json +{ + "self": "/wallets", + "kind": "WalletPage", + "pageOf": "/wallets", + "contents": [] +} +``` + ### 4. Create a new wallet +The wallet can be created using a `POST /wallets` endpoint. +This wallet is going to act as a container for the tenant's assets (DIDs, VCs, Connections, etc.). +The wallet seed may be provided during the wallet creation or omitted to let the Agent generate one randomly. + +If the user already have the wallet associated, the wallet creation will fail as multiple wallets per tenant is not yet allowed. + +```bash +curl -X 'POST' \ + 'http://localhost:8080/prism-agent/wallets' \ + -H "Authorization: Bearer eyJhbGciOi...7ocDHofUDQ" \ + -H 'Accept: application/json' + -H 'Content-Type: application/json' \ + -d '{ + "seed": "c9994785ce6d548134020f610b76102ca1075d3bb672a75ec8c9a27a7b8607e3b9b384e43b77bb08f8d5159651ae38b98573f7ecc79f2d7e1f1cc371ce60cf8a", + "name": "my-wallet" + }' +``` + +Response Example: + +```json +{ + "id": "99734c87-5c9d-4697-b5fd-dea4e9590ba7", + "name": "my-wallet", + "createdAt": "2023-01-01T00:00:00Z", + "updatedAt": "2023-01-01T00:00:00Z" +} +``` + +In this step, the agent create both wallet resource as well as UMA permission on Keycloak assigning the new wallet to the user who created it. + ### 5. Perform a simple action to verify access to PRISM Agent + +Without further operation, the wallet should be availble for the tenant to use. +To prove that the tenant can access the wallet, +try listing the DIDs in the wallet using RPT in the `Authorization` header. + +```bash +curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/dids' \ + -H "Authorization: Bearer eyJhbGciOi...7ocDHofUDQ" \ + -H 'Accept: application/json' +``` + +The result should show 200 status with an empty list. +This means that the wallet has been created and it does not contain any DIDs. +Any interactions that the tenant performs should be scoped to only this wallet. From fb21e914ad1b5add2d131aff9f0c1dff0cdb86f0 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 15:35:29 +0700 Subject: [PATCH 06/47] docs: keycloak jwt migration tutorial Signed-off-by: Pat Losoponkul --- .../multitenancy/tenant-migration.md | 175 ++++++++++++++++++ .../multitenancy/tenant-onboarding-ext-iam.md | 2 +- .../tenant-onboarding-self-service.md | 17 +- 3 files changed, 184 insertions(+), 10 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index e69de29bb2..8e7ab0a67a 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -0,0 +1,175 @@ +# Migration from `apikey` to `JWT` authentication + +PRISM Agent authentication supports enabling multiple authentication methods simultaneously. +This means the user can seamlessly use any available credentials including `apikey` or `JWT` to access the wallet. +The agent's UMA permission resource also exposes self-service permission endpoint, allowing users to manage the permissions for their wallets. +This facilitates a pattern where users can transition from `apikey` to `JWT` authentication without requiring admin intervention. + +## Roles + +In the migration process from `apikey` to `JWT`, there is only 1 role: + +1. Tenant + +## Prerequisites + +1. Keycloak up and running +2. Keycloak is configured the same as in [Tenant Onboarding Self-Service](./tenant-onboarding-self-service.md) +3. PRISM Agent up and running +4. PRISM Agent is configured the same as in [Tenant Onboarding Self-Service](./tenant-onboarding-self-service.md) +5. The user has access to the wallet using `apikey`. (See [Tenant Onboarding](./tenant-onboarding.md)) +6. The user has account registered on Keycloak + +## Overview + +This tutorial outlines the steps to transition from `apikey` to `JWT` authentication. +Initially, users have wallet access through the `apikey` method. +To migrate to `JWT` authentication, users can create a new UMA permission for their wallet and grant permission to their own Keycloak account. + +## Endpoints + +### Agent endpoints +| Endpoint | Description | Role | +|--------------------------------------------|--------------------------------------|--------| +| `GET /wallets` | List the wallets on PRISM Agent | Tenant | +| `POST /wallets` | Create a new wallet on PRISM Agent | Tenant | +| `POST /wallets/{walletId}/uma-permissions` | Create a uma-permission for a wallet | Tenant | +| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | + +### Keycloak endpoints +| Endpoint | Description | Role | +|-----------------------------------------------------|-----------------------|--------| +| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Tenant | + +## Tenant interactions + +### 1. Check the existing wallets using `apikey` + +This tutorial assumes the tenant has access to the wallet using `apikey`. +Before granting more permission to the wallet, the `walletId` must be identified. +This can be done by listing the wallets using `apikey`. + +```bash +curl -X 'GET' \ + 'http://localhost:8080/prism-agent/wallets' \ + -H 'accept: application/json' \ + -H "apikey: my-tenant-token" \ +``` + +Make sure to use the correct `apikey` from the pre-requisite. + +Response Example: + +```json +{ + "self": "/wallets", + "kind": "WalletPage", + "pageOf": "/wallets", + "contents": [ + { + "id": "99734c87-5c9d-4697-b5fd-dea4e9590ba7", + "name": "my-wallet", + "createdAt": "2023-01-01T00:00:00Z", + "updatedAt": "2023-01-01T00:00:00Z" + } + ] +} +``` + +### 2. Get the access token on keycloak + +Run this command to log in and get the access token + +```bash +curl -X 'POST' \ + 'http://localhost:9980/realms/my-realm/protocol/openid-connect/token' \ + -d "grant_type=password" \ + -d "client_id=admin-cli" \ + -d "username=alice" \ + -d "password=1234" +``` + +Make sure to use the correct username and password. +Special attention on the `client_id`, this should be the actual `client_id` of the frontend application that log the user in. +For this tutorial, it is absolutely OK to use `admin-cli`. + +Example token response (some fields omitted for readability) + +```json +{ + "access_token": "eyJhbGciOi...7ocDHofUDQ", + "refresh_token": "eyJhbGciOi...otsEEi4eQA", + ... +} +``` + +### 3. Extract the subject ID from JWT + +When creating a UMA permission, it is important to provide the subject ID which the permission will be granted to. +To get the subject ID of the tenant, one can inspect the JWT payload `sub` claim. + +Run this command to extract the `sub` claim of the token from pervious step + +```bash +echo 'eyJhbGciOi...7ocDHofUDQ' | cut --delimiter='.' --fields=2 | base64 --decode | jq -r '.sub' +``` + +Example result + +```log +4a5c6ac9-12f5-4d1e-b8f2-667525c083fd +``` + +### 4. Grant the user permission to the wallet + +The addition UMA permission can be added to the current wallet giving Keycloak user an access. +This can be done by invoking the `POST /wallets/{walletId}/uma-permissions` endpoint on the agent. + +```bash +curl -X 'POST' \ + 'http://localhost:8080/prism-agent/wallets/99734c87-5c9d-4697-b5fd-dea4e9590ba7/uma-permissions' \ + -H 'accept: */*' \ + -H "apikey: my-tenant-token" \ + -H 'Content-Type: application/json' \ + -d '{ + "subject": "205e04b7-0158-41b0-89c3-f91c3a09f89b", + }' +``` + +Make sure to use the correct `subject` for the user and the correct `walletId` from the step earlier. + +The response should return status `200 OK` in case of successful permission creation. + +### 5. Perform a simple action to verify access to PRISM Agent + +After sucessful UMA permission creation, the user should be able to use `JWT` token for authentitcation to the wallet. +Simply list the wallet using a new `Authorization` header, the listed wallets should contain the wallet with the same ID in step 1. + +```bash +curl -X 'GET' \ + 'http://localhost:8080/prism-agent/wallets' \ + -H 'accept: application/json' \ + -H "Authorization: Bearer eyJhbGciOi...7ocDHofUDQ" \ +``` + +Make sure to use the correct `JWT` from step 2. + +Response Example: + +```json +{ + "self": "/wallets", + "kind": "WalletPage", + "pageOf": "/wallets", + "contents": [ + { + "id": "99734c87-5c9d-4697-b5fd-dea4e9590ba7", + "name": "my-wallet", + "createdAt": "2023-01-01T00:00:00Z", + "updatedAt": "2023-01-01T00:00:00Z" + } + ] +} +``` + +This indicates that the user should be able to perform any wallet interaction with the `JWT` and `apikey` interchangeably. diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index 3c6e7d1510..b0d26e6961 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -312,6 +312,6 @@ Any interactions that the tenant performs should be scoped to only this wallet. In this tutorial, there is an additional step for the tenant to request the RPT from the access token. This aligns with the standard UMA interaction, where the handling of RPT typically occurs on the client side. -To streamline the development experience, the agent has a feature that allows developers to bypass this process. +To simplify the experience, the agent has a feature that allows user to bypass this process. By setting the variable `KEYCLOAK_UMA_AUTO_UPGRADE_RPT=true`, tenants can utilize the access token obtained in step 1 directly in the `Authorization` header, eliminating the need for additional RPT request step. diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 90fc243586..2d44e9ba81 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -46,17 +46,16 @@ automatically associate the tenant's permission with the created wallet. ## Endpoints ### Agent endpoints -| Endpoint | Description | Role | -|--------------------------------------------|--------------------------------------|---------------| -| `GET /wallets` | List the wallets on PRISM Agent | Tenant | -| `POST /wallets` | Create a new wallet on PRISM Agent | Tenant | -| `POST /wallets/{walletId}/uma-permissions` | Create a uma-permission for a wallet | Tenant | -| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | +| Endpoint | Description | Role | +|---------------------------|------------------------------------|--------| +| `GET /wallets` | List the wallets on PRISM Agent | Tenant | +| `POST /wallets` | Create a new wallet on PRISM Agent | Tenant | +| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | ### Keycloak endpoints -| Endpoint | Description | Role | -|-----------------------------------------------------|-------------------------------|-----------------------| -| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Administrator, Tenant | +| Endpoint | Description | Role | +|-----------------------------------------------------|-----------------------|--------| +| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Tenant | ## Tenant interactions From 3b341729794fbad0d0e5b640e7ca54aa1ea3a648 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 16:04:26 +0700 Subject: [PATCH 07/47] docs: fix script to make tut work Signed-off-by: Pat Losoponkul --- docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index b0d26e6961..19bb993240 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -200,11 +200,12 @@ This can be done by invoking the `POST /wallets/{walletId}/uma-permissions` endp ```bash curl -X 'POST' \ 'http://localhost:8080/prism-agent/wallets/99734c87-5c9d-4697-b5fd-dea4e9590ba7/uma-permissions' \ + -v \ -H 'accept: */*' \ -H 'x-admin-api-key: my-admin-token' \ -H 'Content-Type: application/json' \ -d '{ - "subject": "205e04b7-0158-41b0-89c3-f91c3a09f89b", + "subject": "205e04b7-0158-41b0-89c3-f91c3a09f89b" }' ``` @@ -295,7 +296,7 @@ Example RPT payload (some fields omitted for readability) ### 3. Perform a simple action to verify access to PRISM Agent -To prove that the tenant can access the wallet, +To prove that the tenant can access the wallet using RPT, try listing the DIDs in the wallet using RPT in the `Authorization` header. ```bash @@ -304,6 +305,8 @@ curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/d -H 'Accept: application/json' ``` +Make sure to replace the token with RPT from previous step. + The result should show 200 status with an empty list. This means that the wallet has been created and it does not contain any DIDs. Any interactions that the tenant performs should be scoped to only this wallet. From 8b24d1800ded6365b082972021633d0c6fff6479 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 16:11:01 +0700 Subject: [PATCH 08/47] docs: clean up Signed-off-by: Pat Losoponkul --- docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md | 2 +- .../multitenancy/tenant-onboarding-self-service.md | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index 19bb993240..d42ed9ef32 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -301,7 +301,7 @@ try listing the DIDs in the wallet using RPT in the `Authorization` header. ```bash curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/dids' \ - -H "Authorization: Bearer eyJhbGciOi...e7H6W8RUvA" \ + -H 'Authorization: Bearer eyJhbGciOi...e7H6W8RUvA' \ -H 'Accept: application/json' ``` diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 2d44e9ba81..5145f99aa3 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -104,7 +104,7 @@ Listing wallets on it should return empty results. ```bash curl -X 'GET' \ 'http://localhost:8080/prism-agent/wallets' \ - -H "Authorization: Bearer eyJhbGciOi...7ocDHofUDQ" \ + -H 'Authorization: Bearer eyJhbGciOi...7ocDHofUDQ' \ -H 'Accept: application/json' ``` @@ -132,8 +132,8 @@ If the user already have the wallet associated, the wallet creation will fail as ```bash curl -X 'POST' \ 'http://localhost:8080/prism-agent/wallets' \ - -H "Authorization: Bearer eyJhbGciOi...7ocDHofUDQ" \ - -H 'Accept: application/json' + -H 'Authorization: Bearer eyJhbGciOi...7ocDHofUDQ' \ + -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "seed": "c9994785ce6d548134020f610b76102ca1075d3bb672a75ec8c9a27a7b8607e3b9b384e43b77bb08f8d5159651ae38b98573f7ecc79f2d7e1f1cc371ce60cf8a", @@ -162,7 +162,7 @@ try listing the DIDs in the wallet using RPT in the `Authorization` header. ```bash curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/dids' \ - -H "Authorization: Bearer eyJhbGciOi...7ocDHofUDQ" \ + -H 'Authorization: Bearer eyJhbGciOi...7ocDHofUDQ' \ -H 'Accept: application/json' ``` From 5ac5558259963a01bf48da81e03ae487510b0ef7 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 16:19:58 +0700 Subject: [PATCH 09/47] docs: fix typo in script Signed-off-by: Pat Losoponkul --- docs/docusaurus/multitenancy/tenant-migration.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 8e7ab0a67a..dcce88b1dc 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -53,7 +53,7 @@ This can be done by listing the wallets using `apikey`. curl -X 'GET' \ 'http://localhost:8080/prism-agent/wallets' \ -H 'accept: application/json' \ - -H "apikey: my-tenant-token" \ + -H "apikey: my-tenant-token" ``` Make sure to use the correct `apikey` from the pre-requisite. @@ -128,11 +128,12 @@ This can be done by invoking the `POST /wallets/{walletId}/uma-permissions` endp ```bash curl -X 'POST' \ 'http://localhost:8080/prism-agent/wallets/99734c87-5c9d-4697-b5fd-dea4e9590ba7/uma-permissions' \ + -v \ -H 'accept: */*' \ -H "apikey: my-tenant-token" \ -H 'Content-Type: application/json' \ -d '{ - "subject": "205e04b7-0158-41b0-89c3-f91c3a09f89b", + "subject": "205e04b7-0158-41b0-89c3-f91c3a09f89b" }' ``` @@ -149,7 +150,7 @@ Simply list the wallet using a new `Authorization` header, the listed wallets sh curl -X 'GET' \ 'http://localhost:8080/prism-agent/wallets' \ -H 'accept: application/json' \ - -H "Authorization: Bearer eyJhbGciOi...7ocDHofUDQ" \ + -H 'Authorization: Bearer eyJhbGciOi...7ocDHofUDQ' ``` Make sure to use the correct `JWT` from step 2. From d32a9a24a55c5f6f8a0f34904323ffe1ece519bf Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 16:22:50 +0700 Subject: [PATCH 10/47] docs: no ci commit [skip ci] Signed-off-by: Pat Losoponkul From cbdfa4ddf6cddd37d8f326e815281175f5c0c9e3 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 16:28:34 +0700 Subject: [PATCH 11/47] docs: no ci commit [skip ci] Signed-off-by: Pat Losoponkul From 84cc78bbe1176c0e7df387dd363665c7d316823e Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 16:48:23 +0700 Subject: [PATCH 12/47] docs: correct http method Signed-off-by: Pat Losoponkul --- docs/docusaurus/multitenancy/tenant-migration.md | 4 ++-- docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md | 2 +- .../docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index dcce88b1dc..b8cd2b2cc3 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -1,6 +1,6 @@ # Migration from `apikey` to `JWT` authentication -PRISM Agent authentication supports enabling multiple authentication methods simultaneously. +PRISM Agent authentication supports multiple authentication methods simultaneously. This means the user can seamlessly use any available credentials including `apikey` or `JWT` to access the wallet. The agent's UMA permission resource also exposes self-service permission endpoint, allowing users to manage the permissions for their wallets. This facilitates a pattern where users can transition from `apikey` to `JWT` authentication without requiring admin intervention. @@ -39,7 +39,7 @@ To migrate to `JWT` authentication, users can create a new UMA permission for th ### Keycloak endpoints | Endpoint | Description | Role | |-----------------------------------------------------|-----------------------|--------| -| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Tenant | +| `POST /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Tenant | ## Tenant interactions diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index d42ed9ef32..a93627d653 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -66,7 +66,7 @@ The tenant can access the multi-tenant agent by providing the RPT in the `Author | Endpoint | Description | Role | |-----------------------------------------------------|-------------------------------|-----------------------| | `POST /admin/realms/{realm}/users` | Create a new user on Keycloak | Administrator | -| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Administrator, Tenant | +| `POST /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Administrator, Tenant | ## Administrator interactions diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 5145f99aa3..be3c25e9b8 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -55,7 +55,7 @@ automatically associate the tenant's permission with the created wallet. ### Keycloak endpoints | Endpoint | Description | Role | |-----------------------------------------------------|-----------------------|--------| -| `GET /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Tenant | +| `POST /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Tenant | ## Tenant interactions From f17fa6a7ca8e53e375b179da442eaa45c66583db Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 17:18:12 +0700 Subject: [PATCH 13/47] docs: add keycloak convention Signed-off-by: Pat Losoponkul --- README.md | 2 +- docs/docusaurus/index.md | 1 + docs/docusaurus/multitenancy/tenant-migration.md | 4 ++-- docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md | 6 +++--- .../multitenancy/tenant-onboarding-self-service.md | 4 ++-- 5 files changed, 9 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 07420f4b1e..7c7ba6837b 100644 --- a/README.md +++ b/README.md @@ -34,7 +34,7 @@ As a result, you can concentrate on crafting self-sovereign identity solutions u * HTTP events notification * Cardano as a distributed ledger * Secrets management with Hashicorp vault -* Multi-tenancy (coming soon) +* Multi-tenancy ## Example use cases diff --git a/docs/docusaurus/index.md b/docs/docusaurus/index.md index db27f36df4..d9f8037f79 100644 --- a/docs/docusaurus/index.md +++ b/docs/docusaurus/index.md @@ -9,6 +9,7 @@ Whether you are new to [self-sovereign identity (SSI)](/docs/concepts/glossary#s Throughout all code examples in tutorials, the following conventions are in use: +* Issuer Keycloak is hosted at `http://localhost:9980/` * Issuer Agent is hosted at `http://localhost:8080/prism-agent/` * Holder Agent is hosted at `http://localhost:8090/prism-agent/` * Verifier Agent is hosted at `http://localhost:8100/prism-agent/` diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index b8cd2b2cc3..0ae3c8dcd8 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -37,8 +37,8 @@ To migrate to `JWT` authentication, users can create a new UMA permission for th | `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | ### Keycloak endpoints -| Endpoint | Description | Role | -|-----------------------------------------------------|-----------------------|--------| +| Endpoint | Description | Role | +|------------------------------------------------------|-----------------------|--------| | `POST /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Tenant | ## Tenant interactions diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index a93627d653..7b511d68e9 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -63,9 +63,9 @@ The tenant can access the multi-tenant agent by providing the RPT in the `Author | `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | ### Keycloak endpoints -| Endpoint | Description | Role | -|-----------------------------------------------------|-------------------------------|-----------------------| -| `POST /admin/realms/{realm}/users` | Create a new user on Keycloak | Administrator | +| Endpoint | Description | Role | +|------------------------------------------------------|-------------------------------|-----------------------| +| `POST /admin/realms/{realm}/users` | Create a new user on Keycloak | Administrator | | `POST /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Administrator, Tenant | ## Administrator interactions diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index be3c25e9b8..eaf17b5433 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -53,8 +53,8 @@ automatically associate the tenant's permission with the created wallet. | `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | ### Keycloak endpoints -| Endpoint | Description | Role | -|-----------------------------------------------------|-----------------------|--------| +| Endpoint | Description | Role | +|------------------------------------------------------|-----------------------|--------| | `POST /realms/{realm}/protocol/openid-connect/token` | Issue a new JWT token | Tenant | ## Tenant interactions From a078a069834889c67711a486b1b01af491575ba6 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Mon, 20 Nov 2023 18:31:40 +0700 Subject: [PATCH 14/47] docs: link tutorials to glossary Signed-off-by: Pat Losoponkul --- .../multitenancy/tenant-onboarding-ext-iam.md | 14 +++++++------- .../multitenancy/tenant-onboarding-self-service.md | 8 ++++---- docs/docusaurus/multitenancy/tenant-onboarding.md | 4 ++-- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index 7b511d68e9..dc3cbad1ca 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -1,20 +1,20 @@ # Tenant Onboarding with External IAM In the [Tenant Onboarding](./tenant-onboarding.md) tutorial, we explored the basic -IAM functionality provided by the agent out of the box. Although it is usable and straightforward, +[IAM](/docs/concepts/glossary#iam) functionality provided by the agent out of the box. Although it is usable and straightforward, there are more featureful tools available for handling identity and access management. -The agent has the capability to seamlessly connect with Keycloak as an external IAM system +The agent has the capability to seamlessly connect with [Keycloak](/docs/concepts/glossary#keycloak-service) as an external IAM system allowing the application built on top to utilize capabilities that comes with Keycloak. -The PRISM Agent leverages standard protocols like OIDC and UMA for authentication and access management. -The user's identity is established through the ID token, and wallet permissions can be queried using the RPT (requesting party token). +The PRISM Agent leverages standard protocols like [OIDC](/docs/concepts/glossary#oidc) and [UMA](/docs/concepts/glossary#uma) for authentication and access management. +The user's identity is established through the ID token, and wallet permissions can be queried using the [RPT (requesting party token)](/docs/concepts/glossary#rpt). ## Roles In tenant management with external IAM, there are 2 roles: -1. System administrator -2. Tenant +1. [Administrator](/docs/concepts/glossary#administrator) +2. [Tenant](/docs/concepts/glossary#tenant) ## Prerequisites @@ -43,7 +43,7 @@ When setting up UMA permissions on the agent, the wallet resource along with the are created on Keycloak according to a predefined convention. For flexibility in defining custom policy and permission models, administrators can manually create these UMA resources (resource, policy, permission) directly on Keycloak -using a set of UMA endpoints called [Protection API](https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_protection_api). +using a set of UMA endpoints called [Protection API](/docs/concepts/glossary#protection-api) (see [Keycloak Protection API](https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_protection_api)). However, using Protection API to manage permissions is out of scope for this tutorial. Once the registration is successful, the tenant can obtain an ID token from Keycloak using any available OIDC flow, diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index eaf17b5433..5115402dca 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -1,21 +1,21 @@ # Tenant Onboarding Self-Service In the [Tenant Onboarding with External IAM](./tenant-onboarding-ext-iam.md) tutorial, -we learned how Keycloak helps with user access and how it works together with the agent. +we learned how [Keycloak](/docs/concepts/glossary#keycloak-service) helps with user access and how it works together with the agent. To set things up, the admin has to provision the required resources. However, relying on the admin for onboarding operation can be restrictive for some use cases. For example, some tenants might want to onboard on a self-service agent instance without admin intervention. By leveraging Keycloak for a self-service agent instance, -users can self-register or link to other Identity Providers (IDPs) to register an account. +users can self-register or link to other [Identity Providers (IDPs)](/docs/concepts/glossary#idp) to register an account. Once the account is registered, users can use it to set up their own wallet. -This tutorial will dive into the steps to facilitate this scenario where administrator intervention is not needed. +This tutorial will dive into the steps to facilitate this scenario where [administrator](/docs/concepts/glossary#administrator) intervention is not needed. ## Roles In sef-service tenant management with external IAM, there is only 1 role: -1. Tenant +1. [Tenant](/docs/concepts/glossary#tenant) ## Prerequisites diff --git a/docs/docusaurus/multitenancy/tenant-onboarding.md b/docs/docusaurus/multitenancy/tenant-onboarding.md index f1695560b1..0c085cdf43 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding.md @@ -9,8 +9,8 @@ while tenants are users who engage in standard SSI interactions with the PRISM A In tenant management, there are 2 roles: -1. System administrator -2. Tenant +1. [Administrator](/docs/concepts/glossary#administrator) +2. [Tenant](/docs/concepts/glossary#tenant) ## Prerequisites From 02cc1f726db917883754a3d7695745a6e97e3a36 Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Mon, 20 Nov 2023 11:24:46 -0600 Subject: [PATCH 15/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 5115402dca..2bc31f65be 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -168,4 +168,4 @@ curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/d The result should show 200 status with an empty list. This means that the wallet has been created and it does not contain any DIDs. -Any interactions that the tenant performs should be scoped to only this wallet. +The tenant should only perform interactions within the scope of this wallet. From aa2194380a011a75969acb6da47ce7c851522f90 Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Mon, 20 Nov 2023 11:25:05 -0600 Subject: [PATCH 16/47] Update docs/docusaurus/multitenancy/tenant-migration.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 0ae3c8dcd8..ef48c4c668 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -24,7 +24,7 @@ In the migration process from `apikey` to `JWT`, there is only 1 role: This tutorial outlines the steps to transition from `apikey` to `JWT` authentication. Initially, users have wallet access through the `apikey` method. -To migrate to `JWT` authentication, users can create a new UMA permission for their wallet and grant permission to their own Keycloak account. +To migrate to `JWT` authentication, users can create a new UMA permission for their wallet and grant permission to their Keycloak account. ## Endpoints From 8ee3d04711c363b45adfbb9d2bad32ba703d4be1 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Tue, 21 Nov 2023 01:12:34 +0700 Subject: [PATCH 17/47] docs: reference UMA in glossary Signed-off-by: Pat Losoponkul --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index ef48c4c668..e63c37cd7a 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -2,7 +2,7 @@ PRISM Agent authentication supports multiple authentication methods simultaneously. This means the user can seamlessly use any available credentials including `apikey` or `JWT` to access the wallet. -The agent's UMA permission resource also exposes self-service permission endpoint, allowing users to manage the permissions for their wallets. +The agent's [UMA](/docs/concepts/glossary#uma) permission resource also exposes self-service permission endpoint, allowing users to manage the permissions for their wallets. This facilitates a pattern where users can transition from `apikey` to `JWT` authentication without requiring admin intervention. ## Roles From e9d59ce995555f3f02927a03038b4ff4b7324fdb Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:13:26 +0700 Subject: [PATCH 18/47] Update docs/docusaurus/multitenancy/tenant-migration.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index e63c37cd7a..2b404fa963 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -90,7 +90,7 @@ curl -X 'POST' \ ``` Make sure to use the correct username and password. -Special attention on the `client_id`, this should be the actual `client_id` of the frontend application that log the user in. +Special attention on the `client_id`; this should be the actual `client_id` of the frontend application that logs the user in. For this tutorial, it is absolutely OK to use `admin-cli`. Example token response (some fields omitted for readability) From 354d0598662e7bc248c412ec780ecba8264e2608 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:13:55 +0700 Subject: [PATCH 19/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 2bc31f65be..94e5c609e3 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -167,5 +167,4 @@ curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/d ``` The result should show 200 status with an empty list. -This means that the wallet has been created and it does not contain any DIDs. The tenant should only perform interactions within the scope of this wallet. From 4d84dfa62ff6743d78ca3a29f58e70534f28c7f2 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:14:08 +0700 Subject: [PATCH 20/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 94e5c609e3..e4255aff60 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -166,5 +166,5 @@ curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/d -H 'Accept: application/json' ``` -The result should show 200 status with an empty list. +The wallet was successfully created, but it currently does not contain any DIDs - indicated by an empty list and a 200 status. The tenant should only perform interactions within the scope of this wallet. From 208ba3f348cb0b0a399d659e6b98d5255b70b019 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:14:32 +0700 Subject: [PATCH 21/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index e4255aff60..9a80b7545f 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -158,7 +158,6 @@ In this step, the agent create both wallet resource as well as UMA permission on Without further operation, the wallet should be availble for the tenant to use. To prove that the tenant can access the wallet, -try listing the DIDs in the wallet using RPT in the `Authorization` header. ```bash curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/dids' \ From 4bf45edfa80cef72b395ffbbb45ec156003e2ccc Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:14:58 +0700 Subject: [PATCH 22/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 9a80b7545f..16ec666ed5 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -39,7 +39,7 @@ In sef-service tenant management with external IAM, there is only 1 role: ## Overview This tutorial demonstrate the process of user self-registration on Keycloak. -Then the users can log in to Keycloak to obtain a token. +Then, the users can log in to Keycloak to obtain a token. When this token is used on the agent for the wallet creation, the agent recognizes it belonging to a tenant and automatically associate the tenant's permission with the created wallet. From 25dfc7ad9c68cd7026669f3b9d483d1d9a29ef2b Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:15:09 +0700 Subject: [PATCH 23/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 16ec666ed5..d618d05c79 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -40,7 +40,7 @@ In sef-service tenant management with external IAM, there is only 1 role: This tutorial demonstrate the process of user self-registration on Keycloak. Then, the users can log in to Keycloak to obtain a token. -When this token is used on the agent for the wallet creation, the agent recognizes it belonging to a tenant and +When the agent uses this token for the wallet creation, the agent recognizes it belongs to a tenant and automatically associates the tenant's permission with the created wallet. automatically associate the tenant's permission with the created wallet. ## Endpoints From 7f0844f3afcf40677df5bf85f9cf4e287129f7c1 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:15:21 +0700 Subject: [PATCH 24/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index d618d05c79..267f2f329a 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -41,7 +41,6 @@ In sef-service tenant management with external IAM, there is only 1 role: This tutorial demonstrate the process of user self-registration on Keycloak. Then, the users can log in to Keycloak to obtain a token. When the agent uses this token for the wallet creation, the agent recognizes it belongs to a tenant and automatically associates the tenant's permission with the created wallet. -automatically associate the tenant's permission with the created wallet. ## Endpoints From ef79aff1c1315718e2969da5410bba689566ce6d Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:15:34 +0700 Subject: [PATCH 25/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 267f2f329a..d76b278a6f 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -61,7 +61,7 @@ When the agent uses this token for the wallet creation, the agent recognizes it ### 1. Self-register account on Keycloak Start by registering a new account on Keycloak, accessible through its login page. -Usually this should be available at `http://localhost:9980/realms/my-realm/account/`. +Usually, this should be available at `http://localhost:9980/realms/my-realm/account/`. For detailed instruction on how to register a new user, please refer to [registering a new user](https://www.keycloak.org/docs/latest/server_admin/index.html#proc-registering-new-user_server_administration_guide) section on the official documentation. From c1b5944d59c8da61751b303fb606747bf07ab018 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:16:11 +0700 Subject: [PATCH 26/47] Update docs/docusaurus/multitenancy/tenant-migration.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 2b404fa963..797bc05cf1 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -91,7 +91,7 @@ curl -X 'POST' \ Make sure to use the correct username and password. Special attention on the `client_id`; this should be the actual `client_id` of the frontend application that logs the user in. -For this tutorial, it is absolutely OK to use `admin-cli`. +For this tutorial, it is OK to use `admin-cli.` Example token response (some fields omitted for readability) From 16e0a9370857ef4aa9007302cef834a250647a7c Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:16:23 +0700 Subject: [PATCH 27/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index d76b278a6f..906b58285e 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -70,7 +70,7 @@ please refer to [registering a new user](https://www.keycloak.org/docs/latest/se Once a new account is registered, Keycloak should recognize it, allowing the user to log in and obtain the access token. -Run this command to log in and get the access token +Run this command to log in and get the access token. ```bash curl -X 'POST' \ From a61a4fc0fd0033d724dd89cd90962d45a34162a8 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:16:35 +0700 Subject: [PATCH 28/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 906b58285e..4e6978bfe2 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -83,7 +83,7 @@ curl -X 'POST' \ Make sure to use the correct username and password. Special attention on the `client_id`, this should be the actual `client_id` of the frontend application that log the user in. -For this tutorial, it is absolutely OK to use `admin-cli`. +For this tutorial, it is OK to use `admin-cli`. Example token response (some fields omitted for readability) From c0a1abe01197202b4f17751aef84d76e60f96dce Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:16:51 +0700 Subject: [PATCH 29/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 4e6978bfe2..276a2f011c 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -97,7 +97,7 @@ Example token response (some fields omitted for readability) ### 3. Check the existing wallets -Right after the account is registered, there should be no permission associated to it. +Right after the account is registered, no permission should be associated with it. Listing wallets on it should return empty results. ```bash From 411bb4db6e1657a67994dbe0447edd0ee71fe820 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:17:04 +0700 Subject: [PATCH 30/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 276a2f011c..034a139e69 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -107,7 +107,7 @@ curl -X 'GET' \ -H 'Accept: application/json' ``` -Make sure to use the correct `access_token` in the `Authorization` header from the previous command. +Use the correct `access_token` in the previous command's Authorization header. Response Example: From 9272e2e9eee2e93e039c37eda4102d3a7a4c540e Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:17:13 +0700 Subject: [PATCH 31/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 034a139e69..a6e3f0695a 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -122,7 +122,7 @@ Response Example: ### 4. Create a new wallet -The wallet can be created using a `POST /wallets` endpoint. +Create a wallet using a `POST /wallets` endpoint. This wallet is going to act as a container for the tenant's assets (DIDs, VCs, Connections, etc.). The wallet seed may be provided during the wallet creation or omitted to let the Agent generate one randomly. From 841c5f40a0eb40ebaf2ecaa2ad027e15535ebf10 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:17:21 +0700 Subject: [PATCH 32/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index a6e3f0695a..c0536e1d93 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -123,7 +123,7 @@ Response Example: ### 4. Create a new wallet Create a wallet using a `POST /wallets` endpoint. -This wallet is going to act as a container for the tenant's assets (DIDs, VCs, Connections, etc.). +This wallet will be a container for the tenant's assets (DIDs, VCs, Connections, etc.). The wallet seed may be provided during the wallet creation or omitted to let the Agent generate one randomly. If the user already have the wallet associated, the wallet creation will fail as multiple wallets per tenant is not yet allowed. From ba4386301ebda75a1df6055315921468a9fc9441 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:17:30 +0700 Subject: [PATCH 33/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index c0536e1d93..43d30db82a 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -126,7 +126,7 @@ Create a wallet using a `POST /wallets` endpoint. This wallet will be a container for the tenant's assets (DIDs, VCs, Connections, etc.). The wallet seed may be provided during the wallet creation or omitted to let the Agent generate one randomly. -If the user already have the wallet associated, the wallet creation will fail as multiple wallets per tenant is not yet allowed. +If the user already has the wallet associated, the wallet creation will fail as multiple wallets per tenant are not yet allowed. ```bash curl -X 'POST' \ From 8aabde3391717ce83dac9a40f85108d70e33b0d5 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:17:46 +0700 Subject: [PATCH 34/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 43d30db82a..1fde6f3654 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -151,7 +151,7 @@ Response Example: } ``` -In this step, the agent create both wallet resource as well as UMA permission on Keycloak assigning the new wallet to the user who created it. +In this step, the agent creates both wallet resource and UMA permission on Keycloak, assigning the new wallet to the user who created it. ### 5. Perform a simple action to verify access to PRISM Agent From 3aa0035c225d05006dcc2dc9a64e7649b424f93e Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:17:54 +0700 Subject: [PATCH 35/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 1fde6f3654..512702a1bb 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -155,7 +155,7 @@ In this step, the agent creates both wallet resource and UMA permission on Keycl ### 5. Perform a simple action to verify access to PRISM Agent -Without further operation, the wallet should be availble for the tenant to use. +Without further operation, the wallet should be available for the tenant. To prove that the tenant can access the wallet, ```bash From acd27e9ea5a3835b6a46dd5abacb30ad92d9497f Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:18:06 +0700 Subject: [PATCH 36/47] Update docs/docusaurus/multitenancy/tenant-onboarding-self-service.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-self-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 512702a1bb..90f97fea99 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -156,7 +156,7 @@ In this step, the agent creates both wallet resource and UMA permission on Keycl ### 5. Perform a simple action to verify access to PRISM Agent Without further operation, the wallet should be available for the tenant. -To prove that the tenant can access the wallet, +To prove that the tenant can access the wallet, list the DIDs using RPT in the `Authorization` header. ```bash curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/dids' \ From ee694832f687d9d4ed65c535160f7525988aa79f Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:20:31 +0700 Subject: [PATCH 37/47] Apply suggestions from code review Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- .../multitenancy/tenant-migration.md | 16 +++--- .../multitenancy/tenant-onboarding-ext-iam.md | 56 +++++++++---------- .../tenant-onboarding-self-service.md | 18 +++--- 3 files changed, 44 insertions(+), 46 deletions(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 797bc05cf1..538b1527eb 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -105,10 +105,10 @@ Example token response (some fields omitted for readability) ### 3. Extract the subject ID from JWT -When creating a UMA permission, it is important to provide the subject ID which the permission will be granted to. +When creating a UMA permission, it is important to provide the subject ID to grant permission. To get the subject ID of the tenant, one can inspect the JWT payload `sub` claim. -Run this command to extract the `sub` claim of the token from pervious step +Run this command to extract the `sub` claim of the token from previous step. ```bash echo 'eyJhbGciOi...7ocDHofUDQ' | cut --delimiter='.' --fields=2 | base64 --decode | jq -r '.sub' @@ -122,8 +122,8 @@ Example result ### 4. Grant the user permission to the wallet -The addition UMA permission can be added to the current wallet giving Keycloak user an access. -This can be done by invoking the `POST /wallets/{walletId}/uma-permissions` endpoint on the agent. +UMA permission can be added to the current wallet, giving Keycloak users access. +To do this, invoke the `POST /wallets/{walletId}/uma-permissions` endpoint on the agent. ```bash curl -X 'POST' \ @@ -139,12 +139,12 @@ curl -X 'POST' \ Make sure to use the correct `subject` for the user and the correct `walletId` from the step earlier. -The response should return status `200 OK` in case of successful permission creation. +The response should return the status `200 OK` in case of successful permission creation. ### 5. Perform a simple action to verify access to PRISM Agent -After sucessful UMA permission creation, the user should be able to use `JWT` token for authentitcation to the wallet. -Simply list the wallet using a new `Authorization` header, the listed wallets should contain the wallet with the same ID in step 1. +After successful UMA permission creation, the user should be able to use the `JWT` token to authenticate the wallet. +List the wallet using a new `Authorization` header. The listed wallets should contain the wallet with the same ID in step 1. ```bash curl -X 'GET' \ @@ -173,4 +173,4 @@ Response Example: } ``` -This indicates that the user should be able to perform any wallet interaction with the `JWT` and `apikey` interchangeably. +This response indicates that the user should be able to perform any wallet interaction with the `JWT` and `apikey` interchangeably. diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index dc3cbad1ca..efd1185535 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -1,13 +1,11 @@ # Tenant Onboarding with External IAM In the [Tenant Onboarding](./tenant-onboarding.md) tutorial, we explored the basic -[IAM](/docs/concepts/glossary#iam) functionality provided by the agent out of the box. Although it is usable and straightforward, -there are more featureful tools available for handling identity and access management. -The agent has the capability to seamlessly connect with [Keycloak](/docs/concepts/glossary#keycloak-service) as an external IAM system -allowing the application built on top to utilize capabilities that comes with Keycloak. +The agent provides [IAM](/docs/concepts/glossary#iam) functionality out of the box. Although it is usable and straightforward, more featureful tools are available for handling identity and access management. +The agent can seamlessly connect with [Keycloak](/docs/concepts/glossary#keycloak-service) as an external IAM system, allowing the application built on top to utilize capabilities that come with Keycloak. The PRISM Agent leverages standard protocols like [OIDC](/docs/concepts/glossary#oidc) and [UMA](/docs/concepts/glossary#uma) for authentication and access management. -The user's identity is established through the ID token, and wallet permissions can be queried using the [RPT (requesting party token)](/docs/concepts/glossary#rpt). +The user's identity gets established through the ID token, and wallet permissions are searchable using the [RPT (requesting party token)](/docs/concepts/glossary#rpt). ## Roles @@ -36,20 +34,20 @@ In tenant management with external IAM, there are 2 roles: ## Overview -This tutorial illustrates the process of provisioning a wallet resource for the new tenant and subsequently creating a tenant in Keycloak. -The administrator can then create a UMA permission for the wallet giving access to the tenant. +This tutorial illustrates the process of provisioning a wallet resource for the new tenant and creating a tenant in Keycloak. +The administrator can then create a UMA permission for the wallet, giving access to the tenant. -When setting up UMA permissions on the agent, the wallet resource along with the UMA policy and permission +When setting up UMA permissions on the agent, the wallet resource, along with the UMA policy and permission are created on Keycloak according to a predefined convention. For flexibility in defining custom policy and permission models, administrators can manually create these UMA resources (resource, policy, permission) directly on Keycloak using a set of UMA endpoints called [Protection API](/docs/concepts/glossary#protection-api) (see [Keycloak Protection API](https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_protection_api)). -However, using Protection API to manage permissions is out of scope for this tutorial. +However, using Protection API to manage permissions is out of the scope of this tutorial. Once the registration is successful, the tenant can obtain an ID token from Keycloak using any available OIDC flow, such as the direct access grants (username & password). This ID token typically contains user claims such as username and subject ID. The tenant can use Keycloak's token endpoint to convert this token to an RPT (requesting party token), -which is another token containing permissions information. +another token containing permissions information. The tenant can access the multi-tenant agent by providing the RPT in the `Authorization` header. ## Endpoints @@ -95,9 +93,9 @@ Response Example: ### 2. Create a new wallet -The wallet can be created using a `POST /wallets` endpoint. -This wallet is going to act as a container for the tenant's assets (DIDs, VCs, Connections, etc.). -The wallet seed may be provided during the wallet creation or omitted to let the Agent generate one randomly. +Create a wallet using a `POST /wallets` endpoint. +This wallet will be a container for the tenant's assets (DIDs, VCs, Connections, etc.). +Provide a wallet seed during the wallet creation or let the Agent generate one ```bash @@ -126,13 +124,13 @@ Response Example: ### 3. User registration on Keycloak There are multiple ways to complete this step. -The goal is to ensure the user is registered on Keycloak. -Keycloak offers great flexibility, allowing users to self-register, +The goal is to ensure the user has registered on Keycloak. +Keycloak offers great flexibility, allowing users to self-register, connect to IDP, or be manually created by an administrator. -For this tutorial, the user will be manually created using Keycloak admin API for simplicity. +For this tutorial, we will generate the user manually using Keycloak admin API for simplicity. The first step is to get an admin token from Keycloak using the username and password. -This token allows the admin to perform operations on Keycloak such as creating a new user. +This token allows the admin to perform operations on Keycloak, such as creating a new user. Running the provided command should return the admin access token. ```bash @@ -156,7 +154,7 @@ Example token response (some fields omitted for readability) } ``` -After the admin get the `access_token` from Keycloak, a new user can be created by running this command. +After obtaining the `access_token` from Keycloak's admin, a new user can be created using this command: ```bash curl -X 'POST' \ @@ -223,9 +221,9 @@ the tenant can log in and utilize the agent by using the token issued by Keycloa The first step is to authenticate via Keycloak through any applicable authentication method. Usually, the tenant will use some frontend application that follows the standard flow for logging in. -For simplicity, a username and password flow will be used in this tutorial. +For simplicity, we use a flow for username and password in this tutorial. The administrator has already set up the username and password for the tenant. -The tenant can call Keycloak token endpoint directly with those credentials to get the access token. +To get the access token, the tenant can call the Keycloak token endpoint directly with those credentials. Run the command to log in @@ -238,8 +236,8 @@ curl -X 'POST' \ -d "password=1234" ``` -Special attention on the `client_id`, this should be the actual `client_id` of the frontend application that log the user in. -For this tutorial, it is absolutely OK to use `admin-cli`. +Special attention on the `client_id`; this should be the actual `client_id` of the frontend application that logs the user in. +For this tutorial, it is OK to use `admin-cli`. Example token response (some fields omitted for readability) @@ -253,8 +251,8 @@ Example token response (some fields omitted for readability) ### 2. Request RPT (requesting party token) from access token -After the access token is aquired, the next step is to get the RPT token which holds information about the permissions. -The RPT can be requested by running this command +After the access token is acquired, the next step is to get the RPT token, which holds information about the permissions. +It is possible to request the RPT by running this command: ```bash curl -X POST \ @@ -274,7 +272,7 @@ Example token response (some fields omitted for readability) } ``` -Inspecting the token of the response, there should be a new claim in the JWT payload called `authorization`. +After inspecting the response token, a new claim named `authorization` should appear in the JWT payload. Example RPT payload (some fields omitted for readability) @@ -308,13 +306,13 @@ curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/d Make sure to replace the token with RPT from previous step. The result should show 200 status with an empty list. -This means that the wallet has been created and it does not contain any DIDs. -Any interactions that the tenant performs should be scoped to only this wallet. +This means that the wallet has been created and does not contain any DIDs. +All actions carried out by the tenant must be limited to this specific wallet. ### A note on RPT In this tutorial, there is an additional step for the tenant to request the RPT from the access token. -This aligns with the standard UMA interaction, where the handling of RPT typically occurs on the client side. -To simplify the experience, the agent has a feature that allows user to bypass this process. +This process aligns with the standard UMA interaction, where the handling of RPT typically occurs on the client side. +To simplify the experience, the agent has a feature allowing users to bypass this process. By setting the variable `KEYCLOAK_UMA_AUTO_UPGRADE_RPT=true`, tenants can utilize the access token obtained in step 1 directly in the `Authorization` header, eliminating the need for additional RPT request step. diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 90f97fea99..9738d0035f 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -3,27 +3,27 @@ In the [Tenant Onboarding with External IAM](./tenant-onboarding-ext-iam.md) tutorial, we learned how [Keycloak](/docs/concepts/glossary#keycloak-service) helps with user access and how it works together with the agent. To set things up, the admin has to provision the required resources. -However, relying on the admin for onboarding operation can be restrictive for some use cases. +However, relying on the admin for onboarding operations can be restrictive for some use cases. For example, some tenants might want to onboard on a self-service agent instance without admin intervention. By leveraging Keycloak for a self-service agent instance, users can self-register or link to other [Identity Providers (IDPs)](/docs/concepts/glossary#idp) to register an account. -Once the account is registered, users can use it to set up their own wallet. -This tutorial will dive into the steps to facilitate this scenario where [administrator](/docs/concepts/glossary#administrator) intervention is not needed. +Once the account is registered, users can use it to set up their wallets. +This tutorial will investigate the steps to facilitate this scenario where [administrator](/docs/concepts/glossary#administrator) intervention is unnecessary. ## Roles -In sef-service tenant management with external IAM, there is only 1 role: +In self-service tenant management with external IAM, there is only one role: 1. [Tenant](/docs/concepts/glossary#tenant) ## Prerequisites -1. Keycloak up and running +1. Keycloak is up and running. 2. Keycloak is configured as follows 1. A realm called `my-realm` is created 2. A client called `prism-agent` under `my-realm` with __authorization__ feature is created. (See [create client instruction](https://www.keycloak.org/docs/latest/authorization_services/index.html#_resource_server_create_client)) - 3. Make sure the `prism-agent` client has __direct access grants__ enabled to simplify login process for this tutorial + 3. Make sure the `prism-agent` client has __direct access grants__ enabled to simplify the login process for this tutorial. 4. Make sure to [allow user self-registration](https://www.keycloak.org/docs/latest/server_admin/index.html#con-user-registration_server_administration_guide). 3. PRISM Agent up and running 4. PRISM Agent is configured with the following environment variables: @@ -63,7 +63,7 @@ When the agent uses this token for the wallet creation, the agent recognizes it Start by registering a new account on Keycloak, accessible through its login page. Usually, this should be available at `http://localhost:9980/realms/my-realm/account/`. -For detailed instruction on how to register a new user, +For detailed instructions on how to register a new user, please refer to [registering a new user](https://www.keycloak.org/docs/latest/server_admin/index.html#proc-registering-new-user_server_administration_guide) section on the official documentation. ### 2. Obtain access token from Keycloak @@ -82,7 +82,7 @@ curl -X 'POST' \ ``` Make sure to use the correct username and password. -Special attention on the `client_id`, this should be the actual `client_id` of the frontend application that log the user in. +Special attention on the `client_id`; this should be the actual `client_id` of the frontend application that logs the user in. For this tutorial, it is OK to use `admin-cli`. Example token response (some fields omitted for readability) @@ -124,7 +124,7 @@ Response Example: Create a wallet using a `POST /wallets` endpoint. This wallet will be a container for the tenant's assets (DIDs, VCs, Connections, etc.). -The wallet seed may be provided during the wallet creation or omitted to let the Agent generate one randomly. +The Agent can provide or randomly generate the wallet seed during wallet creation. If the user already has the wallet associated, the wallet creation will fail as multiple wallets per tenant are not yet allowed. From 835faa329b460940a5e6424ab9466d8469fee5f3 Mon Sep 17 00:00:00 2001 From: patlo-iog Date: Tue, 21 Nov 2023 01:24:28 +0700 Subject: [PATCH 38/47] Update docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md Co-authored-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Signed-off-by: patlo-iog --- docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index efd1185535..75affbacb9 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -126,7 +126,6 @@ Response Example: There are multiple ways to complete this step. The goal is to ensure the user has registered on Keycloak. Keycloak offers great flexibility, allowing users to self-register, -connect to IDP, or be manually created by an administrator. For this tutorial, we will generate the user manually using Keycloak admin API for simplicity. The first step is to get an admin token from Keycloak using the username and password. From dffbe69bb8948fd71fa267e8882cf0e455ae6ce9 Mon Sep 17 00:00:00 2001 From: Pat Losoponkul Date: Tue, 21 Nov 2023 01:27:07 +0700 Subject: [PATCH 39/47] docs: reference RPT in glossary Signed-off-by: Pat Losoponkul --- docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index 75affbacb9..37de8d0c96 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -248,7 +248,7 @@ Example token response (some fields omitted for readability) } ``` -### 2. Request RPT (requesting party token) from access token +### 2. Request [RPT (requesting party token)](/docs/concepts/glossary#rpt) from access token After the access token is acquired, the next step is to get the RPT token, which holds information about the permissions. It is possible to request the RPT by running this command: From 92f2a02e696a66d5569f2211fb12f7386d19e3e6 Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Tue, 21 Nov 2023 07:39:38 -0600 Subject: [PATCH 40/47] Update docs/docusaurus/multitenancy/tenant-migration.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 538b1527eb..8869cfd603 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -91,7 +91,7 @@ curl -X 'POST' \ Make sure to use the correct username and password. Special attention on the `client_id`; this should be the actual `client_id` of the frontend application that logs the user in. -For this tutorial, it is OK to use `admin-cli.` +For this tutorial, it is OK to use `admin-cli` Example token response (some fields omitted for readability) From 70f0d2461a938f463e67fb0ae31d960b5786c842 Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Tue, 21 Nov 2023 07:40:01 -0600 Subject: [PATCH 41/47] Update docs/docusaurus/multitenancy/tenant-migration.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 8869cfd603..3297d6c9ca 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -3,7 +3,7 @@ PRISM Agent authentication supports multiple authentication methods simultaneously. This means the user can seamlessly use any available credentials including `apikey` or `JWT` to access the wallet. The agent's [UMA](/docs/concepts/glossary#uma) permission resource also exposes self-service permission endpoint, allowing users to manage the permissions for their wallets. -This facilitates a pattern where users can transition from `apikey` to `JWT` authentication without requiring admin intervention. +It allows users to transition from `apikey` to `JWT` authentication without admin intervention.intervention. ## Roles From a2581182cdccb20f713d3fed4c74687940394e42 Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Tue, 21 Nov 2023 07:40:06 -0600 Subject: [PATCH 42/47] Update docs/docusaurus/multitenancy/tenant-migration.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-migration.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 3297d6c9ca..2f010aa905 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -1,7 +1,6 @@ # Migration from `apikey` to `JWT` authentication PRISM Agent authentication supports multiple authentication methods simultaneously. -This means the user can seamlessly use any available credentials including `apikey` or `JWT` to access the wallet. The agent's [UMA](/docs/concepts/glossary#uma) permission resource also exposes self-service permission endpoint, allowing users to manage the permissions for their wallets. It allows users to transition from `apikey` to `JWT` authentication without admin intervention.intervention. From e1ba578f86764f5861e3d170ade47e3c0c46bc79 Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Tue, 21 Nov 2023 07:40:12 -0600 Subject: [PATCH 43/47] Update docs/docusaurus/multitenancy/tenant-migration.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 2f010aa905..7a5dc4ff74 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -1,6 +1,6 @@ # Migration from `apikey` to `JWT` authentication -PRISM Agent authentication supports multiple authentication methods simultaneously. +PRISM Agent authentication supports multiple authentication methods simultaneously, which means the user can seamlessly use any available credentials including `apikey` or `JWT` to access the wallet. The agent's [UMA](/docs/concepts/glossary#uma) permission resource also exposes self-service permission endpoint, allowing users to manage the permissions for their wallets. It allows users to transition from `apikey` to `JWT` authentication without admin intervention.intervention. From 13a31facbe5b6bee099422ac0352abfaa25daff4 Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Tue, 21 Nov 2023 07:40:18 -0600 Subject: [PATCH 44/47] Update docs/docusaurus/multitenancy/tenant-migration.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 7a5dc4ff74..7e057b9c92 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -6,7 +6,7 @@ It allows users to transition from `apikey` to `JWT` authentication without admi ## Roles -In the migration process from `apikey` to `JWT`, there is only 1 role: +In the migration process from `apikey` to `JWT`, there is only one role: 1. Tenant From 493b06fa2aa3fb65432b30e33718bf19aa2167b3 Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Tue, 21 Nov 2023 07:40:23 -0600 Subject: [PATCH 45/47] Update docs/docusaurus/multitenancy/tenant-migration.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 7e057b9c92..46c4b7e481 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -17,7 +17,7 @@ In the migration process from `apikey` to `JWT`, there is only one role: 3. PRISM Agent up and running 4. PRISM Agent is configured the same as in [Tenant Onboarding Self-Service](./tenant-onboarding-self-service.md) 5. The user has access to the wallet using `apikey`. (See [Tenant Onboarding](./tenant-onboarding.md)) -6. The user has account registered on Keycloak +6. The user has an account registered on Keycloak ## Overview From 32f90b7b76d4d7c704975efe109124eb6a2b4d0c Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Tue, 21 Nov 2023 07:40:42 -0600 Subject: [PATCH 46/47] Update docs/docusaurus/multitenancy/tenant-migration.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 46c4b7e481..944dfd14f3 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -46,7 +46,7 @@ To migrate to `JWT` authentication, users can create a new UMA permission for th This tutorial assumes the tenant has access to the wallet using `apikey`. Before granting more permission to the wallet, the `walletId` must be identified. -This can be done by listing the wallets using `apikey`. +To find the wallet, list them using `apikey`. ```bash curl -X 'GET' \ From e404e9b03907dd11ad36f65f6ba11284e575d524 Mon Sep 17 00:00:00 2001 From: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> Date: Tue, 21 Nov 2023 07:43:52 -0600 Subject: [PATCH 47/47] Update docs/docusaurus/multitenancy/tenant-migration.md Signed-off-by: Pete Vielhaber <95773776+petevielhaber@users.noreply.github.com> --- docs/docusaurus/multitenancy/tenant-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 944dfd14f3..38e21e18b4 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -44,7 +44,7 @@ To migrate to `JWT` authentication, users can create a new UMA permission for th ### 1. Check the existing wallets using `apikey` -This tutorial assumes the tenant has access to the wallet using `apikey`. +This tutorial assumes the tenant can access the wallet using `apikey`. Before granting more permission to the wallet, the `walletId` must be identified. To find the wallet, list them using `apikey`.