diff --git a/en/asgardeo/docs/guides/authorization/user-impersonation.md b/en/asgardeo/docs/guides/authorization/user-impersonation.md index dd80a95a1b..7ef0fbe66b 100644 --- a/en/asgardeo/docs/guides/authorization/user-impersonation.md +++ b/en/asgardeo/docs/guides/authorization/user-impersonation.md @@ -1 +1,5 @@ +{% set base_url = "api.asgardeo.io/{organization_name}" %} +{% set base_url_sample = "api.asgardeo.io/bifrost" %} + + {% include "../../../../includes/guides/authorization/user-impersonation.md" %} \ No newline at end of file diff --git a/en/identity-server/7.0.0/docs/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png b/en/identity-server/7.0.0/docs/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png index 161e37eb2a..179ae373c9 100644 Binary files a/en/identity-server/7.0.0/docs/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png and b/en/identity-server/7.0.0/docs/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png differ diff --git a/en/identity-server/7.0.0/docs/assets/img/guides/authorization/impersonation/role-creation.png b/en/identity-server/7.0.0/docs/assets/img/guides/authorization/impersonation/role-creation.png index 8d3cbe89c4..a4f73c9f8d 100644 Binary files a/en/identity-server/7.0.0/docs/assets/img/guides/authorization/impersonation/role-creation.png and b/en/identity-server/7.0.0/docs/assets/img/guides/authorization/impersonation/role-creation.png differ diff --git a/en/identity-server/7.0.0/docs/guides/authorization/api-authorization/api-authorization.md b/en/identity-server/7.0.0/docs/guides/authorization/api-authorization/api-authorization.md index 24c1f256e4..66695d26c3 100644 --- a/en/identity-server/7.0.0/docs/guides/authorization/api-authorization/api-authorization.md +++ b/en/identity-server/7.0.0/docs/guides/authorization/api-authorization/api-authorization.md @@ -1 +1 @@ -{% include "../../../../../../includes/guides/api-authorization.md" %} \ No newline at end of file +{% include "../../../../../../includes/guides/authorization/api-authorization.md" %} \ No newline at end of file diff --git a/en/identity-server/7.0.0/docs/guides/authorization/api-authorization/attribute-based-access-control.md b/en/identity-server/7.0.0/docs/guides/authorization/api-authorization/attribute-based-access-control.md index f4736130a8..c1a7f5150b 100644 --- a/en/identity-server/7.0.0/docs/guides/authorization/api-authorization/attribute-based-access-control.md +++ b/en/identity-server/7.0.0/docs/guides/authorization/api-authorization/attribute-based-access-control.md @@ -1,197 +1 @@ -# Validating the Scope of OAuth Access Tokens using XACML Policies - -WSO2 Identity Server (WSO2 IS) allows you to validate the scope of an -OAuth access token using XACML policies to provide fine-grained access -control to APIs. - -If you want the XACML scope validator to execute after checking the -validity of the access token in an OAuth access token validation flow, -you can select the scope validator as XACML when you configure a service -provider. This provides fine-grained access control to APIs. - -The following sections walk you through the basic steps -you need to follow to validate the scope of OAuth access tokens using -XACML policies. - -### Register the app - -Follow the steps given below to configure an application in WSO2 Identity -Server so that the authentication happens as expected. - -1. On the {{ product_name }} Console, go to **Applications**. -2. Click **New Application** and select **Standard-Based Application**. - ![Register a standard-based application]({{base_path}}/assets/img/guides/applications/register-an-sba.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} -3. Provide an application name and select the other options based on your requirements. - - !!! note - - You can choose OIDC or SAML as the standard protocol for your application. See the complete list of [OIDC]({{base_path}}/references/app-settings/oidc-settings-for-app/) and [SAML]({{base_path}}/references/app-settings/saml-settings-for-app/) configurations. - - If you use OIDC, you can authorize APIs to an app to access the APIs in {{ product_name }}. Learn about [Authorize the API resources for an app]({{base_path}}/guides/authorization/api-authorization/api-authorization/#authorize-the-api-resources-for-an-app). - -4. Click **Register** to complete the registration. -5. After the application is registered, you will be redirected into the application. -6. Do the required changes to the application and click **Update**. -7. Get the created application's inbound protocol (OAuth2 / OIDC) configurations - by using the following REST API call. - - ```java - curl --location 'https://localhost:9443/t//api/server/v1/applications//inbound-protocols/oidc' \ - --header 'Authorization: Basic YWRtaW46YWRtaW4=' - ``` - -8. Copy the response of the above REST API call and add the following value to the - `scopeValidators` array in the response. - - ```json - "scopeValidators": [ - "XACML Scope Validator" - ] - ``` - -9. Execute the Inbound Protocols PUT REST API call to update the application with the - XACML scope validator which added in the step 7. You can get the API call details from - Update OIDC authentication protocol parameters. - -### Register an API resource and Authorize for an app - -1. Go to the **API Resources** and click **New API Resource**. -2. Add the relevant details to Basic Details, Scopes, Authorization sections and click **Create**. -3. Go to the **API Authorization** tab in the created application. -4. Click **Authorize an API Resource**, select the created API resource, scopes and click **Finish**. - - !!!note - For more information on API Authorization, see [here](../api-authorization/api-authorization.md) - -### Create a user and a role - -1. Go to **User Management** > **Users**. -2. Click **Add User** button and select **Single User** option. -3. Provide the relevant details and click **Save & Continue**. -4. Go to the **User Management** > **Roles**. -5. Click **New Role**, add the Basic Details, Permission Selection and click **Finish**. -6. Go to the **Users** tab of the created role and assign the created user to the role. - - !!!note - For more information on User Management, see [here](../../users/index.md) - -The next step is to configure the XACML policy to validate the XACML scope during OAuth -token issuance. - -### Set up the policy - -Follow the instructions given below to publish a policy using a XACML policy -template that is available by default with WSO2 Identity Server. - -1. Log in to the Management Console via . -2. In the **Main** tab of the Management Console, navigate to - **PAP** \> **Policy Administration** under the **Entitlement** menu. -3. Select the `scope_based_token_issuance_policy_template` - policy, and click **Edit** to view the selected policy in the policy - editor. - - - !!! info - XACML template policies provide a pre-configured template with place - holders to customize the policy depending on your requirement. - - -4. Edit the policy to customize it depending on your requirement. You - can change the values of attributes and rules. -5. Click **Save Policy** to save the changes. You can see the policy - that you created on the policy list (the original policy template - remains unchanged). -6. Click the link **Publish to My PDP** corresponding to the new - policy. -7. On the UI that appears, leave the default values as they are and - click **Publish**. - - To ensure that the policy has been published successfully, click on - **Policy View** under the **Entitlement \> PDP** section on the - **Main** tab of the Management Console, and check if the created - policy is listed. - -Now, you have created the policy and enforced it using the policy -template. You can test the policy to evaluate whether XACML scope is -validated at the time of OAuth token issuance. - -### Try it out - -Follow the steps given below to try out the policy using the above created application. - -1. On the {{ product_name }} Console, go to **Applications**. -2. Select your application, go to the **Protocols** tab of the application and enable the **Password** grant type. -3. Execute the following cURL command to get an access token using the password grant type. - -```java -curl --location 'https://localhost:9443/t//oauth2/token' \ ---header 'Content-Type: application/x-www-form-urlencoded' \ ---header 'Authorization: Basic ' \ ---data-urlencode 'grant_type=password' \ ---data-urlencode 'username=' \ ---data-urlencode 'password=' \ ---data-urlencode 'scope=openid SCOPE_1' -``` -If the token request can be permitted by the policy, the response will contain an access token. -If the token request is denied by the policy, the response will contain an error message. - -Follow the steps below to try out the policy using the XACML TryIt tool. - -!!! tip - The XACML TryIt tool allows you to test policies easily without having - to create and send authorization requests to WSO2 IS. It is a tool - through which authorization requests can be created and evaluated - against available policies. You can write simple XACML 3.0 requests in - XML format and try them using the web UI of the TryIt tool. - -1. On the Management Console, click **Tools**, and then click - **TryIt** under the **XACML** section. - -2. Click **Create Request Using Editor**. - -3. Specify the following as the sample request: - - ``` java - - - - test_server - - - - - scope_validation - - - - - openid - - - SCOPE_1 - - - - - @ - - - - - - - - - - - - - - - - - - ``` - -4. Click **Evaluate With PDP**. You will see a response message that - says either `Permit` or `Deny` - depending on whether the XACML scope is validated or not at the time - of OAuth token validation. +{% include "../../../../../../includes/guides/authorization/attribute-based-access-control.md" %} \ No newline at end of file diff --git a/en/identity-server/7.0.0/docs/guides/authorization/fine-grained-authorization/rule-based-provisioning.md b/en/identity-server/7.0.0/docs/guides/authorization/fine-grained-authorization/rule-based-provisioning.md index f913daa15f..7fcb3ce079 100644 --- a/en/identity-server/7.0.0/docs/guides/authorization/fine-grained-authorization/rule-based-provisioning.md +++ b/en/identity-server/7.0.0/docs/guides/authorization/fine-grained-authorization/rule-based-provisioning.md @@ -1,188 +1 @@ -# Configure rule-based provisioning - -This page guides you through provisioning users based on defined XACML rules. - -To get a better understanding of rule-based provisioning, consider a scenario where you need to provision users assigned to the finance role from WSO2 Identity Server to the GoogleIDP. To implement this scenario, you can define a XACML policy that permits the provisioning operation if the provisioning user is assigned the finance role. - -Follow the steps given below to configure rule-based provisioning in WSO2 Identity Server. - -## Sample scenario - -Let's assume we need to provision users based on their email domain and restrict the provisioning of users who do not have the email attribute with the permitted domain (`@abc.com`). Let's create a XACML policy to implement this scenario. - -## Setting up the {{ product_name }} - -### Prerequisites -Setup outbound provisioning using the desired outbound provisioning connector ([Google]({{base_path}}/guides/users/outbound-provisioning/outbound-connectors/google/), [Salesforce]({{base_path}}/guides/users/outbound-provisioning/outbound-connectors/salesforce/) or [SCIM2]({{base_path}}/guides/users/outbound-provisioning/outbound-connectors/scim2/)). - -### Configure the resident service provider - -You need to enable rules in the outbound provisioning connector you have added to the resident service provider. This can be done using the following API: -```java -curl --location --request PUT 'https://localhost:9443/api/server/v1/applications/resident' \ ---header 'accept: application/json' \ ---header 'Authorization: Basic YWRtaW46YWRtaW4=' \ ---header 'Content-Type: application/json' \ ---data '{ - "outboundProvisioningIdps": [ - { - "idp": , - "connector": "SCIM2", - "blocking": false, - "rules": true, - "jit": false - } - ] -}' -``` - -Replace the `` with the name of the outbound provisioning connector you have registered in the earlier step. - -### Configure the service provider - -If you have configured outbound provisioning in your application, you should **Enable rules** in the outbound provisioning connector. This can be done using the following API: - -```java -curl --location --request PATCH 'https://localhost:9443/api/server/v1/applications/' \ ---header 'accept: application/json' \ ---header 'Authorization: Basic YWRtaW46YWRtaW4=' \ ---header 'Content-Type: application/json' \ ---data '{ - "provisioningConfigurations": { - "outboundProvisioningIdps": [ - { - "idp": , - "connector": "SCIM2", - "blocking": false, - "rules": true, - "jit": false - } - ] - } -}' -``` - -Replace the `` with the name of the outbound provisioning connector you have registered in the earlier step. - -Use the [application API]({{base_path}}/apis/application-rest-api/#tag/Applications/operation/getAllApplications) to find the application ID of your application and replace the `` with it. - - -## Set up XACML rules - -1. Log in to the Management Console(`https://:/carbon`) using admin/admin credentials. -2. Click on **Policy Administration** under the **Entitlement** > **PAP** section on the **Main** tab of the management console. -3. Since this sample scenario is based on the email address user claim, we need to select the policy `provisioning_user_claim_based_policy_template`. - ![Policy list]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} -4. Once you click **Edit**, the XML based policy will appear in the policy editor. There are placeholders in capitals for entering the service provider and role names. -5. Edit the placeholders accordingly with the relevant values. - 1. Change the `PolicyId` as follows: - ```xml - PolicyId="provisioning_user_claim_based_policy" - ``` - 2. Edit the `` tag and enter a description relevant to your custom policy. - 3. Locate the `IDP_NAME` placeholder and replace it with the identity provider name you have created earlier. - 4. Since we need to do a regex match on the email claim, change the condition of the rules as follows: - ```xml - - - - .*@abc\.com$ - - - - - - - ``` - 5. Since we are using only one user claim for this policy, remove the other claim by removing that entire section from the start of the `` tag to the ending `` tag. This should be edited in both POST and PUT sections as the provisioning is initiated when creating the user and when updating the user as well. - 6. Also for this example, we do not need a service provider. Therefore, we need to remove the service provider `SP_NAME` match block as well. -6. Once the changes have been made, the policy should be similar to the following. -```xml - -This template policy provides ability to authorize provisioning requests initiated from a given service provider(defined by SP_NAME) to a given identity provider(defined by IDP_NAME) in the outbound provisioning flow based on the claim values of the user (CLAIM_URI_1=CLAIM_VALUE_1 and CLAIM_URI_2=CLAIM_VALUE_2). Users with the given claim values will be allowed and any other users will be denied. - - - - -WSO2IDP - - - - -provisioning - - - - - - - - - - - -POST - - - - - - - - - -.*@wso2\.com$ - - - - - - - - - - - - - -PUT - - - - - - - - - - - - - -test@abc.com - - - - - - - -``` - -7. Click **Save Policy** to save the changes. You can see the policy you just created on the policy list (the original template policy will remain unchanged for later use). - ![Saved policy list]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy-saved.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -8. Click on the **Publish to My PDP** link corresponding to the new policy. - ![Publish To My PDP icon]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy-to-publish.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -9. On the UI that appears, leave the default selected values as they are and click **Publish**. -10. Click on **Policy View** under the **Entitlement>PDP** section on the **Main** tab of the management console. -11. To ensure that the policy has been published successfully, check if the policy is listed. - ![Published policy]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy-published.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} -12. To test out whether the policy works, follow the **Try it** out section. - - -## Try it out - -Once the policies are published to PDP, they are ready to execute during outbound provisioning. You can test rule-based provisioning by creating a user in WSO2 Identity Server that matches the rules you enforced. -For example, when you create a user with the email `"jane@abc.com"` in WSO2 Identity Server, it should be provisioned to the external IDP you have configured for outbound provisioning as well. A user who does not have an email with the domain `@abc.com` should not be provisioned. \ No newline at end of file +{% include "../../../../../../includes/guides/authorization/fine-grained-authorization/rule-based-provisioning.md" %} \ No newline at end of file diff --git a/en/identity-server/7.0.0/docs/guides/authorization/impersonation/user-impersonation.md b/en/identity-server/7.0.0/docs/guides/authorization/impersonation/user-impersonation.md index bc8fd65e2b..8a6e3e98eb 100644 --- a/en/identity-server/7.0.0/docs/guides/authorization/impersonation/user-impersonation.md +++ b/en/identity-server/7.0.0/docs/guides/authorization/impersonation/user-impersonation.md @@ -1,380 +1,4 @@ -# User Impersonation +{% set base_url = "localhost:9443" %} +{% set base_url_sample = "localhost:9443" %} -User impersonation involves an authorization server’s ability to temporarily grant access to another user's account. With this feature, a user with required permission can impersonate any user within the organization. - -!!! note - This feature is only available from update level 41 onwards. If you don't already have this update, see the instructions on [updating WSO2 products](https://updates.docs.wso2.com/en/latest/updates/overview/). - -## Setting up the {{ product_name }} - -### Enable Impersonation Feature - -#### Apply deployment.toml configuration - -You need to apply following deployment.toml configurations before statring the server. -```toml -[[oauth.custom_response_type]] -name= "subject_token" -class= "org.wso2.carbon.identity.oauth2.authz.handlers.SubjectTokenResponseTypeHandler" -validator= "org.wso2.carbon.identity.oauth.common.SubjectTokenResponseValidator" - -[[oauth.custom_response_type]] -name= "id_token subject_token" -class= "org.wso2.carbon.identity.oauth2.authz.handlers.SubjectTokenResponseTypeHandler" -validator= "org.wso2.carbon.identity.oauth.common.SubjectTokenResponseValidator" - -[[api_resources]] -name= "User Impersonation" -identifier= "system:impersonation" -requiresAuthorization= true -description= "Resource representation of the User Impersonation" -type= "TENANT" - -[[api_resources.scopes]] -displayName = "User Impersonation Scope" -name = "internal_user_impersonate" -description = "Allows to impersonate another user" -``` - -#### Add Impersonation Configuration Resource - -Impersonation feature requires a config type to be added to the IDN_CONFIG_TYPE table. Please find the relevant db scripts below. - -??? Example "DB2" - - ```sql - INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); - ``` - -??? Example "H2" - - ```sql - INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); - ``` - -??? Example "MsSQL" - - ```sql - INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); - ``` - -??? Example "MYSQL" - - ```sql - INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); - - ``` - -??? Example "MYSQL-Cluster" - - ```sql - INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); - ``` - -??? Example "Oracle" - - ```sql - INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); - ``` - -??? Example "OracleRac" - - ```sql - INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); - ``` - -??? Example "Postgres" - - ```sql - INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); - ``` - -Alternatively you can use Config Management REST API to add this configuration. Please find the sample curl below. - -```curl -curl --location 'https:///api/identity/config-mgt/v1.0/resource-type' \ ---header 'accept: application/json' \ ---header 'Content-Type: application/json' \ ---header 'Authorization: Basic YWRtaW46YWRtaW4=' \ ---data '{"name": "IMPERSONATION_CONFIGURATION", "description": "A resource type to keep the tenant impersonation preferences."}' -``` - -You only need to run this command once per deployment. - - -### Configure the application - -#### Subscribe to Impersonation API - -1. On the {{ product_name }} Console, go to **Applications**. - -2. Select the application and go to API Authorization tab of the application and click authorize on API Resource. - -3. Search for User Impersonation under management APIs and subscribe to the application. - - ![Api-Authorization-Impersonation-Selection]({{base_path}}/assets/img/guides/authorization/impersonation/user-impersonation-selection.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - - ![Api-Authorization-Impersonation]({{base_path}}/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -4. Switch to the Roles tab, click on **+ New Role** to create a Role and assign the Impersonation Scope. - - ![Role-Creation]({{base_path}}/assets/img/guides/authorization/impersonation/role-creation.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -5. Create a User and assign to the Role. - -!!! note - To read about subscribing APIs and authorize using Role Based Access Control (RBAC) check [Role-based access control (RBAC)]({{base_path}}/guides/authorization/api-authorization/api-authorization/) - -#### Configure Subject token for the application - -1. On the {{ product_name }} Console, go to **Applications**. - -2. Select the application and go to Protocol tab. - -3. Enable **Token Exchange** grant type. - -4. Enable subject token. - -5. [Optional] Configure Subject token expiry time by default it is 3 minutes. - - ![Subject-Token-Config]({{base_path}}/assets/img/guides/authorization/impersonation/subject-token-config.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -6. Enable **JWT type** Access token. - -#### Apply application advanced configuration - -1. Select the application and go to Application Advanced tab. - -2. Enable skip login consent and Enable skip logout consent. - -## Impersonating a User - -Impersonating a user involves two step process. - -1. Acquire Subject token from Authorize endpoint. - -2. Exchange subject token for impersonated access token using Token Exchange grant type. - - ![Impersonation-Flow]({{base_path}}/assets/img/guides/authorization/impersonation/Impersonation-flow.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -### Acquire Subject Token - -A security JWT token that represents the identity of both parties Impersonator and End-User. Subject token can be used to exchange impersonated access token. To obtain subject token, client need to initiate an authorize call with following query parameters. - -**Request Format** -``` bash -https://{{ host_name }}/oauth2/authorize?redirect_uri={redirect_uri}&client_id={client_id}&state=&scope=internal_user_impersonate%20{Other_Required_Scopes}&response_type=id_token%20subject_token&requested_subject={User_id_of_the_end_user}&nonce={nonce} -``` - -**Sample Request** -``` bash -https://localhost:9443/oauth2/authorize?client_id=jVcW4oLn1Jjb2T94H4gtPV9z5Y0a&state=sample_state&scope=internal_user_impersonate%20openid%20internal_org_user_mgt_view%20internal_org_user_mgt_list%20internal_user_mgt_delete%20internal_org_user_mgt_create%20internal_login%20internal_user_mgt_delete%20internal_user_mgt_view%20internal_user_mgt_list%20internal_user_mgt_update%20internal_user_mgt_create&redirect_uri=https%3A%2F%2Foauth.pstmn.io%2Fv1%2Fcallback&response_type=id_token%20subject_token&requested_subject=32bc4697-ed0f-4546-8387-dcd6403e7caa&nonce=2131232 -``` - -**Sample Response after sucessful authorization** -``` bash -https://oauth.pstmn.io/v1/callback#id_token={id_token}&session_state=ecfb74cde9f694c1de0905aa40a5f6fc1dd595bdcfd739cbd3dd5b964da53325.1554z-G22KW3pwK_hYhqPw&state=sample&subject_token={subject_token} -``` - - -!!! note - - In Subject token requrest, - - - Response type can be **id_token subject_token** or **subject_token**. - - Scope should contain **internal_user_impersonate** scope with other required scopes. - - Requested_subject should be a valid user id. - - Authorizing user should have a role that is associated with Impersonation permission related to the application. - - Nonce is required if you re using “id_token subject_token” response type. - - -#### JWT cliams of Subject Token - -Apart from generic claims, subject token has a claim **may_act**. The **may_act** claim makes a statement that one party is authorized to become the actor and act on behalf of another party. Here **sub** id inside **may_act** claim hold the identity of the impersoator. - - -``` json -{ - "sub": "32bc4697-ed0f-4546-8387-dcd6403e7caa", - "aud": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "nbf": 1718694997, - "azp": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "scope": "internal_login internal_org_user_mgt_list internal_org_user_mgt_view internal_user_mgt_list internal_user_mgt_view", - "iss": "https://localhost:9443/oauth2/token", - "may_act": { - "sub": "2d931c9d-876e-46c0-9aba-f34501879dfc" - }, - "exp": 1718712997, - "iat": 1718694997, - "jti": "66dff3b0-2828-4bc0-8a27-84aa9bd3ebdb", - "client_id": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a" -} -``` - -### Acquire Impersonated Access Token - -Token exchange grant type can be used exchange subject for an impersonated access token. - -**Request Format** -``` bash -curl --location 'https://{{ host_name }}/oauth2/token' \ ---header 'Content-Type: application/x-www-form-urlencoded' \ ---header 'Authorization: Basic ' \ ---data-urlencode 'subject_token={subeject_token}' \ ---data-urlencode 'subject_token_type=urn:ietf:params:oauth:token-type:jwt' \ ---data-urlencode 'requested_token_type=urn:ietf:params:oauth:token-type:access_token' \ ---data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \ ---data-urlencode 'actor_token={id_token}' \ ---data-urlencode 'actor_token_type=urn:ietf:params:oauth:token-type:id_token' -``` - -**Sample Response** -``` json -{ - "access_token": "eyJ4NXQiOiJPV1JpTXpaaVlURXhZVEl4WkdGa05UVTJOVE0zTWpkaFltTmxNVFZrTnpRMU56a3paVGc1TVRrNE0yWmxOMkZoWkdaalpURmlNemxsTTJJM1l6ZzJNZyIsImtpZCI6Ik9XUmlNelppWVRFeFlUSXhaR0ZrTlRVMk5UTTNNamRoWW1ObE1UVmtOelExTnprelpUZzVNVGs0TTJabE4yRmhaR1pqWlRGaU16bGxNMkkzWXpnMk1nX1JTMjU2IiwidHlwIjoiYXQrand0IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIzMmJjNDY5Ny1lZDBmLTQ1NDYtODM4Ny1kY2Q2NDAzZTdjYWEiLCJhdXQiOiJBUFBMSUNBVElPTl9VU0VSIiwiaXNzIjoiaHR0cHM6XC9cL2xvY2FsaG9zdDo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiY2xpZW50X2lkIjoialZjVzRvTG4xSmpiMlQ5NEg0Z3RQVjl6NVkwYSIsImF1ZCI6ImpWY1c0b0xuMUpqYjJUOTRINGd0UFY5ejVZMGEiLCJuYmYiOjE3MTg2OTUwNTIsImFjdCI6eyJzdWIiOiIyZDkzMWM5ZC04NzZlLTQ2YzAtOWFiYS1mMzQ1MDE4NzlkZmMifSwiYXpwIjoialZjVzRvTG4xSmpiMlQ5NEg0Z3RQVjl6NVkwYSIsIm9yZ19pZCI6IjEwMDg0YThkLTExM2YtNDIxMS1hMGQ1LWVmZTM2YjA4MjIxMSIsInNjb3BlIjoiaW50ZXJuYWxfbG9naW4gaW50ZXJuYWxfb3JnX3VzZXJfbWd0X2xpc3QgaW50ZXJuYWxfb3JnX3VzZXJfbWd0X3ZpZXcgaW50ZXJuYWxfdXNlcl9tZ3RfbGlzdCBpbnRlcm5hbF91c2VyX21ndF92aWV3IG9wZW5pZCIsImV4cCI6MTcxODY5ODY1Miwib3JnX25hbWUiOiJTdXBlciIsImlhdCI6MTcxODY5NTA1MiwianRpIjoiMDcyOGQ1MTctNzk2OC00NzRmLWJkN2QtMTI1MzdjY2JlNDM2In0.FqavHBDNLo-nMMgJ3OTDswo7pl6zMztpUkm-cgBOgDJPek_FAEQzt4DFxGglnf2-AtnRN14wPOv9_M_DYJWH529hbwYBVrQQDlJmcF1WtWX_MnBgBGsIfA5_3nzocZWBqj5KDjbXS3_3CSexQ9_h3tKWCDX1oit03flcs7E_xG_nkWV1TUPFUAaoHrMWTROIttN1iFqwRjeg6Bkqjx8hHM3Dn7E9Zsmby0EhuC7i41kid2s9F_5XPPMCYM0gyxX5lAjsf6UFth9v3SWIuMLFgiq5Eh6u4pCs9srh2A5t0DIcKMwyXTEm-QVIhGi1zkB-wGV6yYD9TwbiujnrqOyFQA", - "issued_token_type": "urn:ietf:params:oauth:token-type:access_token", - "scope": "internal_login internal_org_user_mgt_list internal_org_user_mgt_view internal_user_mgt_list internal_user_mgt_view", - "token_type": "Bearer", - "expires_in": 3600 -} -``` - -#### JWT cliams of Impersonated Access Token - -Apart from generic claims, impersonated access token has a claim **act**. The **act** (actor) claim provides a means within a JWT to express that impersonation has occurred and identify the acting party to whom authority has been impersonated. The act claim value is a JSON object, Here **sub** id inside **act** claim hold the identity of the actor. - -``` json - -{ - "sub": "32bc4697-ed0f-4546-8387-dcd6403e7caa", - "aut": "APPLICATION_USER", - "iss": "https://localhost:9443/oauth2/token", - "client_id": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "aud": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "nbf": 1718695052, - "act": { - "sub": "2d931c9d-876e-46c0-9aba-f34501879dfc" - }, - "azp": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "org_id": "10084a8d-113f-4211-a0d5-efe36b082211", - "scope": "internal_login internal_org_user_mgt_list internal_org_user_mgt_view internal_user_mgt_list internal_user_mgt_view", - "exp": 1718698652, - "org_name": "Super", - "iat": 1718695052, - "jti": "0728d517-7968-474f-bd7d-12537ccbe436" -} - -``` - -The sub claim is the impersonated user (32bc4697-ed0f-4546-8387-dcd6403e7caa), while act.sub contains the ID of the impersonator (2d931c9d-876e-46c0-9aba-f34501879dfc). Client can detect impersonation using **act** claim in the access token. - -### Email Notification for impersonated user - -Once impersonated access token obtained, Authorization server will send an email notification to impersonated user. - -#### Configure Impersonation Email Notification - -1. Go to Login and Registration section. - -2. Select Impersonation Configurations under Organizations settings. - - ![Impersonation-Config]({{base_path}}/assets/img/guides/authorization/impersonation/impersonation-config.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -3. Here you can enable/disable the email notification. When enabled, an email notification will send to impersonated user. By default, this configuration is enabled. - - ![Impersonation-Email-Config]({{base_path}}/assets/img/guides/authorization/impersonation/impersonation-email-config.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -Following is the default template of impersonation notification. - -![Impersonation-Email-Notification]({{base_path}}/assets/img/guides/authorization/impersonation/impersonation-email-notification.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -!!! note - See [Customize email templates]({{base_path}}/guides/branding/customize-email-templates/#configure-email-templates) for more information about customise the email template according to your branding preferences. - -!!! note - If Impersonation email template not found in branding preferences, you can add it via following REST API request. - - **Sample Request Format** - - ``` - {% raw %} - curl --location 'https://{{ host_name }}/api/server/v1/email/template-types' \ - --header 'Content-Type: application/json' \ - --header 'Authorization: Basic ' \ - --data-raw '{ - "displayName": "Impersonation Email Notification", - "templates": [ - { - "contentType": "text/html", - "subject": "User Impersonation Session Started", - "body": "\n \n \n \n User Impersonation Session Started\n \n \n \n \n \n \n \n \n \n \n
\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n \n \n \n \n \n \n
Please click the following button to\n securely reset the password of your account in the organization\n {{organization-name}}:\n
\n
\n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n \"{{organization.logo.altText}}\"\n
\n \n User Impersonation Session Started\n \n
\n \n \n \n \n \n \n
\n
\n \n Hi {{user-name}},\n

\n \n We wanted to inform you that an impersonation session for your account {{user-name}} was initiated on {{login-time}} by {{impersonator-user-name}}. If you have any concerns, please contact\n {{organization.support.mail}}\n \n immediately.\n

\n
\n
\n \n {{organization.copyright.text}}\n

\n
\n
\n
\n
\n \n \n \n \n \n \n \n
\n

\n You\n received this email because you have an account in the\n organization\n {{organization-name}}. If you encounter any issues,\n you may contact us at\n {{organization.support.mail}}.\n \n

\n

\n This\n mail was sent by WSO2 LLC. 3080 Olcott St., Suite C220,\n Santa Clara, CA 95054, USA\n

\n
\n
\n \n
\n \n \n \n ", - "id": "en_US" - } - ] - }' - {% endraw %} - ``` -## Access protected resources using Impersonated Access token - -Impersonated access token can be used as same as generic access token to access protected resources as impersonated user. - -### Audit logs for Impersonation - -When a resource get modified using impersonated access token, an audit log will be printed expressing the details of the resource modification. These audit logs can be used to track actions performed by impersonation. - -**Audit log Format** -``` java -TID: [-1234] [2024-06-03 14:50:42,298] [1a2ac914-ea61-4699-8778-ea44d2fa27c5] INFO {AUDIT_LOG} - Initiator={Impersonated_User_Id} Action=resource-modification-via-impersonation Target={Impersonated_User_Id} Data={"ResourcePath":{Resource_Path} ,"clientId":{Client_Id} ,"subject":{Impersonated_User_Id},"scope":{Scope Issued for the Impersonated Access token} ,"impersonator":{Impersonater Id} ,"httpMethod":{Http Method} } Outcome=AUTHORIZED -``` - -**Sample Audit Log** -``` java -TID: [-1234] [2024-06-03 14:50:42,298] [1a2ac914-ea61-4699-8778-ea44d2fa27c5] INFO {AUDIT_LOG} - Initiator=0fa51985-d36d-4492-9ebd-298f9d68861f Action=resource-modification-via-impersonation Target=49de2b73-5f0b-44db-bf75-6fddec4b058e Data={"ResourcePath":"/scim2/Me","clientId":"luoljDTbHYcfx6YWT_7wsYs67rsa","subject":"49de2b73-5f0b-44db-bf75-6fddec4b058e","scope":"internal_login internal_user_mgt_list internal_user_mgt_view","impersonator":"0fa51985-d36d-4492-9ebd-298f9d68861f","httpMethod":"PATCH"} Outcome=AUTHORIZED -``` - -Addtionally all existing audits logs will be appended by Impersonater Id, if the resource accessed via impersonation. Following is the sample audit log when the user claim updated via Impersonation. - -``` java -TID: [-1234] [2024-06-03 14:50:42,976] [1a2ac914-ea61-4699-8778-ea44d2fa27c5] INFO {AUDIT_LOG} - Initiator=49de2b73-5f0b-44db-bf75-6fddec4b058e Action=Set-User-Claim-Values Target=t******r Data={"ServiceProviderName":"POSTMAN_SBA","Claims":{"http://wso2.org/claims/country":"S***n","http://wso2.org/claims/modified":"2*************************Z","profileConfiguration":"d*****t"}} Outcome=Success | Impersonator : 0fa51985-d36d-4492-9ebd-298f9d68861f -``` - -## Access protected resources of invited user in the sub organization. - -You can use the impersonated access token to exchange for a sub oirganization bound impersonated access token. To use this flow, impersonated user should be invited from parent organization. - -!!! note - To read about inviting users from parent organization check [Invite users from the parent organization]({{base_path}}/guides/organization-management/invite-parent-organization-users/) - -![Impersonation-sub-org]({{base_path}}/assets/img/guides/authorization/impersonation/impersonation-flow-sub-org.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -**Request Format** -``` bash -curl --location 'https://{{ host_name }}/oauth2/token' \ ---header 'Content-Type: application/x-www-form-urlencoded' \ ---header 'Authorization: Basic ' \ ---data-urlencode 'client_id={Client_Id}' \ ---data-urlencode 'grant_type=organization_switch' \ ---data-urlencode 'scope={Organization API Scopes}' \ ---data-urlencode 'switching_organization={Organization_Id}' \ ---data-urlencode 'token={Impersonated Access Token}' -``` - -**Sample Response** -``` json -{ - "access_token": "eyJ4NXQiOiJPV1JpTXpaaVlURXhZVEl4WkdGa05UVTJOVE0zTWpkaFltTmxNVFZrTnpRMU56a3paVGc1TVRrNE0yWmxOMkZoWkdaalpURmlNemxsTTJJM1l6ZzJNZyIsImtpZCI6Ik9XUmlNelppWVRFeFlUSXhaR0ZrTlRVMk5UTTNNamRoWW1ObE1UVmtOelExTnprelpUZzVNVGs0TTJabE4yRmhaR1pqWlRGaU16bGxNMkkzWXpnMk1nX1JTMjU2IiwidHlwIjoiYXQrand0IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIzMmJjNDY5Ny1lZDBmLTQ1NDYtODM4Ny1kY2Q2NDAzZTdjYWEiLCJhdXQiOiJBUFBMSUNBVElPTl9VU0VSIiwiaXNzIjoiaHR0cHM6XC9cL2xvY2FsaG9zdDo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiY2xpZW50X2lkIjoialZjVzRvTG4xSmpiMlQ5NEg0Z3RQVjl6NVkwYSIsImF1ZCI6ImpWY1c0b0xuMUpqYjJUOTRINGd0UFY5ejVZMGEiLCJ1c2VyX29yZyI6IjEwMDg0YThkLTExM2YtNDIxMS1hMGQ1LWVmZTM2YjA4MjIxMSIsIm5iZiI6MTcxODY5NTA3MiwiYWN0Ijp7InN1YiI6IjJkOTMxYzlkLTg3NmUtNDZjMC05YWJhLWYzNDUwMTg3OWRmYyJ9LCJhenAiOiJqVmNXNG9MbjFKamIyVDk0SDRndFBWOXo1WTBhIiwib3JnX2lkIjoiMTU1OGViZjYtMTdlMC00MTY1LWI5YzAtYTgxMTdjODc4MDZiIiwic2NvcGUiOiJpbnRlcm5hbF9sb2dpbiBpbnRlcm5hbF9vcmdfdXNlcl9tZ3RfbGlzdCBpbnRlcm5hbF9vcmdfdXNlcl9tZ3RfdmlldyIsImV4cCI6MTcxODY5ODY3Miwib3JnX25hbWUiOiJTdWJPcmciLCJpYXQiOjE3MTg2OTUwNzIsImp0aSI6IjA2NjcwOGYzLWQyNzYtNDQyMi1iZWZlLTE0Njk3N2RlMDA4ZiJ9.XliLCV0IS-KzYZTriSBpVacg-u4l0tLiRoBwWmjoyZz-9-LbCAf-oAweywpaWM7kwo6EaxCZ1S4Am5K1hh-R9Rp5RP1PouxL407MHd-gRpLU5x8V1c9PmofZgWNrrqWLgvxi-MjI-XRkFqMARf39tfBgqHcsZA8Ixeht8zN16EL4GTeYMWbcIuHPSDKaQ-_ZgOcoL1fim3ELUMc0N7Mtv4QGM8bHjhKUQV-wHrj6CRcx7TmyCcMyW1rqLpyqbnkbiOoUDlz0AvK_TxNVt4qhVsgS-9ZCmLb4fdIWTdsqAiZrM7Cfn1HT16PsGP0YTqz3AI3c_ZqTGuH867E6qxJpzg", - "scope": "internal_login internal_org_user_mgt_list internal_org_user_mgt_view", - "token_type": "Bearer", - "expires_in": 3600 -} -``` -Retrieved access token also has a claim **act** which holds the identity of the impersonator. Client can detect impersonation using **act** claim in the access token. - -## Extending Impersonation Authorization - -[ImpersonationValidator](https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/master/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/impersonation/validators/ImpersonationValidator.java) service used to entend custom impersonation validators. Currently following validators are engaged in Impersonation authorization flow. - -- SubjectScopeValidator - It checks the authorization scopes associated with the impersonation request to determine if the requested scopes are authorized for the impersonated user. - -- ImpersonatorPermissionValidator - This class validates whether an authenticated user has the necessary impersonation permissions within a given tenant and for a specified client. - -You can extend this validation process by adding custom validators as OSGi Service. +{% include "../../../../../../includes/guides/authorization/user-impersonation.md" %} \ No newline at end of file diff --git a/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png index 161e37eb2a..179ae373c9 100644 Binary files a/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png and b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png differ diff --git a/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/impersonation-email-config.png b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/impersonation-email-config.png index ebb9a8517b..b408201fd7 100644 Binary files a/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/impersonation-email-config.png and b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/impersonation-email-config.png differ diff --git a/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/role-creation.png b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/role-creation.png index 8d3cbe89c4..a4f73c9f8d 100644 Binary files a/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/role-creation.png and b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/role-creation.png differ diff --git a/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/subject-token-config.png b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/subject-token-config.png index cd98b40cfc..3c3758c9eb 100644 Binary files a/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/subject-token-config.png and b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/subject-token-config.png differ diff --git a/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/user-impersonation-selection.png b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/user-impersonation-selection.png new file mode 100644 index 0000000000..1ab3fbbaf6 Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/authorization/impersonation/user-impersonation-selection.png differ diff --git a/en/identity-server/next/docs/guides/authorization/api-authorization/api-authorization.md b/en/identity-server/next/docs/guides/authorization/api-authorization/api-authorization.md index 9c7f00798b..66695d26c3 100644 --- a/en/identity-server/next/docs/guides/authorization/api-authorization/api-authorization.md +++ b/en/identity-server/next/docs/guides/authorization/api-authorization/api-authorization.md @@ -1,2 +1 @@ -{% set product_name = "WSO2 Identity Server" %} -{% include "../../../../../../includes/guides/api-authorization.md" %} \ No newline at end of file +{% include "../../../../../../includes/guides/authorization/api-authorization.md" %} \ No newline at end of file diff --git a/en/identity-server/next/docs/guides/authorization/api-authorization/attribute-based-access-control.md b/en/identity-server/next/docs/guides/authorization/api-authorization/attribute-based-access-control.md index f4736130a8..c1a7f5150b 100644 --- a/en/identity-server/next/docs/guides/authorization/api-authorization/attribute-based-access-control.md +++ b/en/identity-server/next/docs/guides/authorization/api-authorization/attribute-based-access-control.md @@ -1,197 +1 @@ -# Validating the Scope of OAuth Access Tokens using XACML Policies - -WSO2 Identity Server (WSO2 IS) allows you to validate the scope of an -OAuth access token using XACML policies to provide fine-grained access -control to APIs. - -If you want the XACML scope validator to execute after checking the -validity of the access token in an OAuth access token validation flow, -you can select the scope validator as XACML when you configure a service -provider. This provides fine-grained access control to APIs. - -The following sections walk you through the basic steps -you need to follow to validate the scope of OAuth access tokens using -XACML policies. - -### Register the app - -Follow the steps given below to configure an application in WSO2 Identity -Server so that the authentication happens as expected. - -1. On the {{ product_name }} Console, go to **Applications**. -2. Click **New Application** and select **Standard-Based Application**. - ![Register a standard-based application]({{base_path}}/assets/img/guides/applications/register-an-sba.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} -3. Provide an application name and select the other options based on your requirements. - - !!! note - - You can choose OIDC or SAML as the standard protocol for your application. See the complete list of [OIDC]({{base_path}}/references/app-settings/oidc-settings-for-app/) and [SAML]({{base_path}}/references/app-settings/saml-settings-for-app/) configurations. - - If you use OIDC, you can authorize APIs to an app to access the APIs in {{ product_name }}. Learn about [Authorize the API resources for an app]({{base_path}}/guides/authorization/api-authorization/api-authorization/#authorize-the-api-resources-for-an-app). - -4. Click **Register** to complete the registration. -5. After the application is registered, you will be redirected into the application. -6. Do the required changes to the application and click **Update**. -7. Get the created application's inbound protocol (OAuth2 / OIDC) configurations - by using the following REST API call. - - ```java - curl --location 'https://localhost:9443/t//api/server/v1/applications//inbound-protocols/oidc' \ - --header 'Authorization: Basic YWRtaW46YWRtaW4=' - ``` - -8. Copy the response of the above REST API call and add the following value to the - `scopeValidators` array in the response. - - ```json - "scopeValidators": [ - "XACML Scope Validator" - ] - ``` - -9. Execute the Inbound Protocols PUT REST API call to update the application with the - XACML scope validator which added in the step 7. You can get the API call details from - Update OIDC authentication protocol parameters. - -### Register an API resource and Authorize for an app - -1. Go to the **API Resources** and click **New API Resource**. -2. Add the relevant details to Basic Details, Scopes, Authorization sections and click **Create**. -3. Go to the **API Authorization** tab in the created application. -4. Click **Authorize an API Resource**, select the created API resource, scopes and click **Finish**. - - !!!note - For more information on API Authorization, see [here](../api-authorization/api-authorization.md) - -### Create a user and a role - -1. Go to **User Management** > **Users**. -2. Click **Add User** button and select **Single User** option. -3. Provide the relevant details and click **Save & Continue**. -4. Go to the **User Management** > **Roles**. -5. Click **New Role**, add the Basic Details, Permission Selection and click **Finish**. -6. Go to the **Users** tab of the created role and assign the created user to the role. - - !!!note - For more information on User Management, see [here](../../users/index.md) - -The next step is to configure the XACML policy to validate the XACML scope during OAuth -token issuance. - -### Set up the policy - -Follow the instructions given below to publish a policy using a XACML policy -template that is available by default with WSO2 Identity Server. - -1. Log in to the Management Console via . -2. In the **Main** tab of the Management Console, navigate to - **PAP** \> **Policy Administration** under the **Entitlement** menu. -3. Select the `scope_based_token_issuance_policy_template` - policy, and click **Edit** to view the selected policy in the policy - editor. - - - !!! info - XACML template policies provide a pre-configured template with place - holders to customize the policy depending on your requirement. - - -4. Edit the policy to customize it depending on your requirement. You - can change the values of attributes and rules. -5. Click **Save Policy** to save the changes. You can see the policy - that you created on the policy list (the original policy template - remains unchanged). -6. Click the link **Publish to My PDP** corresponding to the new - policy. -7. On the UI that appears, leave the default values as they are and - click **Publish**. - - To ensure that the policy has been published successfully, click on - **Policy View** under the **Entitlement \> PDP** section on the - **Main** tab of the Management Console, and check if the created - policy is listed. - -Now, you have created the policy and enforced it using the policy -template. You can test the policy to evaluate whether XACML scope is -validated at the time of OAuth token issuance. - -### Try it out - -Follow the steps given below to try out the policy using the above created application. - -1. On the {{ product_name }} Console, go to **Applications**. -2. Select your application, go to the **Protocols** tab of the application and enable the **Password** grant type. -3. Execute the following cURL command to get an access token using the password grant type. - -```java -curl --location 'https://localhost:9443/t//oauth2/token' \ ---header 'Content-Type: application/x-www-form-urlencoded' \ ---header 'Authorization: Basic ' \ ---data-urlencode 'grant_type=password' \ ---data-urlencode 'username=' \ ---data-urlencode 'password=' \ ---data-urlencode 'scope=openid SCOPE_1' -``` -If the token request can be permitted by the policy, the response will contain an access token. -If the token request is denied by the policy, the response will contain an error message. - -Follow the steps below to try out the policy using the XACML TryIt tool. - -!!! tip - The XACML TryIt tool allows you to test policies easily without having - to create and send authorization requests to WSO2 IS. It is a tool - through which authorization requests can be created and evaluated - against available policies. You can write simple XACML 3.0 requests in - XML format and try them using the web UI of the TryIt tool. - -1. On the Management Console, click **Tools**, and then click - **TryIt** under the **XACML** section. - -2. Click **Create Request Using Editor**. - -3. Specify the following as the sample request: - - ``` java - - - - test_server - - - - - scope_validation - - - - - openid - - - SCOPE_1 - - - - - @ - - - - - - - - - - - - - - - - - - ``` - -4. Click **Evaluate With PDP**. You will see a response message that - says either `Permit` or `Deny` - depending on whether the XACML scope is validated or not at the time - of OAuth token validation. +{% include "../../../../../../includes/guides/authorization/attribute-based-access-control.md" %} \ No newline at end of file diff --git a/en/identity-server/next/docs/guides/authorization/fine-grained-authorization/rule-based-provisioning.md b/en/identity-server/next/docs/guides/authorization/fine-grained-authorization/rule-based-provisioning.md index f913daa15f..7fcb3ce079 100644 --- a/en/identity-server/next/docs/guides/authorization/fine-grained-authorization/rule-based-provisioning.md +++ b/en/identity-server/next/docs/guides/authorization/fine-grained-authorization/rule-based-provisioning.md @@ -1,188 +1 @@ -# Configure rule-based provisioning - -This page guides you through provisioning users based on defined XACML rules. - -To get a better understanding of rule-based provisioning, consider a scenario where you need to provision users assigned to the finance role from WSO2 Identity Server to the GoogleIDP. To implement this scenario, you can define a XACML policy that permits the provisioning operation if the provisioning user is assigned the finance role. - -Follow the steps given below to configure rule-based provisioning in WSO2 Identity Server. - -## Sample scenario - -Let's assume we need to provision users based on their email domain and restrict the provisioning of users who do not have the email attribute with the permitted domain (`@abc.com`). Let's create a XACML policy to implement this scenario. - -## Setting up the {{ product_name }} - -### Prerequisites -Setup outbound provisioning using the desired outbound provisioning connector ([Google]({{base_path}}/guides/users/outbound-provisioning/outbound-connectors/google/), [Salesforce]({{base_path}}/guides/users/outbound-provisioning/outbound-connectors/salesforce/) or [SCIM2]({{base_path}}/guides/users/outbound-provisioning/outbound-connectors/scim2/)). - -### Configure the resident service provider - -You need to enable rules in the outbound provisioning connector you have added to the resident service provider. This can be done using the following API: -```java -curl --location --request PUT 'https://localhost:9443/api/server/v1/applications/resident' \ ---header 'accept: application/json' \ ---header 'Authorization: Basic YWRtaW46YWRtaW4=' \ ---header 'Content-Type: application/json' \ ---data '{ - "outboundProvisioningIdps": [ - { - "idp": , - "connector": "SCIM2", - "blocking": false, - "rules": true, - "jit": false - } - ] -}' -``` - -Replace the `` with the name of the outbound provisioning connector you have registered in the earlier step. - -### Configure the service provider - -If you have configured outbound provisioning in your application, you should **Enable rules** in the outbound provisioning connector. This can be done using the following API: - -```java -curl --location --request PATCH 'https://localhost:9443/api/server/v1/applications/' \ ---header 'accept: application/json' \ ---header 'Authorization: Basic YWRtaW46YWRtaW4=' \ ---header 'Content-Type: application/json' \ ---data '{ - "provisioningConfigurations": { - "outboundProvisioningIdps": [ - { - "idp": , - "connector": "SCIM2", - "blocking": false, - "rules": true, - "jit": false - } - ] - } -}' -``` - -Replace the `` with the name of the outbound provisioning connector you have registered in the earlier step. - -Use the [application API]({{base_path}}/apis/application-rest-api/#tag/Applications/operation/getAllApplications) to find the application ID of your application and replace the `` with it. - - -## Set up XACML rules - -1. Log in to the Management Console(`https://:/carbon`) using admin/admin credentials. -2. Click on **Policy Administration** under the **Entitlement** > **PAP** section on the **Main** tab of the management console. -3. Since this sample scenario is based on the email address user claim, we need to select the policy `provisioning_user_claim_based_policy_template`. - ![Policy list]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} -4. Once you click **Edit**, the XML based policy will appear in the policy editor. There are placeholders in capitals for entering the service provider and role names. -5. Edit the placeholders accordingly with the relevant values. - 1. Change the `PolicyId` as follows: - ```xml - PolicyId="provisioning_user_claim_based_policy" - ``` - 2. Edit the `` tag and enter a description relevant to your custom policy. - 3. Locate the `IDP_NAME` placeholder and replace it with the identity provider name you have created earlier. - 4. Since we need to do a regex match on the email claim, change the condition of the rules as follows: - ```xml - - - - .*@abc\.com$ - - - - - - - ``` - 5. Since we are using only one user claim for this policy, remove the other claim by removing that entire section from the start of the `` tag to the ending `` tag. This should be edited in both POST and PUT sections as the provisioning is initiated when creating the user and when updating the user as well. - 6. Also for this example, we do not need a service provider. Therefore, we need to remove the service provider `SP_NAME` match block as well. -6. Once the changes have been made, the policy should be similar to the following. -```xml - -This template policy provides ability to authorize provisioning requests initiated from a given service provider(defined by SP_NAME) to a given identity provider(defined by IDP_NAME) in the outbound provisioning flow based on the claim values of the user (CLAIM_URI_1=CLAIM_VALUE_1 and CLAIM_URI_2=CLAIM_VALUE_2). Users with the given claim values will be allowed and any other users will be denied. - - - - -WSO2IDP - - - - -provisioning - - - - - - - - - - - -POST - - - - - - - - - -.*@wso2\.com$ - - - - - - - - - - - - - -PUT - - - - - - - - - - - - - -test@abc.com - - - - - - - -``` - -7. Click **Save Policy** to save the changes. You can see the policy you just created on the policy list (the original template policy will remain unchanged for later use). - ![Saved policy list]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy-saved.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -8. Click on the **Publish to My PDP** link corresponding to the new policy. - ![Publish To My PDP icon]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy-to-publish.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -9. On the UI that appears, leave the default selected values as they are and click **Publish**. -10. Click on **Policy View** under the **Entitlement>PDP** section on the **Main** tab of the management console. -11. To ensure that the policy has been published successfully, check if the policy is listed. - ![Published policy]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy-published.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} -12. To test out whether the policy works, follow the **Try it** out section. - - -## Try it out - -Once the policies are published to PDP, they are ready to execute during outbound provisioning. You can test rule-based provisioning by creating a user in WSO2 Identity Server that matches the rules you enforced. -For example, when you create a user with the email `"jane@abc.com"` in WSO2 Identity Server, it should be provisioned to the external IDP you have configured for outbound provisioning as well. A user who does not have an email with the domain `@abc.com` should not be provisioned. \ No newline at end of file +{% include "../../../../../../includes/guides/authorization/fine-grained-authorization/rule-based-provisioning.md" %} \ No newline at end of file diff --git a/en/identity-server/next/docs/guides/authorization/impersonation/user-impersonation.md b/en/identity-server/next/docs/guides/authorization/impersonation/user-impersonation.md index a4b3ba5bad..8a6e3e98eb 100644 --- a/en/identity-server/next/docs/guides/authorization/impersonation/user-impersonation.md +++ b/en/identity-server/next/docs/guides/authorization/impersonation/user-impersonation.md @@ -1,257 +1,4 @@ -# User Impersonation +{% set base_url = "localhost:9443" %} +{% set base_url_sample = "localhost:9443" %} -User impersonation involves an authorization server’s ability to temporarily grant access to another user's account. With this feature, a user with required permission can impersonate any user within the organization. - -## Setting up the {{ product_name }} - -### Configure the application - -#### Subscribe to Impersonation API - -1. On the {{ product_name }} Console, go to **Applications**. - -2. Select the application and go to API Authorization tab of the application and click authorize API Resource. - -3. Search for User Impersonation under management APIs and subscribe to the application. - - ![Api-Authorization-Impersonation]({{base_path}}/assets/img/guides/authorization/impersonation/api-authorization-impersonation.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -4. Switch to the Roles tab, click on **+ New Role** to create a Role and assign the Impersonation Scope. - - ![Role-Creation]({{base_path}}/assets/img/guides/authorization/impersonation/role-creation.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -5. Create a User and assign to the Role. - -!!! note - To read about subscribing APIs and authorize using Role Based Access Control (RBAC) check [Role-based access control (RBAC)]({{base_path}}/guides/authorization/api-authorization/api-authorization/) - -#### Configure Subject token for the application - -1. On the {{ product_name }} Console, go to **Applications**. - -2. Select the application and go to Protocol tab. - -3. Enable **Token Exchange** grant type. - -4. Enable subject token. - -5. [Optional] Configure Subject token expiry time by default it is 3 minutes. - - ![Subject-Token-Config]({{base_path}}/assets/img/guides/authorization/impersonation/subject-token-config.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -6. Enable **JWT type** Access token. - -#### Apply application advanced configuration - -1. Select the application and go to Application Advanced tab. - -2. Enable skip login consent and Enable skip logout consent. - -## Impersonating a User - -Impersonating a user involves two step process. - -1. Acquire Subject token from Authorize endpoint. - -2. Exchange subject token for impersonated access token using Token Exchange grant type. - - ![Impersonation-Flow]({{base_path}}/assets/img/guides/authorization/impersonation/Impersonation-flow.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -### Acquire Subject Token - -A security JWT token that represents the identity of both parties Impersonator and End-User. Subject token can be used to exchange impersonated access token. To obtain subject token, client need to initiate an authorize call with following query parameters. - -**Request Format** -``` bash -https://{{ host_name }}/oauth2/authorize?response_type=code&redirect_uri={redirect_uri}&client_id={client_id}state=&scope=internal_user_impersonate%20{Other_Required_Scopes}&response_type=id_token%20subject_token&requested_subject={User_id_of_the_end_user}&nonce={nonce} -``` - -**Sample Request** -``` bash -https://localhost:9443/oauth2/authorize?client_id=jVcW4oLn1Jjb2T94H4gtPV9z5Y0a&state=sample_state&scope=internal_user_impersonate%20openid%20internal_org_user_mgt_view%20internal_org_user_mgt_list%20internal_user_mgt_delete%20internal_org_user_mgt_create%20internal_login%20internal_user_mgt_delete%20internal_user_mgt_view%20internal_user_mgt_list%20internal_user_mgt_update%20internal_user_mgt_create%20readBooking%0A&redirect_uri=https%3A%2F%2Foauth.pstmn.io%2Fv1%2Fcallback&response_type=id_token%20subject_token&requested_subject=32bc4697-ed0f-4546-8387-dcd6403e7caa&nonce=2131232 -``` - -**Sample Response after sucessful authorization** -``` bash -https://oauth.pstmn.io/v1/callback#id_token={id_token}&session_state=ecfb74cde9f694c1de0905aa40a5f6fc1dd595bdcfd739cbd3dd5b964da53325.1554z-G22KW3pwK_hYhqPw&state=sample&subject_token={subject_token} -``` - - -!!! note - - In Subject token requrest, - - - Response type can be **id_token subject_token** or **subject_token**. - - Scope should contain **internal_user_impersonate** scope with other required scopes. - - Requested_subject should be a valid user id. - - Authorizing user should have a role that is associated with Impersonation permission related to the application. - - Nonce is required if you re using “id_token subject_token” response type. - - -#### JWT cliams of Subject Token - -Apart from generic claims, subject token has a claim **may_act**. The **may_act** claim makes a statement that one party is authorized to become the actor and act on behalf of another party. Here **sub** id inside **may_act** claim hold the identity of the impersoator. - - -``` json -{ - "sub": "32bc4697-ed0f-4546-8387-dcd6403e7caa", - "aud": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "nbf": 1718694997, - "azp": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "scope": "internal_login internal_org_user_mgt_list internal_org_user_mgt_view internal_user_mgt_list internal_user_mgt_view", - "iss": "https://localhost:9443/oauth2/token", - "may_act": { - "sub": "2d931c9d-876e-46c0-9aba-f34501879dfc" - }, - "exp": 1718712997, - "iat": 1718694997, - "jti": "66dff3b0-2828-4bc0-8a27-84aa9bd3ebdb", - "client_id": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a" -} -``` - -### Acquire Impersonated Access Token - -Token exchange grant type can be used exchange subject for an impersonated access token. - -**Request Format** -``` bash -curl --location 'https://{{ host_name }}/oauth2/token' \ ---header 'Content-Type: application/x-www-form-urlencoded' \ ---header 'Authorization: Basic ' \ ---data-urlencode 'subject_token={subeject_token}' \ ---data-urlencode 'subject_token_type=urn:ietf:params:oauth:token-type:jwt' \ ---data-urlencode 'requested_token_type=urn:ietf:params:oauth:token-type:access_token' \ ---data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \ ---data-urlencode 'actor_token={id_token}' \ ---data-urlencode 'actor_token_type=urn:ietf:params:oauth:token-type:id_token' -``` - -**Sample Response** -``` json -{ - "access_token": "eyJ4NXQiOiJPV1JpTXpaaVlURXhZVEl4WkdGa05UVTJOVE0zTWpkaFltTmxNVFZrTnpRMU56a3paVGc1TVRrNE0yWmxOMkZoWkdaalpURmlNemxsTTJJM1l6ZzJNZyIsImtpZCI6Ik9XUmlNelppWVRFeFlUSXhaR0ZrTlRVMk5UTTNNamRoWW1ObE1UVmtOelExTnprelpUZzVNVGs0TTJabE4yRmhaR1pqWlRGaU16bGxNMkkzWXpnMk1nX1JTMjU2IiwidHlwIjoiYXQrand0IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIzMmJjNDY5Ny1lZDBmLTQ1NDYtODM4Ny1kY2Q2NDAzZTdjYWEiLCJhdXQiOiJBUFBMSUNBVElPTl9VU0VSIiwiaXNzIjoiaHR0cHM6XC9cL2xvY2FsaG9zdDo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiY2xpZW50X2lkIjoialZjVzRvTG4xSmpiMlQ5NEg0Z3RQVjl6NVkwYSIsImF1ZCI6ImpWY1c0b0xuMUpqYjJUOTRINGd0UFY5ejVZMGEiLCJuYmYiOjE3MTg2OTUwNTIsImFjdCI6eyJzdWIiOiIyZDkzMWM5ZC04NzZlLTQ2YzAtOWFiYS1mMzQ1MDE4NzlkZmMifSwiYXpwIjoialZjVzRvTG4xSmpiMlQ5NEg0Z3RQVjl6NVkwYSIsIm9yZ19pZCI6IjEwMDg0YThkLTExM2YtNDIxMS1hMGQ1LWVmZTM2YjA4MjIxMSIsInNjb3BlIjoiaW50ZXJuYWxfbG9naW4gaW50ZXJuYWxfb3JnX3VzZXJfbWd0X2xpc3QgaW50ZXJuYWxfb3JnX3VzZXJfbWd0X3ZpZXcgaW50ZXJuYWxfdXNlcl9tZ3RfbGlzdCBpbnRlcm5hbF91c2VyX21ndF92aWV3IG9wZW5pZCIsImV4cCI6MTcxODY5ODY1Miwib3JnX25hbWUiOiJTdXBlciIsImlhdCI6MTcxODY5NTA1MiwianRpIjoiMDcyOGQ1MTctNzk2OC00NzRmLWJkN2QtMTI1MzdjY2JlNDM2In0.FqavHBDNLo-nMMgJ3OTDswo7pl6zMztpUkm-cgBOgDJPek_FAEQzt4DFxGglnf2-AtnRN14wPOv9_M_DYJWH529hbwYBVrQQDlJmcF1WtWX_MnBgBGsIfA5_3nzocZWBqj5KDjbXS3_3CSexQ9_h3tKWCDX1oit03flcs7E_xG_nkWV1TUPFUAaoHrMWTROIttN1iFqwRjeg6Bkqjx8hHM3Dn7E9Zsmby0EhuC7i41kid2s9F_5XPPMCYM0gyxX5lAjsf6UFth9v3SWIuMLFgiq5Eh6u4pCs9srh2A5t0DIcKMwyXTEm-QVIhGi1zkB-wGV6yYD9TwbiujnrqOyFQA", - "issued_token_type": "urn:ietf:params:oauth:token-type:access_token", - "scope": "internal_login internal_org_user_mgt_list internal_org_user_mgt_view internal_user_mgt_list internal_user_mgt_view", - "token_type": "Bearer", - "expires_in": 3600 -} -``` - -#### JWT cliams of Impersonated Access Token - -Apart from generic claims, impersonated access token has a claim **act**. The **act** (actor) claim provides a means within a JWT to express that impersonation has occurred and identify the acting party to whom authority has been impersonated. The act claim value is a JSON object, Here **sub** id inside **act** claim hold the identity of the actor. - -``` json - -{ - "sub": "32bc4697-ed0f-4546-8387-dcd6403e7caa", - "aut": "APPLICATION_USER", - "iss": "https://localhost:9443/oauth2/token", - "client_id": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "aud": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "nbf": 1718695052, - "act": { - "sub": "2d931c9d-876e-46c0-9aba-f34501879dfc" - }, - "azp": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", - "org_id": "10084a8d-113f-4211-a0d5-efe36b082211", - "scope": "internal_login internal_org_user_mgt_list internal_org_user_mgt_view internal_user_mgt_list internal_user_mgt_view", - "exp": 1718698652, - "org_name": "Super", - "iat": 1718695052, - "jti": "0728d517-7968-474f-bd7d-12537ccbe436" -} - -``` - -The sub claim is the impersonated user (32bc4697-ed0f-4546-8387-dcd6403e7caa), while act.sub contains the ID of the impersonator (2d931c9d-876e-46c0-9aba-f34501879dfc). Client can detect impersonation using **act** claim in the access token. - -### Email Notification for impersonated user - -Once impersonated access token obtained, Authorization server will send an email notification to impersonated user. - -#### Configure Impersonation Email Notification - -1. Go to Login and Registration section. - -2. Select Impersonation Configurations under Organizations settings. - - ![Impersonation-Config]({{base_path}}/assets/img/guides/authorization/impersonation/impersonation-config.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -3. Here you can enable/disable the email notification. When enabled, an email notification will send to impersonated user. By default, this configuration is enabled. - - ![Impersonation-Email-Config]({{base_path}}/assets/img/guides/authorization/impersonation/impersonation-email-config.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -Following is the default template of impersonation notification. - -![Impersonation-Email-Notification]({{base_path}}/assets/img/guides/authorization/impersonation/impersonation-email-notification.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -!!! note - See [Customize email templates]({{base_path}}/guides/branding/customize-email-templates/#configure-email-templates) for more information about customise the email template according to your branding preferences. - -## Access protected resources using Impersonated Access token - -Impersonated access token can be used as same as generic access token to access protected resources as impersonated user. - -### Audit logs for Impersonation - -When a resource get modified using impersonated access token, an audit log will be printed expressing the details of the resource modification. These audit logs can be used to track actions performed by impersonation. - -**Audit log Format** -``` java -TID: [-1234] [2024-06-03 14:50:42,298] [1a2ac914-ea61-4699-8778-ea44d2fa27c5] INFO {AUDIT_LOG} - Initiator={Impersonated_User_Id} Action=resource-modification-via-impersonation Target={Impersonated_User_Id} Data={"ResourcePath":{Resource_Path} ,"clientId":{Client_Id} ,"subject":{Impersonated_User_Id},"scope":{Scope Issued for the Impersonated Access token} ,"impersonator":{Impersonater Id} ,"httpMethod":{Http Method} } Outcome=AUTHORIZED -``` - -**Sample Audit Log** -``` java -TID: [-1234] [2024-06-03 14:50:42,298] [1a2ac914-ea61-4699-8778-ea44d2fa27c5] INFO {AUDIT_LOG} - Initiator=0fa51985-d36d-4492-9ebd-298f9d68861f Action=resource-modification-via-impersonation Target=49de2b73-5f0b-44db-bf75-6fddec4b058e Data={"ResourcePath":"/scim2/Me","clientId":"luoljDTbHYcfx6YWT_7wsYs67rsa","subject":"49de2b73-5f0b-44db-bf75-6fddec4b058e","scope":"internal_login internal_user_mgt_list internal_user_mgt_view","impersonator":"0fa51985-d36d-4492-9ebd-298f9d68861f","httpMethod":"PATCH"} Outcome=AUTHORIZED -``` - -Addtionally all existing audits logs will be appended by Impersonater Id, if the resource accessed via impersonation. Following is the sample audit log when the user claim updated via Impersonation. - -``` java -TID: [-1234] [2024-06-03 14:50:42,976] [1a2ac914-ea61-4699-8778-ea44d2fa27c5] INFO {AUDIT_LOG} - Initiator=49de2b73-5f0b-44db-bf75-6fddec4b058e Action=Set-User-Claim-Values Target=t******r Data={"ServiceProviderName":"POSTMAN_SBA","Claims":{"http://wso2.org/claims/country":"S***n","http://wso2.org/claims/modified":"2*************************Z","profileConfiguration":"d*****t"}} Outcome=Success | Impersonator : 0fa51985-d36d-4492-9ebd-298f9d68861f -``` - -## Access protected resources of invited user in the sub organization. - -You can use the impersonated access token to exchange for a sub oirganization bound impersonated access token. To use this flow, impersonated user should be invited from parent organization. - -!!! note - To read about inviting users from parent organization check [Invite users from the parent organization]({{base_path}}/guides/organization-management/invite-parent-organization-users/) - -![Impersonation-sub-org]({{base_path}}/assets/img/guides/authorization/impersonation/impersonation-flow-sub-org.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} - -**Request Format** -``` bash -curl --location 'https://{{ host_name }}/oauth2/token' \ ---header 'Content-Type: application/x-www-form-urlencoded' \ ---header 'Authorization: Basic ' \ ---data-urlencode 'client_id={Client_Id}' \ ---data-urlencode 'grant_type=organization_switch' \ ---data-urlencode 'scope={Organization API Scopes}' \ ---data-urlencode 'switching_organization={Organization_Id}' \ ---data-urlencode 'token={Impersonated Access Token}' -``` - -**Sample Response** -``` json -{ - "access_token": "eyJ4NXQiOiJPV1JpTXpaaVlURXhZVEl4WkdGa05UVTJOVE0zTWpkaFltTmxNVFZrTnpRMU56a3paVGc1TVRrNE0yWmxOMkZoWkdaalpURmlNemxsTTJJM1l6ZzJNZyIsImtpZCI6Ik9XUmlNelppWVRFeFlUSXhaR0ZrTlRVMk5UTTNNamRoWW1ObE1UVmtOelExTnprelpUZzVNVGs0TTJabE4yRmhaR1pqWlRGaU16bGxNMkkzWXpnMk1nX1JTMjU2IiwidHlwIjoiYXQrand0IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIzMmJjNDY5Ny1lZDBmLTQ1NDYtODM4Ny1kY2Q2NDAzZTdjYWEiLCJhdXQiOiJBUFBMSUNBVElPTl9VU0VSIiwiaXNzIjoiaHR0cHM6XC9cL2xvY2FsaG9zdDo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiY2xpZW50X2lkIjoialZjVzRvTG4xSmpiMlQ5NEg0Z3RQVjl6NVkwYSIsImF1ZCI6ImpWY1c0b0xuMUpqYjJUOTRINGd0UFY5ejVZMGEiLCJ1c2VyX29yZyI6IjEwMDg0YThkLTExM2YtNDIxMS1hMGQ1LWVmZTM2YjA4MjIxMSIsIm5iZiI6MTcxODY5NTA3MiwiYWN0Ijp7InN1YiI6IjJkOTMxYzlkLTg3NmUtNDZjMC05YWJhLWYzNDUwMTg3OWRmYyJ9LCJhenAiOiJqVmNXNG9MbjFKamIyVDk0SDRndFBWOXo1WTBhIiwib3JnX2lkIjoiMTU1OGViZjYtMTdlMC00MTY1LWI5YzAtYTgxMTdjODc4MDZiIiwic2NvcGUiOiJpbnRlcm5hbF9sb2dpbiBpbnRlcm5hbF9vcmdfdXNlcl9tZ3RfbGlzdCBpbnRlcm5hbF9vcmdfdXNlcl9tZ3RfdmlldyIsImV4cCI6MTcxODY5ODY3Miwib3JnX25hbWUiOiJTdWJPcmciLCJpYXQiOjE3MTg2OTUwNzIsImp0aSI6IjA2NjcwOGYzLWQyNzYtNDQyMi1iZWZlLTE0Njk3N2RlMDA4ZiJ9.XliLCV0IS-KzYZTriSBpVacg-u4l0tLiRoBwWmjoyZz-9-LbCAf-oAweywpaWM7kwo6EaxCZ1S4Am5K1hh-R9Rp5RP1PouxL407MHd-gRpLU5x8V1c9PmofZgWNrrqWLgvxi-MjI-XRkFqMARf39tfBgqHcsZA8Ixeht8zN16EL4GTeYMWbcIuHPSDKaQ-_ZgOcoL1fim3ELUMc0N7Mtv4QGM8bHjhKUQV-wHrj6CRcx7TmyCcMyW1rqLpyqbnkbiOoUDlz0AvK_TxNVt4qhVsgS-9ZCmLb4fdIWTdsqAiZrM7Cfn1HT16PsGP0YTqz3AI3c_ZqTGuH867E6qxJpzg", - "scope": "internal_login internal_org_user_mgt_list internal_org_user_mgt_view", - "token_type": "Bearer", - "expires_in": 3600 -} -``` -Retrieved access token also has a claim **act** which holds the identity of the impersonator. Client can detect impersonation using **act** claim in the access token. - -## Extending Impersonation Authorization - -[ImpersonationValidator](https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/master/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/impersonation/validators/ImpersonationValidator.java) service used to entend custom impersonation validators. Currently following validators are engaged in Impersonation authorization flow. - -- SubjectScopeValidator - It checks the authorization scopes associated with the impersonation request to determine if the requested scopes are authorized for the impersonated user. - -- ImpersonatorPermissionValidator - This class validates whether an authenticated user has the necessary impersonation permissions within a given tenant and for a specified client. - -You can extend this validation process by adding custom validators as OSGi Service. +{% include "../../../../../../includes/guides/authorization/user-impersonation.md" %} \ No newline at end of file diff --git a/en/identity-server/next/docs/guides/identity-verification/add-identity-verification-provider.md b/en/identity-server/next/docs/guides/identity-verification/configure-identity-verification-provider.md similarity index 57% rename from en/identity-server/next/docs/guides/identity-verification/add-identity-verification-provider.md rename to en/identity-server/next/docs/guides/identity-verification/configure-identity-verification-provider.md index 8b7782f2ad..6875d28aeb 100644 --- a/en/identity-server/next/docs/guides/identity-verification/add-identity-verification-provider.md +++ b/en/identity-server/next/docs/guides/identity-verification/configure-identity-verification-provider.md @@ -1 +1 @@ -{% include "../../../../../includes/guides/identity-verification/add-identity-verification-provider.md" %} +{% include "../../../../../includes/guides/identity-verification/configure-identity-verification-provider.md" %} \ No newline at end of file diff --git a/en/identity-server/next/docs/guides/identity-verification/manage-identity-verification-provider.md b/en/identity-server/next/docs/guides/identity-verification/manage-identity-verification-provider.md deleted file mode 100644 index 5c5f1ec7d0..0000000000 --- a/en/identity-server/next/docs/guides/identity-verification/manage-identity-verification-provider.md +++ /dev/null @@ -1 +0,0 @@ -{% include "../../../../../includes/guides/identity-verification/manage-identity-verification-provider.md" %} diff --git a/en/identity-server/next/mkdocs.yml b/en/identity-server/next/mkdocs.yml index 90882ed510..c2fd5be424 100644 --- a/en/identity-server/next/mkdocs.yml +++ b/en/identity-server/next/mkdocs.yml @@ -47,7 +47,7 @@ plugins: 'guides/authentication/enterprise-login/index.md': 'guides/authentication/standard-based-login/index.md' 'guides/authentication/enterprise-login/add-oidc-idp-login.md': 'guides/authentication/standard-based-login/add-oidc-idp-login.md' 'guides/authentication/enterprise-login/add-saml-idp-login.md': 'guides/authentication/standard-based-login/add-saml-idp-login.md' - 'guides/request-path-auth/request-paths-overview.md': 'guides/authentication//app-native-authentication/add-app-native-authentication.md' + 'guides/request-path-auth/request-paths-overview.md': 'guides/authentication/app-native-authentication/add-app-native-authentication.md' 'guides/request-path-auth/oauth-request-path.md': 'guides/authentication/app-native-authentication/add-app-native-authentication.md' 'guides/authentication/add-application-native-login.md': 'guides/authentication/app-native-authentication/add-app-native-authentication.md' 'guides/passwordless/overview.md': 'guides/authentication/passwordless-login.md' @@ -137,7 +137,6 @@ plugins: 'guides/password-mgt/password-policies.md': 'guides/account-configurations/login-security/password-validation.md' 'guides/password-mgt/forced-password-reset.md': 'guides/account-configurations/account-recovery/admin-initiated-password-reset.md' 'guides/password-mgt/recover-password.md': 'guides/user-self-service/user-password-recovery.md' - 'guides/identity-lifecycles/provisioning-overview.md': 'guides/users/manage-users.md' 'guides/identity-lifecycles/provisioning-patterns.md': 'guides/users/manage-users.md' 'guides/identity-lifecycles/role-based-provisioning.md': 'guides/users/manage-roles.md' @@ -157,7 +156,6 @@ plugins: 'guides/identity-lifecycles/self-register-verification.md': 'guides/account-configurations/user-onboarding/self-registration.md' 'guides/identity-lifecycles/enable-email-account-verification-for-an-updated-email-address.md': 'guides/users/attributes/manage-attributes.md' 'guides/identity-lifecycles/enable-verification-for-updated-mobile-number.md': 'guides/users/attributes/manage-attributes.md' - 'guides/my-account/my-account.md': 'guides/user-self-service/configure-self-service-portal.md' 'guides/user-self-service/customer-self-service-portal.md': 'guides/user-self-service/configure-self-service-portal.md' 'guides/my-account/manage-own-profile.md': 'guides/user-self-service/update-profile-info.md' @@ -178,7 +176,6 @@ plugins: 'guides/analytics/analyzing-login-attempts.md': 'guides/analytics/elk-analytics/analyzing-login-attempts.md' 'guides/analytics/analyzing-active-sessions.md': 'guides/analytics/elk-analytics/analyzing-active-sessions.md' 'guides/analytics/elk-alert-types.md': 'guides/analytics/elk-analytics/elk-alert-types.md' - 'guides/dialects/dialects-overview.md': 'guides/users/attributes/index.md' 'guides/dialects/add-claim-dialects.md': 'guides/users/attributes/manage-attributes.md' 'guides/dialects/edit-claim-dialects.md': 'guides/users/attributes/manage-attributes.md' @@ -189,11 +186,9 @@ plugins: 'guides/dialects/delete-claim-mapping.md': 'guides/users/attributes/manage-attributes.md' 'guides/dialects/configure-unique-claims.md': 'guides/users/attributes/configure-unique-attributes.md' 'guides/identity-lifecycles/enable-email-as-username.md': 'guides/users/attributes/enable-email-as-username.md' - 'guides/users/manage-collaborators.md': 'guides/users/manage-administrators.md' 'guides/users/manage-customers.md': 'guides/users/manage-users.md' 'guides/user-self-service/register-security-key.md': 'guides/user-self-service/register-passkey.md' - 'deploy/get-started/get-started-with-the-management-console.md': 'guides/your-is/manage-console-access.md' 'deploy/get-started/customize-the-management-console.md': 'guides/your-is/manage-console-access.md' 'guides/mfa/mfa-for-management-console.md': 'guides/your-is/manage-console-access.md' @@ -221,8 +216,8 @@ plugins: 'deploy/change-to-remote-h2.md': 'deploy/configure/databases/carbon-database/change-to-remote-h2.md' 'deploy/change-datasource-bpsds.md': 'deploy/configure/databases/carbon-database/change-datasource-bpsds.md' 'deploy/change-datasource-consent-management.md': 'deploy/configure/databases/carbon-database/change-datasource-consent-management.md' - 'deploy/enable-fips-for-is.md': 'deploy/security/enable-fips-for-is.md' + 'deploy/enable-fips-for-is.md': 'deploy/security/enable-fips-for-is.md' 'apis/overview.md': 'apis/index.md' 'apis/idp-rest-api.md': 'apis/idp.md' 'apis/scim-1.1-apis.md': 'apis/scim2-users-rest-apis.md' @@ -316,7 +311,17 @@ plugins: 'references/extend/errors/error-codes-and-descriptions.md': 'references/troubleshoot/error-codes.md' 'references/error-catalog.md': 'references/troubleshoot/api-error-codes.md' 'guides/organization-management/onboard-sub-org-admins.md': 'guides/organization-management/onboard-org-admins.md' - 'guides/authentication/app-native-authentication/configure-advanced-app-native-settings.md' : 'guides/authentication/app-native-authentication/index.md' + 'guides/authentication/app-native-authentication/configure-advanced-app-native-settings.md': 'guides/authentication/app-native-authentication/index.md' + 'apis/scim2-users-rest-apis.md': 'apis/scim2/scim2-users-rest-api.md' + 'apis/scim2-groups-rest-apis.md': 'apis/scim2/scim2-groups-rest-api.md' + 'apis/scim2-patch-operations.md': 'apis/scim2/scim2-patch-operations.md' + 'apis/scim2-bulk-rest-apis.md': 'apis/scim2/scim2-bulk-rest-api.md' + 'apis/scim2-batch-operations.md': 'apis/scim2/scim2-batch-operations.md' + 'apis/scim2-sp-config-rest-apis.md': 'apis/scim2/scim2-sp-config-rest-api.md' + 'apis/organization-apis/org-scim2-bulk-mgt.md': 'apis/organization-apis/scim2/scim2-org-bulk.md' + 'apis/organization-apis/org-user-mgt.md': 'apis/organization-apis/scim2/scim2-org-user-mgt.md' + 'apis/organization-apis/org-group-mgt.md': 'apis/organization-apis/scim2/scim2-org-group-mgt.md' + 'apis/use-the-dynamic-client-registration-rest-apis.md' : 'apis/dynamic-client-registration-rest-api.md' # To address the broken links in the API Authorization guides due to the directory structure mismatch is Asgardeo and IS 'guides/api-authorization.md': 'guides/authorization/api-authorization/api-authorization.md' @@ -366,6 +371,11 @@ nav: - Add login to an SPA: guides/authentication/add-login-to-single-page-app.md - Add login to a web app: guides/authentication/add-login-to-web-app.md - Add login to a mobile app: guides/authentication/add-login-to-mobile-app.md + - Add login to saas app: + - Add SSO login to saas apps: guides/authentication/sso-integrations/index.md + - Google Workspace: guides/authentication/sso-integrations/add-google-workspace-template.md + - Salesforce: guides/authentication/sso-integrations/add-salesforce-template.md + - Microsoft 365: guides/authentication/sso-integrations/add-microsoft-365-template.md - Add passwordless login: - Add passwordless login: guides/authentication/passwordless-login/index.md - Add login with Magic link: guides/authentication/passwordless-login/add-passwordless-login-with-magic-link.md @@ -426,12 +436,15 @@ nav: - MFA based on user device: guides/authentication/conditional-auth/new-device-based-template.md - MFA based on IP address: guides/authentication/conditional-auth/ip-based-template.md - MFA based on ELK-risk: guides/authentication/conditional-auth/elk-risk-based-template.md + - MFA based on TypingDNA: guides/authentication/conditional-auth/typingdna-based-adaptive-auth.md - Add passkey progressive enrollment: guides/authentication/conditional-auth/passkey-progressive-enrollment-based-template.md - Write a custom authentication script: guides/authentication/conditional-auth/write-your-first-script.md - Configure multi-attribute login: guides/authentication/multi-attribute-login.md - App-native authentication: + - App-native authentication: guides/authentication/app-native-authentication/index.md - Add app-native authentication: guides/authentication/app-native-authentication/add-app-native-authentication.md - Secure app-native authentication flows: guides/authentication/app-native-authentication/secure-app-native-authentication-flows.md + - Handle advanced login scenarios: guides/authentication/app-native-authentication/handle-advanced-login-scenarios.md - Configure OIDC flows: - Configure OIDC flows: guides/authentication/oidc/index.md - Discover OIDC endpoints: guides/authentication/oidc/discover-oidc-configs.md @@ -449,6 +462,7 @@ nav: - Revoke tokens: guides/authentication/oidc/revoke-tokens.md - Implement logout: guides/authentication/oidc/add-logout.md - Implement back channel logout: guides/authentication/oidc/add-back-channel-logout.md + - Implement federated IdP-initiated logout: guides/authentication/oidc/oidc-federated-idp-initiated-logout.md - Configure SAML flows: - Configure SAML flows: guides/authentication/saml/index.md @@ -464,8 +478,7 @@ nav: - User Impersonation: guides/authorization/impersonation/user-impersonation.md - Identity Verification: - Identity Verification: guides/identity-verification/index.md - - Registering an Identity Verification Provider: guides/identity-verification/add-identity-verification-provider.md - - Manage an Identity Verification Provider: guides/identity-verification/manage-identity-verification-provider.md + - Configure an Identity Verification Provider: guides/identity-verification/configure-identity-verification-provider.md - User management: - User management: guides/users/index.md - Manage administrators: guides/users/manage-administrators.md @@ -501,6 +514,7 @@ nav: - SCIM2 attribute mappings: guides/users/attributes/manage-scim2-attribute-mappings.md - Configure email address as the username: guides/users/attributes/enable-email-as-username.md - Configure unique attributes: guides/users/attributes/configure-unique-attributes.md + - Configure user attribute change verification: guides/users/attributes/user-attribute-change-verification.md - Manage user stores: - Manage user stores: guides/users/user-stores/index.md - Configure the primary user store: @@ -535,7 +549,7 @@ nav: - User self-service: - User self-service: guides/user-self-service/index.md - Self-service portal: - - configure the self-service portal: guides/user-self-service/configure-self-service-portal.md + - Configure the self-service portal: guides/user-self-service/configure-self-service-portal.md - Update profile information: guides/user-self-service/update-profile-info.md - Change password: guides/user-self-service/change-password.md - Manage linked social accounts: guides/user-self-service/manage-linked-accounts.md @@ -666,7 +680,7 @@ nav: - Encryption: - Symmetric encryption: - Symmetric encryption: deploy/security/symmetric-encryption/index.md - - Configurations related to symmetric key encryption: deploy/security/symmetric-encryption/use-symmetric-encryption.md + - Configure symmetric key encryption: deploy/security/symmetric-encryption/use-symmetric-encryption.md - Symmetric data encryption key rotation: deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md - Asymmetric encryption: - Asymmetric encryption: deploy/security/asymmetric-encryption/index.md @@ -737,7 +751,7 @@ nav: - Authorized apps API V2: apis/authorized-apps-v2-rest-api.md - OAuth 2.0 scope management API: apis/oauth2-scope-management-rest-apis.md - OpenID Connect scope management API: apis/oidc-scope-management-rest-apis.md - - OIDC Dynamic Client Registration API: apis/use-the-openid-connect-dynamic-client-registration-rest-apis.md + - OIDC Dynamic Client Registration API: apis/dynamic-client-registration-rest-api.md - Script Library management API: apis/script-library-rest-api.md - App-native authentication API: apis/app-native-authentication-api.md - Authentication Data API: apis/use-the-authentication-rest-apis.md @@ -773,18 +787,22 @@ nav: - Consent management: - Overview: apis/use-the-consent-management-rest-apis.md - Consent management API: apis/consent-management-api-definition.md - - Email templates API: apis/email-templates-rest-api.md + - Email templates: + - Email templates v1 API: apis/email-templates-rest-api.md + - Email templates v2 API: apis/email-templates-v2-rest-api.md - Session management API: apis/session-mgt-rest-api.md - Server configuration API: apis/configs-rest-api.md - User Functionality management API: apis/user-functionality-mgt-rest-api.md - User management: - SCIM 2.0 API: - - SCIM 2.0 User management API: apis/scim2-users-rest-apis.md - - SCIM 2.0 Group management API: apis/scim2-groups-rest-apis.md - - SCIM 2.0 Patch Operations: apis/scim2-patch-operations.md - - SCIM 2.0 Bulk API: apis/scim2-bulk-rest-apis.md - - SCIM 2.0 Batch Operations: apis/scim2-batch-operations.md - - SCIM 2.0 Service provider configuration API: apis/scim2-sp-config-rest-apis.md + - SCIM 2.0 API: apis/scim2/index.md + - SCIM 2.0 Users API: apis/scim2/scim2-users-rest-api.md + - SCIM 2.0 Groups API: apis/scim2/scim2-groups-rest-api.md + - SCIM 2.0 Patch operations: apis/scim2/scim2-patch-operations.md + - SCIM 2.0 Bulk API: apis/scim2/scim2-bulk-rest-api.md + - SCIM 2.0 Batch operations: apis/scim2/scim2-batch-operations.md + - SCIM 2.0 Resource types API: apis/scim2/scim2-resource-types.md + - SCIM 2.0 Service provider configuration API: apis/scim2/scim2-sp-config-rest-api.md - Account recovery APIs: - Account recovery v0.9 API: apis/use-the-account-recovery-rest-apis.md - Account recovery v1 API (deprecated): apis/user-account-recovery-v1-rest-api.md @@ -812,7 +830,11 @@ nav: - SCIM 2.0 Bulk API: apis/organization-apis/org-scim2-bulk-mgt.md - SCIM 2.0 Group management API: apis/organization-apis/org-group-mgt.md - SCIM 2.0 Role management API: apis/organization-apis/org-role-mgt.md - - SCIM 2.0 User management API: apis/organization-apis/org-user-mgt.md + - User management: + - User management: apis/organization-apis/scim2/index.md + - SCIM 2.0 Users API: apis/organization-apis/scim2/scim2-org-user-mgt.md + - SCIM 2.0 Groups API: apis/organization-apis/scim2/scim2-org-group-mgt.md + - SCIM 2.0 Bulk API: apis/organization-apis/scim2/scim2-org-bulk-mgt.md - End User APIs: - FIDO API: apis/fido-rest-api.md - Session management API: apis/session-mgt-by-user-rest-api.md diff --git a/en/includes/guides/authorization/attribute-based-access-control.md b/en/includes/guides/authorization/attribute-based-access-control.md new file mode 100644 index 0000000000..f4736130a8 --- /dev/null +++ b/en/includes/guides/authorization/attribute-based-access-control.md @@ -0,0 +1,197 @@ +# Validating the Scope of OAuth Access Tokens using XACML Policies + +WSO2 Identity Server (WSO2 IS) allows you to validate the scope of an +OAuth access token using XACML policies to provide fine-grained access +control to APIs. + +If you want the XACML scope validator to execute after checking the +validity of the access token in an OAuth access token validation flow, +you can select the scope validator as XACML when you configure a service +provider. This provides fine-grained access control to APIs. + +The following sections walk you through the basic steps +you need to follow to validate the scope of OAuth access tokens using +XACML policies. + +### Register the app + +Follow the steps given below to configure an application in WSO2 Identity +Server so that the authentication happens as expected. + +1. On the {{ product_name }} Console, go to **Applications**. +2. Click **New Application** and select **Standard-Based Application**. + ![Register a standard-based application]({{base_path}}/assets/img/guides/applications/register-an-sba.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} +3. Provide an application name and select the other options based on your requirements. + + !!! note + - You can choose OIDC or SAML as the standard protocol for your application. See the complete list of [OIDC]({{base_path}}/references/app-settings/oidc-settings-for-app/) and [SAML]({{base_path}}/references/app-settings/saml-settings-for-app/) configurations. + - If you use OIDC, you can authorize APIs to an app to access the APIs in {{ product_name }}. Learn about [Authorize the API resources for an app]({{base_path}}/guides/authorization/api-authorization/api-authorization/#authorize-the-api-resources-for-an-app). + +4. Click **Register** to complete the registration. +5. After the application is registered, you will be redirected into the application. +6. Do the required changes to the application and click **Update**. +7. Get the created application's inbound protocol (OAuth2 / OIDC) configurations + by using the following REST API call. + + ```java + curl --location 'https://localhost:9443/t//api/server/v1/applications//inbound-protocols/oidc' \ + --header 'Authorization: Basic YWRtaW46YWRtaW4=' + ``` + +8. Copy the response of the above REST API call and add the following value to the + `scopeValidators` array in the response. + + ```json + "scopeValidators": [ + "XACML Scope Validator" + ] + ``` + +9. Execute the Inbound Protocols PUT REST API call to update the application with the + XACML scope validator which added in the step 7. You can get the API call details from + Update OIDC authentication protocol parameters. + +### Register an API resource and Authorize for an app + +1. Go to the **API Resources** and click **New API Resource**. +2. Add the relevant details to Basic Details, Scopes, Authorization sections and click **Create**. +3. Go to the **API Authorization** tab in the created application. +4. Click **Authorize an API Resource**, select the created API resource, scopes and click **Finish**. + + !!!note + For more information on API Authorization, see [here](../api-authorization/api-authorization.md) + +### Create a user and a role + +1. Go to **User Management** > **Users**. +2. Click **Add User** button and select **Single User** option. +3. Provide the relevant details and click **Save & Continue**. +4. Go to the **User Management** > **Roles**. +5. Click **New Role**, add the Basic Details, Permission Selection and click **Finish**. +6. Go to the **Users** tab of the created role and assign the created user to the role. + + !!!note + For more information on User Management, see [here](../../users/index.md) + +The next step is to configure the XACML policy to validate the XACML scope during OAuth +token issuance. + +### Set up the policy + +Follow the instructions given below to publish a policy using a XACML policy +template that is available by default with WSO2 Identity Server. + +1. Log in to the Management Console via . +2. In the **Main** tab of the Management Console, navigate to + **PAP** \> **Policy Administration** under the **Entitlement** menu. +3. Select the `scope_based_token_issuance_policy_template` + policy, and click **Edit** to view the selected policy in the policy + editor. + + + !!! info + XACML template policies provide a pre-configured template with place + holders to customize the policy depending on your requirement. + + +4. Edit the policy to customize it depending on your requirement. You + can change the values of attributes and rules. +5. Click **Save Policy** to save the changes. You can see the policy + that you created on the policy list (the original policy template + remains unchanged). +6. Click the link **Publish to My PDP** corresponding to the new + policy. +7. On the UI that appears, leave the default values as they are and + click **Publish**. + + To ensure that the policy has been published successfully, click on + **Policy View** under the **Entitlement \> PDP** section on the + **Main** tab of the Management Console, and check if the created + policy is listed. + +Now, you have created the policy and enforced it using the policy +template. You can test the policy to evaluate whether XACML scope is +validated at the time of OAuth token issuance. + +### Try it out + +Follow the steps given below to try out the policy using the above created application. + +1. On the {{ product_name }} Console, go to **Applications**. +2. Select your application, go to the **Protocols** tab of the application and enable the **Password** grant type. +3. Execute the following cURL command to get an access token using the password grant type. + +```java +curl --location 'https://localhost:9443/t//oauth2/token' \ +--header 'Content-Type: application/x-www-form-urlencoded' \ +--header 'Authorization: Basic ' \ +--data-urlencode 'grant_type=password' \ +--data-urlencode 'username=' \ +--data-urlencode 'password=' \ +--data-urlencode 'scope=openid SCOPE_1' +``` +If the token request can be permitted by the policy, the response will contain an access token. +If the token request is denied by the policy, the response will contain an error message. + +Follow the steps below to try out the policy using the XACML TryIt tool. + +!!! tip + The XACML TryIt tool allows you to test policies easily without having + to create and send authorization requests to WSO2 IS. It is a tool + through which authorization requests can be created and evaluated + against available policies. You can write simple XACML 3.0 requests in + XML format and try them using the web UI of the TryIt tool. + +1. On the Management Console, click **Tools**, and then click + **TryIt** under the **XACML** section. + +2. Click **Create Request Using Editor**. + +3. Specify the following as the sample request: + + ``` java + + + + test_server + + + + + scope_validation + + + + + openid + + + SCOPE_1 + + + + + @ + + + + + + + + + + + + + + + + + + ``` + +4. Click **Evaluate With PDP**. You will see a response message that + says either `Permit` or `Deny` + depending on whether the XACML scope is validated or not at the time + of OAuth token validation. diff --git a/en/includes/guides/authorization/fine-grained-authorization/rule-based-provisioning.md b/en/includes/guides/authorization/fine-grained-authorization/rule-based-provisioning.md new file mode 100644 index 0000000000..f913daa15f --- /dev/null +++ b/en/includes/guides/authorization/fine-grained-authorization/rule-based-provisioning.md @@ -0,0 +1,188 @@ +# Configure rule-based provisioning + +This page guides you through provisioning users based on defined XACML rules. + +To get a better understanding of rule-based provisioning, consider a scenario where you need to provision users assigned to the finance role from WSO2 Identity Server to the GoogleIDP. To implement this scenario, you can define a XACML policy that permits the provisioning operation if the provisioning user is assigned the finance role. + +Follow the steps given below to configure rule-based provisioning in WSO2 Identity Server. + +## Sample scenario + +Let's assume we need to provision users based on their email domain and restrict the provisioning of users who do not have the email attribute with the permitted domain (`@abc.com`). Let's create a XACML policy to implement this scenario. + +## Setting up the {{ product_name }} + +### Prerequisites +Setup outbound provisioning using the desired outbound provisioning connector ([Google]({{base_path}}/guides/users/outbound-provisioning/outbound-connectors/google/), [Salesforce]({{base_path}}/guides/users/outbound-provisioning/outbound-connectors/salesforce/) or [SCIM2]({{base_path}}/guides/users/outbound-provisioning/outbound-connectors/scim2/)). + +### Configure the resident service provider + +You need to enable rules in the outbound provisioning connector you have added to the resident service provider. This can be done using the following API: +```java +curl --location --request PUT 'https://localhost:9443/api/server/v1/applications/resident' \ +--header 'accept: application/json' \ +--header 'Authorization: Basic YWRtaW46YWRtaW4=' \ +--header 'Content-Type: application/json' \ +--data '{ + "outboundProvisioningIdps": [ + { + "idp": , + "connector": "SCIM2", + "blocking": false, + "rules": true, + "jit": false + } + ] +}' +``` + +Replace the `` with the name of the outbound provisioning connector you have registered in the earlier step. + +### Configure the service provider + +If you have configured outbound provisioning in your application, you should **Enable rules** in the outbound provisioning connector. This can be done using the following API: + +```java +curl --location --request PATCH 'https://localhost:9443/api/server/v1/applications/' \ +--header 'accept: application/json' \ +--header 'Authorization: Basic YWRtaW46YWRtaW4=' \ +--header 'Content-Type: application/json' \ +--data '{ + "provisioningConfigurations": { + "outboundProvisioningIdps": [ + { + "idp": , + "connector": "SCIM2", + "blocking": false, + "rules": true, + "jit": false + } + ] + } +}' +``` + +Replace the `` with the name of the outbound provisioning connector you have registered in the earlier step. + +Use the [application API]({{base_path}}/apis/application-rest-api/#tag/Applications/operation/getAllApplications) to find the application ID of your application and replace the `` with it. + + +## Set up XACML rules + +1. Log in to the Management Console(`https://:/carbon`) using admin/admin credentials. +2. Click on **Policy Administration** under the **Entitlement** > **PAP** section on the **Main** tab of the management console. +3. Since this sample scenario is based on the email address user claim, we need to select the policy `provisioning_user_claim_based_policy_template`. + ![Policy list]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} +4. Once you click **Edit**, the XML based policy will appear in the policy editor. There are placeholders in capitals for entering the service provider and role names. +5. Edit the placeholders accordingly with the relevant values. + 1. Change the `PolicyId` as follows: + ```xml + PolicyId="provisioning_user_claim_based_policy" + ``` + 2. Edit the `` tag and enter a description relevant to your custom policy. + 3. Locate the `IDP_NAME` placeholder and replace it with the identity provider name you have created earlier. + 4. Since we need to do a regex match on the email claim, change the condition of the rules as follows: + ```xml + + + + .*@abc\.com$ + + + + + + + ``` + 5. Since we are using only one user claim for this policy, remove the other claim by removing that entire section from the start of the `` tag to the ending `` tag. This should be edited in both POST and PUT sections as the provisioning is initiated when creating the user and when updating the user as well. + 6. Also for this example, we do not need a service provider. Therefore, we need to remove the service provider `SP_NAME` match block as well. +6. Once the changes have been made, the policy should be similar to the following. +```xml + +This template policy provides ability to authorize provisioning requests initiated from a given service provider(defined by SP_NAME) to a given identity provider(defined by IDP_NAME) in the outbound provisioning flow based on the claim values of the user (CLAIM_URI_1=CLAIM_VALUE_1 and CLAIM_URI_2=CLAIM_VALUE_2). Users with the given claim values will be allowed and any other users will be denied. + + + + +WSO2IDP + + + + +provisioning + + + + + + + + + + + +POST + + + + + + + + + +.*@wso2\.com$ + + + + + + + + + + + + + +PUT + + + + + + + + + + + + + +test@abc.com + + + + + + + +``` + +7. Click **Save Policy** to save the changes. You can see the policy you just created on the policy list (the original template policy will remain unchanged for later use). + ![Saved policy list]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy-saved.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} + +8. Click on the **Publish to My PDP** link corresponding to the new policy. + ![Publish To My PDP icon]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy-to-publish.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} + +9. On the UI that appears, leave the default selected values as they are and click **Publish**. +10. Click on **Policy View** under the **Entitlement>PDP** section on the **Main** tab of the management console. +11. To ensure that the policy has been published successfully, check if the policy is listed. + ![Published policy]({{base_path}}/assets/img/guides/authorization/fine-grained-authorization/provisioning-user-claim-policy-published.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} +12. To test out whether the policy works, follow the **Try it** out section. + + +## Try it out + +Once the policies are published to PDP, they are ready to execute during outbound provisioning. You can test rule-based provisioning by creating a user in WSO2 Identity Server that matches the rules you enforced. +For example, when you create a user with the email `"jane@abc.com"` in WSO2 Identity Server, it should be provisioned to the external IDP you have configured for outbound provisioning as well. A user who does not have an email with the domain `@abc.com` should not be provisioned. \ No newline at end of file diff --git a/en/includes/guides/authorization/user-impersonation.md b/en/includes/guides/authorization/user-impersonation.md index 84f49511cc..1f65fe8837 100644 --- a/en/includes/guides/authorization/user-impersonation.md +++ b/en/includes/guides/authorization/user-impersonation.md @@ -9,9 +9,101 @@ This guide explains how you can implement user impersonation in {{product_name}} You can go through the following steps to prepare your application for user impersonation. -### Prerequisite +### Prerequisites + +{% if product_name == "WSO2 Identity Server" and is_version == "7.0.0" %} + +- Enable impersonation. To do so, apply the following configurations in the `deployment.toml` file found in the `/repository/conf` directory. + + ```bash + [[oauth.custom_response_type]] + name= "subject_token" + class= "org.wso2.carbon.identity.oauth2.authz.handlers.SubjectTokenResponseTypeHandler" + validator= "org.wso2.carbon.identity.oauth.common.SubjectTokenResponseValidator" + + [[oauth.custom_response_type]] + name= "id_token subject_token" + class= "org.wso2.carbon.identity.oauth2.authz.handlers.SubjectTokenResponseTypeHandler" + validator= "org.wso2.carbon.identity.oauth.common.SubjectTokenResponseValidator" + + [[api_resources]] + name= "User Impersonation" + identifier= "system:impersonation" + requiresAuthorization= true + description= "Resource representation of the User Impersonation" + type= "TENANT" + + [[api_resources.scopes]] + displayName = "User Impersonation Scope" + name = "internal_user_impersonate" + description = "Allows to impersonate another user" + ``` + +- Insert a new configuration type into the `IDN_CONFIG_TYPE` table of your database. The relevant DB scripts are shown below. + + ??? Example "DB2" + + ```sql + INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); + ``` + + ??? Example "H2" + + ```sql + INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); + ``` + + ??? Example "MsSQL" + + ```sql + INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); + ``` + + ??? Example "MYSQL" + + ```sql + INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); + ``` + + ??? Example "MYSQL-Cluster" + + ```sql + INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); + ``` + + ??? Example "Oracle" + + ```sql + INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); + ``` + + ??? Example "OracleRac" + + ```sql + INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); + ``` + ??? Example "Postgres" + + ```sql + INSERT INTO IDN_CONFIG_TYPE (ID, NAME, DESCRIPTION) VALUES ('3e5b1f91-72d8-4fbc-94d1-1b9a4f8c3b07', 'IMPERSONATION_CONFIGURATION', 'A resource type to keep the tenant impersonation preferences.'); + ``` + + Alternatively you can use [Config Management REST API]({{base_path}}/apis/use-the-configuration-management-rest-apis/) to add this configuration as shown below. + + ```curl + curl --location 'https:///api/identity/config-mgt/v1.0/resource-type' \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ + --data '{"name": "IMPERSONATION_CONFIGURATION", "description": "A resource type to keep the tenant impersonation preferences. + ``` + +- You need to have an application registered in {{product_name}}. If you don't already have one, [register a web app with OIDC]({{base_path}}/guides/applications/register-oidc-web-app/). + +{% else %} To get started, you need to have an application registered in {{product_name}}. If you don't already have one, [register a web app with OIDC]({{base_path}}/guides/applications/register-oidc-web-app/). +{% endif %} ### Step 1: Authorize application for user impersonation @@ -105,7 +197,7 @@ Subject token is a JWT token that contains information on both the impersonated === "Request Format" ``` bash - https://api.asgardeo.io/t/{organization_name}/oauth2/authorize? + https://{{base_url}}/oauth2/authorize? client_id={clientID} redirect_uri={redirect_uri} &state={sample_state} @@ -119,7 +211,7 @@ Subject token is a JWT token that contains information on both the impersonated === "Sample Request" ``` bash - https://api.asgardeo.io/t/bifrost/oauth2/authorize? + https://{{base_url_sample}}/oauth2/authorize? client_id=jVcW4oLn1Jjb2T94H4gtPV9z5Y0a &redirect_uri=https://oauth.pstmn.io/v1/callback &state=sample_state @@ -177,7 +269,7 @@ The decoded subject token may looks as follows: "nbf": 1718694997, "azp": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", "scope": "internal_login internal_user_mgt_list internal_user_mgt_view", - "iss": "https://api.asgardeo.io/t/{organization_name}/oauth2/token", + "iss": "https://{{base_url}}/oauth2/token", "may_act": { "sub": "2d931c9d-876e-46c0-9aba-f34501879dfc" }, @@ -198,7 +290,7 @@ Once a subject token is received, it can then be exchanged for an access token w === "Request Format" ``` bash - curl --location 'https://api.asgardeo.io/t/{organization_name}/oauth2/token' \ + curl --location 'https://{{base_url}}/oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --header 'Authorization: Basic ' \ --data-urlencode 'subject_token={subject_token}' \ @@ -212,7 +304,7 @@ Once a subject token is received, it can then be exchanged for an access token w === "Sample Request" ``` bash - curl --location 'https://api.asgardeo.io/t/bifrost/oauth2/token' \ + curl --location 'https://{{base_url_sample}}/oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --header 'Authorization: Basic QVVhZkoyeWpXM2dUR3JZaWZCTlF1MTBXRWtNYToybWN1blJ1T1Y5WFQ3QXpzRDEyVmY3cGhOVWJRUmdlT0NtZW5Wa0xKQTR3YQ==' \ --data-urlencode 'subject_token=eyJ4NXQiOiJDN3Q1elQ4UUhXcWJBZ3ZJ9HVXWTN4UnlwcE0iLCJraWQiOiJaR0UyTXpjeE1XWXpORGhtTVRoak1HSmlOamhpTmpNMFlqWXhNakJtTUdZeFl6ZzBabU0zWldJd1pHRmxZakk1TTJZelpHTmtaalkxWXpBeE5qZzNNUV9SUzI1NiIsInR5cCI6Imp3dCIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiIxYmI0NmMyOC0zN2U4LTQxN2UtYWI5NS0wMzAzYTYzM2ZlZTIiLCJhdWQiOiJBVWFmSjJ5alczZ1RHcllpZkJOUXUxMFdFa01hIiwibmJmIjoxNzI4ODc5NTQ3LCJhenAiOiJBVWFmSjJ5alczZ1RHcllpZkJOUXUxMFdFa01hIiwic2NvcGUiOiJpbnRlcm5hbF9vcmdfYXBwbGljYXRpb25fbWd0X3ZpZXcgb3BlbmlkIiwiaXNzIjoiaHR0cHM6XC9cL2FwaS5hc2dhcmRlby5pb1wvdFwvaGltZXNoZGV2aW5kYVwvb2F1dGgyXC90b2tlbiIsIm1heV9hY3QiOnsic3ViIjoiNTllNmNlZWEtOGU2Ni00MTkyLWJlMDktMzQwYmIwMmQ1N2MxIn0sImV4cCI6MTcyODg3OTcyNywiaWF0IjoxNzI4ODc5NTQ3LCJqdGkiOiIzYjIzNDViOS1jN2Y4LTQ4MjUtYWYyNC1lNDRjYjk3Y2U5NWEiLCJjbGllbnRfaWQiOiJBVWFmSjJ5alczZ1RHcllpZkJOUXUxMFdFa01hIn0.UmhvpiqrgbgJ8MSXNkzyUMbw5c2BG5oWv9HpBDrZwig2HkM-FpceFlGi4tnl45LGAxDeVE2NJBAII3Q6ccMK0pk9DM2piX0m7gtxtfNy9XQURMad39JOY1GTy8p9uJY0wYWrYXYCc3nyF83kwu4y3xHABYd1JNjcZgLW_B5M1XUUk05cOOyJLOvjaMAkl8DlohD9mAY4-C2UyaxsG8ftfth4mMJZeg3MJOW150cye9TAil0SACO6DIv3Tik7Wt_zyghSueBKQiOqgLEXZdphIT-7TWYASiJigTX0n_PKBF67qOo9tD5FIDEh5fQquXYAjPP9LHJYeK_C6dkh9jiX7w' \ @@ -241,7 +333,7 @@ The decoded access token may looks as follows: { "sub": "32bc4697-ed0f-4546-8387-dcd6403e7caa", "aut": "APPLICATION_USER", - "iss": "https://api.asgardeo.io/t/bifrost/oauth2/token", + "iss": "https://{{base_url_sample}}/oauth2/token", "client_id": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", "aud": "jVcW4oLn1Jjb2T94H4gtPV9z5Y0a", "nbf": 1718695052, @@ -267,8 +359,9 @@ holds the value of `2d931c9d-876e-46c0-9aba-f34501879dfc`, which is the userid o ## Access logs related to user impersonation -In order to troubleshoot issues and keep track of the actions performed by impersonators, {{product_name}} supports logs for user impersonation. -Whenever a resource gets modified using an impersonated access token, an audit log is printed with the relevant details of the impersonator. +In order to troubleshoot issues and keep track of the actions performed by impersonators, {{product_name}} supports logs for user impersonation. Whenever a resource gets modified using an impersonated access token, an audit log is printed with the relevant details of the impersonator. + +{% if product_name == "Asgardeo" %} You may access these logs from the **Logs** section of the {{product_name}} Console. @@ -278,10 +371,46 @@ You may access these logs from the **Logs** section of the {{product_name}} Cons Learn more about [audit logs]({{base_path}}/guides/asgardeo-logs/audit-logs/). +{% else %} + +=== "Audit log format" + + ``` bash + TID: [-1234] [2024-06-03 14:50:42,298] [1a2ac914-ea61-4699-8778-ea44d2fa27c5] INFO {AUDIT_LOG} \ + - Initiator={Impersonated_User_Id} \ + Action=resource-modification-via-impersonation \ + Target={Impersonated_User_Id} \ + Data={"ResourcePath":{Resource_Path} ,"clientId":{Client_Id} ,"subject":{Impersonated_User_Id},"scope":{Scope Issued for the Impersonated Access token} ,"impersonator":{Impersonater Id} ,"httpMethod":{Http Method}} \ + Outcome=AUTHORIZED + ``` + +=== "Sample audit log" + + ```bash + TID: [-1234] [2024-06-03 14:50:42,298] [1a2ac914-ea61-4699-8778-ea44d2fa27c5] INFO {AUDIT_LOG} \ + - Initiator=0fa51985-d36d-4492-9ebd-298f9d68861f \ + Action=resource-modification-via-impersonation \ + Target=49de2b73-5f0b-44db-bf75-6fddec4b058e \ + Data={"ResourcePath":"/scim2/Me","clientId":"luoljDTbHYcfx6YWT_7wsYs67rsa","subject":"49de2b73-5f0b-44db-bf75-6fddec4b058e","scope":"internal_login internal_user_mgt_list internal_user_mgt_view","impersonator":"0fa51985-d36d-4492-9ebd-298f9d68861f","httpMethod":"PATCH" \ + Outcome=AUTHORIZED + ``` + +In an instance where the impersonator modifies a resource, a log will be printed similar to the following: + +```bash +TID: [-1234] [2024-06-03 14:50:42,976] [1a2ac914-ea61-4699-8778-ea44d2fa27c5] INFO {AUDIT_LOG} \ +- Initiator=49de2b73-5f0b-44db-bf75-6fddec4b058e \ +Action=Set-User-Claim-Values \ +Target=t******r \ +Data={"ServiceProviderName":"POSTMAN_SBA","Claims":{"http://wso2.org/claims/country":"S***n","http://wso2.org/claims/modified":"2*************************Z","profileConfiguration":"d*****t"}} \ +Outcome=Success | Impersonator : 0fa51985-d36d-4492-9ebd-298f9d68861f +``` + +{% endif %} ## Notify users on impersonation -When an impersonated access token is issued on behalf of a user, Asgardeo allows you to send a notification email to the affected user. +When an impersonated access token is issued on behalf of a user, {{product_name}} allows you to send a notification email to the affected user. This enhances transparency by keeping the user informed of any actions performed on their behalf. Follow the steps below to enable/disable email notifications: @@ -317,7 +446,7 @@ The following diagram shows the detailed steps involved in receiving an imperson === "Request Format" ``` bash - curl --location 'https://api.asgardeo.io/t/{organization_name}/oauth2/token' \ + curl --location 'https://{{base_url}}/oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --header 'Authorization: Basic ' \ --data-urlencode 'client_id={Client_Id}' \ @@ -330,7 +459,7 @@ The following diagram shows the detailed steps involved in receiving an imperson === "Sample Request" ``` bash - curl --location 'https://api.asgardeo.io/t/bifrost/oauth2/token' \ + curl --location 'https://{{base_url_sample}}/oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --header 'Authorization: Basic QVVhZkoyeWpXM2dUR3JZaWZCTlF1MTBXRWtNYToybWN1blJ1T1Y5WFQ3QXpzRDEyVmY3cGhOVWJRUmdlT0NtZW5Wa0xKQTR3YQ==' \ --data-urlencode 'client_id=AUafJ2yjW3gTGrYifBNQu10WEkMb' \