UMA 2.0 feature in WSO2 Identity Server

10 min readJul 13, 2018

During my internship at WSO2, I got the chance to work on implementing User-Managed Access 2.0 support for WSO2 Identity Server. In this blog post I’ll be explaining step by step on how to configure and test UMA features by using WSO2 Identity Server as the authorization server. First of all let me briefly explain what is actually UMA and how it is integrated with WSO2 Identity Server.

User-Managed Access (UMA) is a standard protocol built on top of OAuth 2.0 which enables party-to-party sharing. It gives the resource owner the ability to control who can access his/her protected resources from a centralized authorization server by creating authorization policies.

For detailed explanation on UMA 2.0 protocol I recommend you to read here and here.

As depicted above, UMA profile consists of two main components.

Protection API

This OAuth protected API provides the following endpoints:

Resource Registration Endpoint: allows the resource server to put resources under the protection of the authorization server on behalf of the resource owner and manage them over time.
Permission Endpoint: provides a means for the resource server to request permission(s) when the client’s resource request is unaccompanied by RPT (Requesting Party Token) or is accompanied by an invalid RPT.
Token Introspection Endpoint: provides a means for the resource server to introspect the RPT which is required to access an UMA protected resource.

To access Resource Registration Endpoint, Permission Endpoint and Token Introspection Endpoint it is a must for the request made by the resource server to authorization server to be accompanied with an access token namely, PAT (Protection API Access Token). PAT represents the resource owner’s authorization to use the protection API. The PAT token is simply an OAuth access token with the scope “uma_protection”.

2. UMA grant

A client acting on behalf of the requesting party can obtain an RPT from the authorization server after successful evaluation of policy conditions, scopes, claims and any other relevant information.

Now let’s see the UMA flow.

1 - Resource server puts resources and their available scopes under authorization server protection. Once the resource is registered, the resource owner can set policy conditions at the authorization server.

2 - Client acting on behalf of the requesting party makes an access request to protected resource (with invalid/ no RPT access token).

3 - Resource server requests permissions (resources and scopes bounded to that resource).

4 - Authorization server returns a permission ticket.

5 - Resource server returns authorization server uri and permission ticket.

6 - Client requests access token by providing the permission ticket and any required claims.

7- Authorization server issues an RPT.

8 - Client requests for the protected resource with RPT.

9 - Resource server introspects RPT at the authorization server.

10 - Authorization server returns token introspection status.

11 - Resource server gives access to protected resource.

I hope you got a basic understanding about how UMA protocol operates. So let’s get started with testing how UMA works in WSO2 Identity Server. I’ll be using a simple scenario to demo the flow.

Scenario :

Let us consider Kate (resource owner) wants to share with view permission her photo album (resource) on her cloud drive (resource server) with her friend Sam (requesting party). Sam uses a mobile app (client) to act on his behalf to request for Kate’s photo album. UMA 2.0 helps Kate by outsourcing of authorization and giving her the ability to control resources pro-actively and sharing resources in a selective manner from single console (authorization server).

Kate has the WSO2 Identity Server as the authorization server. She has put some of her resources under the authorization server protection. She has defined policies in the WSO2 IS to state who can access which resource under which permission scopes. When the client acting on behalf of Sam makes a resource request without an access token or invalid RPT (Requesting Party Token) to Kate’s photo album residing at resource server, the resource server requests one or more permissions (resource identifiers and corresponding scopes) from the authorization server. In return the resource server gets a permission ticket. The resource server sends the newly created permission ticket and the authorization server url to the client. Then the client requests for a RPT by providing valid claims and the permission ticket. If the authorization assessment is successful the client will receive a RPT. Now the client can again request to the resource server for the protected resource access with the valid access token and through a token introspection call to the authorization server the required information to carry on with the resource sharing will occur.

Testing out UMA flow

Pre-requisites:

At the time of writing this blog, the WSO2 Identity Server (version: 5.5.0) available in the product download page doesn’t contain the UMA feature embedded. Therefore before you begin, visit https://github.com/wso2/product-is/releases and download the latest version. For details on running the Identity Server, see Running the Product.

Step 1: Register UMA grant type in WSO2 IS.

Before running the product, let us first register the UMA grant type. Configure the <IS_HOME>/repository/conf/identity/identity.xml file by adding the below given entry, under the <OAuth><SupportedGrantTypes> element.

<SupportedGrantType>
    <GrantTypeName>urn:ietf:params:oauth:grant-type:uma-ticket</GrantTypeName>
    <GrantTypeHandlerImplClass>org.wso2.carbon.identity.oauth.uma.grant.UMA2GrantHandler</GrantTypeHandlerImplClass>
    <GrantTypeValidatorImplClass>org.wso2.carbon.identity.oauth.uma.grant.GrantValidator</GrantTypeValidatorImplClass>
</SupportedGrantType>

Now let’s run the product.

Step 2: Configuring resource owner (Kate).

On the Main tab, click Add under Users and Roles.

Click Users and Add New User. Add user as kate. You can create a role such as “resourceOwner” with the required permissions such as “Entitlement Management” and assign this role to kate. For this example let us assign the default “admin” role to kate.

Step 3: Configuring requesting party (Sam).

On the Main tab, click Add under Users and Roles.

Click Users and Add New User. Add user as sam.

Step 4: Configuring service providers for the resource server and client.

Click Add under Service Providers on the Main tab and add a new service provider in the Identity section. Here we can put any name for the service provider name, but since we are using the service provider to represent the resource server let’s use a name like “resourceServer”.

Click Register to add the new service provider.

Expand the Inbound Authentication Configuration section and add OAuth/OpenID Connect Configuration.

Follow the same procedure to add the client (acting on behalf of the requesting party) as a service provider. Let’s give the service provider name as “UMAClient”.

Make sure “urn:ietf:params:oauth:grant-type:uma-ticket” is ticked when adding OAuth/OpenID Connect Configuration for UMAClient.

Step 5: Get Protection API Access token (PAT).

Request

curl -u <client id>:<client secret> -k -d "grant_type=<grant_type>&username=<username>&password=<password>&scope=<scope>" -H "Content-Type:application/x-www-form-urlencoded" https://localhost:9443/oauth2/token

Sample cURL

Replace <ClientId>:<ClientSecret>with client id and client secret of OAuth service provider for resource server and scope as ‘uma_protection’. For <grant_type> we will use ‘password’ (resource owner password credentials grant). For <username> and <password> add kate’s credentials (resource owner’s username and password).

curl -u m8WRB7bPcXHFVqLVlGchHLj9pfIa:cPkdfEs7uC0dPu6636gX7u64yxka -k -d "grant_type=password&username=kate&password=pass123&scope=uma_protection" -H "Content-Type:application/x-www-form-urlencoded" https://localhost:9443/oauth2/token

Response


{"access_token":"b8df48ff-feab-3632-b3dc-68ae6b4c62e2","refresh_token":"1037ccad-f45a-38e7-96ad-40c00fbc7ca4","scope":"uma_protection","token_type":"Bearer","expires_in":3600}

Step 6: Register resource.

Request

curl -v -X POST -H "Authorization:Bearer <PAT>" -H "Content-Type: application/json" -d '{"resource_scopes":<resource scopes list>, "description":<resource description>, "icon_uri":<resource icon uri>, "name":"<resource name>, "type":<resource type>}' https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource -k

Sample cURL

Replace <PAT> with the obtained access token. Replace<resource scopes list>, <resource description>, <resource icon uri>, <resource name> and <resource type> with the relevant resource details of the resource to put under authorization protection.

curl -v -X POST -H "Authorization:Bearer b8df48ff-feab-3632-b3dc-68ae6b4c62e2" -H "Content-Type: application/json" -d '{"resource_scopes":["view", "download"], "description":"Collection of digital photographs", "icon_uri":"http://www.example.com/icons/flower.png", "name":"Photo Album", "type":"http://www.example.com/rsrcs/photoalbum"}' https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource -k

Response

{"_id":"3f88c89a-d3b8-4ebb-9567-08e5bb774d3c"}

Step 7: Register a policy.

The resource owner can set access policies subsequent to the resource registration action just completed.

Go to Entitlement dropdown menu in the Main tab. Click Policy Administration under PAP.

Click Add New Entitlement Policy.

Select Write policy in XML from the available policy creation methods.

Write the policy and Save Policy.

The newly created policy is listed in Policy Administration page. Select the policy and click Publish To My PDP button.

In the Publish Policy page, click Publish.

Click Yes to confirm publishing to PDP.

To view the published policy click Policy View under PDP.

Sample XACML policy

<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId=entitlement policy name RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
   <Target>
      <AnyOf>
         <AllOf>
            <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">resource id</AttributeValue>
               <AttributeDesignator AttributeId="http://wso2.org/identity/identity-resource/resource-id" Category="http://wso2.org/identity/identity-resource" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator>
            </Match>
         </AllOf>
      </AnyOf>
   </Target>
   <Rule Effect="Permit" RuleId="permit_for_username">
      <Target>
         <AnyOf>
            <AllOf>
               <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                  <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">requesting party</AttributeValue>
                  <AttributeDesignator AttributeId="http://wso2.org/identity/user/username" Category="http://wso2.org/identity/user" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"></AttributeDesignator>
               </Match>
            </AllOf>
         </AnyOf>
      </Target>
      <Condition>
         <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
            <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">scope 01</AttributeValue>
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">scope 02</AttributeValue>
            </Apply>
            <AttributeDesignator AttributeId="http://wso2.org/identity/identity-action/action-name" Category="http://wso2.org/identity/identity-action" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator>
         </Apply>
      </Condition>
   </Rule>
   <Rule Effect="Deny" RuleId="Deny_all"></Rule>
</Policy>

Replace the entitlement policy name, resource id, requesting party and scopes with the relevant values. A policy is defined per resource id. Against the resource id, multiple requesting parties and their allowed scopes can be defined.

Sample policy for this scenario

<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId="UMApolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
   <Target>
      <AnyOf>
         <AllOf>
            <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">3305e662-34a4-4a77-8237-7cf346026d98</AttributeValue>
               <AttributeDesignator AttributeId="http://wso2.org/identity/identity-resource/resource-id" Category="http://wso2.org/identity/identity-resource" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator>
            </Match>
         </AllOf>
      </AnyOf>
   </Target>
   <Rule Effect="Permit" RuleId="permit_for_username">
      <Target>
         <AnyOf>
            <AllOf>
               <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                  <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">sam</AttributeValue>
                  <AttributeDesignator AttributeId="http://wso2.org/identity/user/username" Category="http://wso2.org/identity/user" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"></AttributeDesignator>
               </Match>
            </AllOf>
         </AnyOf>
      </Target>
      <Condition>
         <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
            <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">view</AttributeValue>
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">download</AttributeValue>
            </Apply>
            <AttributeDesignator AttributeId="http://wso2.org/identity/identity-action/action-name" Category="http://wso2.org/identity/identity-action" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator>
         </Apply>
      </Condition>
   </Rule>
   <Rule Effect="Deny" RuleId="Deny_all"></Rule>
</Policy>

Step 8: Obtain a permission ticket.

Permission Endpoint- Allows the resource server to request permissions when a client makes a resource request without a token or the request contains an invalid token.

Note: To change the permission ticket expiration validity period, navigate to <IS_HOME>/repository/conf/identity/identity.xml file and change the value for <AuthorizationCodeDefaultValidityPeriod>. Before obtaining the permission ticket I recommend you to increase the validity period (I changed it to 3000 for this demo. Otherwise by the time the request for RPT is made, the permission ticket has expired and you will again have to obtain a new permission ticket in order to proceed).

Request

curl -X POST https://localhost:9443/api/identity/oauth2/uma/permission/v1.0/permission -H 'authorization: Bearer <PAT>' -H "Content-Type: application/json" -d '[{"resource_id":<resource id>,"resource_scopes":[<resource scopes>]}]' -k

Sample cURL

Replace <PAT> with the obtained access token. For <resource id> and <resource scopes> add details of the registered resource.

Request can contain one or multiple permissions (multiple resources and the relevant scopes of one single resource owner). The below request contain a single permission.

curl -X POST https://localhost:9443/api/identity/oauth2/uma/permission/v1.0/permission -H 'authorization: Bearer c555e611-e640-3581-ba09-c6019ad7f27e' -H "Content-Type: application/json" -d '[{"resource_id":"3f88c89a-d3b8-4ebb-9567-08e5bb774d3c","resource_scopes":["view"]}]' -k

Response

Regardless of whether the request contained one or multiple permissions, only a single permission ticket is returned.

{"ticket":"97f476f2-72d0-4540-aa08-a4784bd2053e"}

Step 9: Gather claims by obtaining OIDC token.

Client should pass the id token to prove the identity to the authorization server (End username (requesting party) should be obtained to evaluate the policy defined in this demo. Other than the end username, the resource owner can define other claims for the policy to be evaluated. In this demo only the username is required).

Request

curl -u <ClientId>:<ClientSecret> -k -d "grant_type=<grant_type>&username=<username>&password=<password>&scope=<scope>" -H "Content-Type:application/x-www-form-urlencoded" https://localhost:9443/oauth2/token

Sample cURL

Replace <ClientId>:<ClientSecret>with client key and client secret of OAuth service provider for the client acting on behalf of the requesting party (Sam). For <grant_type> let’s use ‘password’. <username> and <password> parameters should be replaced by requesting party credentials.

curl -u Czbn61UfKOYrAwk9Af6bur3nKa8a:X68v30hi8hTYgwDxKcv7OtTfTcca -k -d "grant_type=password&username=sam&password=pass1234&scope=openid" -H "Content-Type:application/x-www-form-urlencoded" https://localhost:9443/oauth2/token

Response

{"access_token":"f2999d40-af06-3779-b157-731d6540c5de","refresh_token":"f95adb62-34ae-311e-83c1-6b136eb49017","scope":"openid","id_token":"eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiMVhhWm43TE1LeU5sdFhFbnBOZ09fQSIsImF1ZCI6IkN6Ym42MVVmS09ZckF3azlBZjZidXIzbkthOGEiLCJzdWIiOiJzYW0iLCJhenAiOiJDemJuNjFVZktPWXJBd2s5QWY2YnVyM25LYThhIiwiYW1yIjpbInBhc3N3b3JkIl0sImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTUzNTE4MjM5OCwiaWF0IjoxNTM1MTc4Nzk4fQ.Rs3nPOMA_Fn8iWfDpVvmgWayhKU3_hhMQg_WHPxE0P_Dg2S8qxtSHBLMj6Z_b5iXNIAKFYFA_VF9fxZnSKgmVxZiYyrD0YADbZ5Hu6PW5uQPI59c0hdXT4rCH2WG2hP4slKRqsNZ1DCleWr0aiCPLwWixyUdnPub2c98IOcheOhkOOVV6WvAtI56f2gRDzUf66-t-3ZgKgfxkT0X6uNkvkRsk3oG7nK6_2wCuyoGYIS1h0yzryZYPmRLs7Db7QShshkB9yhAHrqo8b9b7Lf8S5NAXH2fcayEBq1MaqioBN9b_11swQ6R_2IA1EgoDfZ-eKGWCjOEsKusPmuDAI4xvQ","token_type":"Bearer","expires_in":3600}

For more detailed information on getting an OIDC token in WSO2 Identity Server, check here.

Step 10: Obtain Requesting Party Token (RPT).

Client acting on behalf of the requesting party requests for a RPT, with the obtained permission ticket and the claim token

Request

curl --user <ClientId>:<Clientsecret> -k -d "grant_type=<uma_grant>&ticket=<permission_ticket>&claim_token=<id_token>" -H "Content-Type: application/x-www-form-urlencoded" https://localhost:9443/oauth2/token

Sample cURL

Replace <ClientId>:<ClientSecret>with client key and client secret of OAuth service provider for the client acting on behalf of the requesting party (Sam). For <id_token> parameter, substitute the obtained OIDC token for Sam. <grant_type> should be the uma grant type. For <permission_ticket> use the permission ticket obtained in step 8. Make sure the permission ticket is not expired. If expired, obtain a new permission ticket.

curl --user Czbn61UfKOYrAwk9Af6bur3nKa8a:X68v30hi8hTYgwDxKcv7OtTfTcca -k -d "grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket&ticket=5e7e6873-3f5d-42f6-a37f-63ee1d23f31a&claim_token=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiMVhhWm43TE1LeU5sdFhFbnBOZ09fQSIsImF1ZCI6IkN6Ym42MVVmS09ZckF3azlBZjZidXIzbkthOGEiLCJzdWIiOiJzYW0iLCJhenAiOiJDemJuNjFVZktPWXJBd2s5QWY2YnVyM25LYThhIiwiYW1yIjpbInBhc3N3b3JkIl0sImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTUzNTE4MjM5OCwiaWF0IjoxNTM1MTc4Nzk4fQ.Rs3nPOMA_Fn8iWfDpVvmgWayhKU3_hhMQg_WHPxE0P_Dg2S8qxtSHBLMj6Z_b5iXNIAKFYFA_VF9fxZnSKgmVxZiYyrD0YADbZ5Hu6PW5uQPI59c0hdXT4rCH2WG2hP4slKRqsNZ1DCleWr0aiCPLwWixyUdnPub2c98IOcheOhkOOVV6WvAtI56f2gRDzUf66-t-3ZgKgfxkT0X6uNkvkRsk3oG7nK6_2wCuyoGYIS1h0yzryZYPmRLs7Db7QShshkB9yhAHrqo8b9b7Lf8S5NAXH2fcayEBq1MaqioBN9b_11swQ6R_2IA1EgoDfZ-eKGWCjOEsKusPmuDAI4xvQ" -H "Content-Type: application/x-www-form-urlencoded" https://localhost:9443/oauth2/token

Response

{"access_token":"p8dj48ff-heah-3632-b3dc-68aenm4c62e9","token_type":"Bearer","expires_in":3600}

Step 11: Token Introspection.

Request

curl -v -k -H "Authorization: Bearer <PAT>" -H "Content-Type:application/x-www-form-urlencoded" -X POST --data "token=<RPT>" https://localhost:9443/oauth2/introspect

Sample cURL

Replace PAT and RPT with the obtained tokens. If the PAT has expired it is required to obtain a new PAT (default validity period for an access token is 3600 seconds. This value can be changed in the identity.xml file if needed)

curl -v -k -H "Authorization:Bearer b8df48ff-feab-3632-b3dc-68ae6b4c62e2" -H "Content-Type:application/x-www-form-urlencoded" -X POST --data "token=p8dj48ff-heah-3632-b3dc-68aenm4c62e9" https://localhost:9443/oauth2/introspect

Response

{"active":true,"token_type":"Bearer","exp":1535634757,"iat":1535274757,"client_id":"Czbn61UfKOYrAwk9Af6bur3nKa8a","username":"sam"}

If the token introspection for the RPT is successful, the resource server can now share the resource with the client :) This is how UMA works simply.

Additional to resource registration, the Resource Registration Endpoint allows to list registered UMA resources, read resource description of a UMA resource, update an UMA resource and delete an UMA resource.

List registered UMA resources

Request

curl -X GET https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource -H "authorization:Bearer <PAT>" -k

Sample cURL

curl -X GET https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource -H "authorization:Bearer b8df48ff-feab-3632-b3dc-68ae6b4c62e2" -k

Response

["e2895d95-c026-45ef-b610-9070aa6cab06","3f88c89a-d3b8-4ebb-9567-08e5bb774d3c","ab3598f2-1f2c-4c86-8bb1-187ec56df495","e9d2b63b-a0c9-4bd6-b2c4-a3769793eec4"]

Read resource description of a UMA resource

Request

curl -v  -X GET https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource/<resource id> -H "Authorization:Bearer <PAT>" -k

Sample cURL

curl -v  -X GET https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource/540a3a81-cb35-49b6-bc1d-c555a14fc62d -H "Authorization:Bearer b8df48ff-feab-3632-b3dc-68ae6b4c62e2" -k

Response

{"resource_scopes":["view","download"],"_id":"ab3598f2-1f2c-4c86-8bb1-187ec56df495","name":"Photo Album","type":"http://www.example.com/rsrcs/photoalbum","icon_uri":"http://www.example.com/icons/flower.png","description":"Collection of digital photographs"}

Update an UMA resource

Request

curl -X PUT https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource/<resource id> -H "authorization:Bearer <PAT>" -H "Content-Type: application/json" -d '{"resource_scopes": [<resource scopes>],"name": <resource name>,"type": <resource type>,"icon_uri": <icon uri>}' -k

Sample cURL

curl -X PUT https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource/540a3a81-cb35-49b6-bc1d-c555a14fc62d -H "authorization:Bearer b8df48ff-feab-3632-b3dc-68ae6b4c62e2" -H "Content-Type: application/json" -d '{"resource_scopes": ["view","download"],"name": "photo1","type": "http://www.example.com/new/photoalbum","icon_uri": "Collection of digital photographs"}' -k

Response

{"_id":"540a3a81-cb35-49b6-bc1d-c555a14fc62d"}

Delete an UMA resource

Request:

curl -X DELETE https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource/<ResourceId> -H "authorization:Bearer <PAT>" -H "Content-Type: application/json" -k

Sample cURL:

curl -X DELETE https://localhost:9443/api/identity/oauth2/uma/resourceregistration/v1.0/resource/540a3a81-cb35-49b6-bc1d-c555a14fc62d -H 'authorization: Bearer b8df48ff-feab-3632-b3dc-68ae6b4c62e2' -H "Content-Type: application/json" -k

UMA 2.0 feature in WSO2 Identity Server

Scenario :

Testing out UMA flow

Written by Dewni Weeraman

Responses (3)