WSO2TORIAL Permissions, Management UI and Services

Whenever we do a WSO2 training, one of the first labs is adding a user and a role to the system. In case of the ESB this is often a ‘tester’ user that has limited functionality. Originally we added just the following three pernissions:

1. Login
2. TryIt
3. Monitor

In previous versions of the ESB this allowed to view the Services deployed on the ESB. The current version of the ESB however (as well as 4.9.0 version) displays an empty list.

What are we aiming to do?

We are going to investigate which permission is required by a user to be able to view the list of services. To do this we are adding a user, initially without any role. We take the following steps:

1. Open a browser and access https://localhost:9443/carbon (allow access without a valid certificate if needed)
2. Login to the ESB as default user admin and password admin
3. Select Configure Tab
4. Select User & Roles option from menu
5. Choose Users and click Add New User action
6. Complete with name tester and password tester
7. Click on Finish to complete user creation

Now we have added a user, The next step is to actually give permissions since this user cannot do anything. Permissions are assigned to a user through roles. Roles group one or more permissions which are used by a particular jobrole. Roles are used in WSO2 products for various reasons. For instance to login to the API Manager store or publisher but also for runtime message mediation like when working with XACML Entitlements for services.

For now our user needs permissions to view the services list in the admin console.

Adding permissions

To do that we will add a role to the system.

1. Select User & Roles option from menu
2. Choose Roles Management and click Add New Role
3. Set the role name to Tester and click Nex
4. Select Login, Tryit & Monitor permissions and click Next
5. Select the user created on previous step to add to role
6. Click Finish to complete role creation and assignation.
7. Logout and Login as user tester, check the tabs and options this user is able to perform.

As said and show in the first screen shot, these permissions result in an empty list of services. So how do we go about making the list visible and the tester able to test the Axis2 Echo service?

Permissions and UI

Unfortunately, there is no list of permissions and what services they are linked to. We mention services since every Management UI will (under water) call one of the Admin Services in WSO2. It does not matter what product you use, all WSO2 products work this way with admin and even hidden services.

We asked WSO2 if such a list exists and the answer is NO. So it is either taking the source code and determining it from there or, less work and easier, trial and error. 

So we started by adding permissions to the tester role to see if we can actually see the service.

In this case we started out with the high level permissions like Manage, added it and removed permissions until we ended up with the right permission to be added. In this case it was Mediation.

So the permissions looked like this:

Test the service

Now we can actually see the deployed services and we can start and TryIt.

1. As user tester, select Services->List option from the Main tab
2. Click on WSDL1.1 cell of echo service to access its definition (opens in a new browser tab).
3.  On ESB Console, in the Tools tab, select tryIt option and introduce the WSDL URL

On ESB Console, in the Tools tab, select tryIt option and introduce the WSDL URL

1. Click on Try It to test the service (popup window will be opened showing service detailed information) Note that Internet Explorer browser does not support the TryIt tool. Use Chrome, Mozilla or Firefox for this step.
2. Select echoString operation, introduce a text between <in> and </in> tags of the XML payload body.
3. Click the Send button
4. The service executes and returns the original string sent.

Alternatives

At this moment we have not found any other way to map permissions to Admin Services. The permissions are actually part of the registry (/_system/governance/permission) and can be set using the AdminServices (https://localhost:9443/services/UserAdmin).

So for now it is trial and error to find out what permissions need to be set for a product / role combination.

Read also our other WSO2 tutorials and blogs, written by our WSO2 Gurus. In case you need WSO2 support, contact the Yenlo WSO2 Guru team to get WSO2 Development Support or WSO2 Operational Support. Of course we do deliver excellent WSO2 training services as well, based on reallife WSO2 tutorials.

Thanks to Thijs Volders for his contributions to this blog.