Skip to main content

How to use WSO2 Carbon Admin services to assign permissions to user goups

This is the way of setting permissions for a role using a “carbon admin service”. Basically, this is an http post request.


Replace localhost and port according management console information
That should be like <esb host name>:<management console https port>

Request Payload :

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=”http://org.apache.axis2/xsd“>
   <soapenv:Header/>
   <soapenv:Body>
      <xsd:setRoleUIPermission>
         <!–Optional:–>
         <xsd:roleName>cg_publisher</xsd:roleName>
         <!–Zero or more repetitions:–>
         <xsd:rawResources>/permission/admin/login</xsd:rawResources>
         <xsd:rawResources>/permission/admin/configure/datasources</xsd:rawResources>
      </xsd:setRoleUIPermission>
   </soapenv:Body>
</soapenv:Envelope>

Inside <xsd:roleName> element, the “Group Name” should be passed.
Inside < xsd:rawResources > element, the “Permission Path” should be passed. If you need to set many permissions for a role Then you can send many elements like this.

And set Basic Auth giving the username and the password of the admin user of the esb in the request. I’ll explain in the below section about this too, if you don’t know how to set basic auth in the request.

This is all about the request and that is all what you should do. But, for creating “Permission Path” string, you’ll need to understand the “Permission Tree” of the WSO2 carbon.

Permissions Tree

This is a predefined tree in wso2. If you need to see this tree, this is in the registry location,  /_system/governance/permission.

  1. Go to WSO2 management console Main -> Registry-> Browse
  2. Just paste this above “registry path”( /_system/governance/permission) on Location field in the registry.
  3. Expand the Properties section clicking on the “+” mark of the properties.(in the right most corner)
  4. You’ll see the Value “All Permissions”. That is the display name of that permission. We’ll need this display name later.
  5. In the Entries section, List of names(admin, protected) are permissions.

You can again click one of these permissions, you’ll get the child permissions list of this particular parent permission. You can go inside and inside until a leave gets found. And while, you are moving thru this, the Location path also getting changed. If you go a location like this /_system/governance/permission/admin/login ,  then, you won’t see any more permissions list inside login permission of the admin permission. Because, login permission is a leaf of this permission tree.

Permission Path

In the permission tree section, if you did that steps correctly, then, you should see the location path of the registry. If you remove the first two locations(/_system/governance) from that location path, the rest is the permission path. That is the string that you need to send in the above request.
Let’s say you are going to set the permissions for login to management console, The permission path for that permission is “/permission/admin/login”(without quotes).

You can give the permissions for the parents.

Suppose that you gave the permission to /permission/ of the permission tree, then, this role has every permission in the permission tree.
Suppose that you gave the permission to  /permission/admin/ then, this user has the permissions for the full tree of admin.

Note

Once you send a request for setting a permission or set of permissions to a particular role, then, existing permissions of that particular role is not valid anymore. It set all the new permissions to that particular role sent in the new request. You have to list all the permissions if you need to update the permissions of a particular role like below.

Let’s say admin is the role name and it has following permissions

/permission/admin/configure
/permission/admin/manage/extensions

Now you’ll need to add the permission /permission/manage/manage_tiers also.

Then, you request body should be like.

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=”http://org.apache.axis2/xsd“>
   <soapenv:Header/>
   <soapenv:Body>
      <xsd:setRoleUIPermission>
         <!–Optional:–>
         <xsd:roleName>admin</xsd:roleName>
         <!–Zero or more repetitions:–>
         <xsd:rawResources>/permission/admin/configure</xsd:rawResources>
         <xsd:rawResources>/permission/admin/manage/extensions</xsd:rawResources>
         <xsd:rawResources>/permission/manage/manage_tiers </xsd:rawResources>
      </xsd:setRoleUIPermission>
   </soapenv:Body>
</soapenv:Envelope>

Setting Basic Auth

For setting this, you have set the a header of your request. Header name is “Authorization”(without quotes). And the value should be Basic<space><base64 encoded administrator username:password pair separated by a semi colon>. Let’s say, your user name and the password is admin/admin. Base64encode the “admin:admin”(without quotes) string. That is YWRtaW46YWRtaW4= . Then, the value of the header for this example,
Name = Authorization
Value  = Basic YWRtaW46YWRtaW4=

Validation

For validating, if the permission is set or not.

  1. Send a request correctly.
  2. Log-in to Management Console.
  3. Go to Configure -> Users and Roles
  4. Go to roles and click on the permissions of the particular role, you set the permissions.
  5. This displays the graphical permission tree.
  6. Permissions assigned should have been clicked already.

Here in this large graphical tree, it uses “display name” I described in the 4th step ofPermissions Tree section.

Hope you all understood. If you have further questions, please contact me personally or simply reply here.

Comments

  1. Nice and good article. It is very useful for me to learn and understand easily. Thanks for sharing your valuable information and time. Please keep updating mulesoft online training Hyderabad

    ReplyDelete
  2. This is realy a Nice blog post read on of my blogs It is really helpful article please read it too my blog Delete a Facebook group. you can visits our websites or toll free no +1-866-558-4555. solve your problem fastly.

    ReplyDelete

Post a Comment

Popular posts from this blog

Understanding Threads created in WSO2 ESB

WSO2 ESB is an asynchronous high performing messaging engine which uses Java NIO technology for its internal implementations. You can find more information about the implementation details about the WSO2 ESB’s high performing http transport known as Pass-Through Transport (PTT) from the links given below. [1] http://soatutorials.blogspot.com/2015/05/understanding-wso2-esb-pass-through.html [2] http://wso2.com/library/articles/2013/12/demystifying-wso2-esb-pass-through-transport-part-i/ From this tutorial, I am going to discuss about various threads created when you start the ESB and start processing requests with that. This would help you to troubleshoot critical ESB server issues with the usage of a thread dump. You can monitor the threads created by using a monitoring tool like Jconsole or java mission control (java 1.7.40 upwards). Given below is a list of important threads and their stack traces from an active ESB server.  PassThroughHTTPSSender ( 1 Thread )

How to configure timeouts in WSO2 ESB to get rid of client timeout errors

WSO2 ESB has defined some configuration parameters which controls the timeout of a particular request which is going out of ESB. In a particular  scneario, your client sends a request to ESB, and then ESB sends a request to another endpoint to serve the request. CLIENT->WSO2 ESB->BACKEND The reason for clients getting timeout is that ESB timeout is larger than client's timeout. This can be solved by either increasing the timeout at client side or by decreasing the timeout in ESB side. In any of the case, you can control the timeout in ESB using the below properties. 1) Global timeout defined in synapse.properties (ESB_HOME\repository\conf\) file. This will decide the maximum time that a callback is waiting in the ESB for a response for a particular request. If ESB does not get any response from Back End, it will drop the message and clears out the call back. This is a global level parameter which affects all the endpoints configured in ESB. synapse.global_timeout_inte

WSO2 ESB tuning performance with threads

I have written several blog posts explaining the internal behavior of the ESB and the threads created inside ESB. With this post, I am talking about the effect of threads in the WSO2 ESB and how to tune up threads for optimal performance. You can refer [1] and [2] to understand the threads created within the ESB. [1] http://soatutorials.blogspot.com/2015/05/understanding-threads-created-in-wso2.html [2] http://wso2.com/library/articles/2012/03/importance-performance-wso2-esb-handles-nonobvious/ Within this blog post, I am discussing about the "worker threads" which are used for processing the data within the WSO2 ESB. There are 2 types of worker threads created when you start sending the requests to the server 1) Server Worker/Client Worker Threads 2) Mediator Worker (Synapse-Worker) Threads Server Worker/Client Worker Threads These set of threads will be used to process all the requests/responses coming to the ESB server. ServerWorker Threads will be used to pr