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

How to protect your APIs with self contained access token (JWT) using WSO2 API Manager and WSO2 Identity Server

In a typical enterprise information system, there is a high chance that people will use different types of systems built by different vendors to implement certain types of functionalities. The APIs might be hosted in an API Manager developed by vendor A and the user management can be implemented using a different vendor (vendor B). In this type of a situation, one system will not be able to directly contact the other system but they want to use both systems in tandem. Self-contained access tokens are used in these types of situations where applications can get the token from one system and use that in another system to access protected resources. In this scenario, the second system does not need to make a contact to the first system over the network to validate the user information since the token is self-contained and it has relevant details about the user. This will improve the token processing time significantly since it completely removes the network interaction. The below fig...

WSO2 ESB creating a response for a "GET" request

When you are creating REST APIs with WSO2 ESB, you may need to send some response message back to the user when something goes wrong. In this kind of scenario, you can create a payload inside the ESB and send it back. For doing this, you can use the below configuration. <api xmlns=" http://ws.apache.org/ ns/synapse " name="LoopBackProxy" context="/loopback">    <resource methods="POST GET">       <inSequence>          <property name="NO_ENTITY_BODY" scope="axis2" action="remove"></property>          <log level="full"></log>          <payloadFactory media-type="xml">             <format>                <m:messageBeforeLoopBack xmlns:m=" http://services...

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...