Skip to main content

Managing GREG publisher menu based on user permissions

The default behaviour of GREG is to show all the menu options related to each asset. Even though you can enable/disable the asset type based on the user permissions you cannot manage the different options of the individual asset.

Prerequisite

In order to try this use case first you would need to download the Governance Registry Product. You can download it here [1]

Overview

For each asset the GREG publisher would show the following menu. This is the menu shows for a esdl based soap service.



If we have a requirement where we need to control the users who are able to create Associations there is no direct way in which this is supported. In other words there is no way of managing these menu items based on role permissions. But the good news is this can be accomplished by doing a few customizations in the GREG. Below steps will guide you through how you can allow/disable the Association tab based on user permission with GREG.

Let's get started

1) First let's create a new user by logging into the managements console and assign the user the publisher role.

2) When the user logs in he would be able to see the menu as shown in the image above and can also access the Associations tab. Now lets change the flow so that this user would not be authorized to access the associations tab.

3) Let's assign the permission 'Association' which is in the permission tree as the permission which authorizes the users to add/view associations for the assets. So we need to log in to the management console and assign the permission to the created new user's private role.







4) Now that we have selected this as our custom permission to check before displaying the Associations, we need to map this permission in the publisher app. For that Open the file wso2greg-5.1.0/repository/deployment/server/jaggeryapps/publisher/extensions/app/greg-publisher-defaults/permissions.js and add the following entry below the Permissions.GREG_COMMUNITY_FEATURES entry.

 Permissions.GREG_ASSOCIATIONS = '/permission/admin/manage/resources/associations';

5) Next we need to check for this permission before we display the UI menu item for the 'Associations'. For this we need to create a method to check the permissions. Add the below method to the top of the file wso2greg-5.1.0/repository/deployment/server/jaggeryapps/publisher/extensions/app/greg-publisher-defaults/asset.js below the assetManager() function.

 var hasAssociationPermission = function () {
   var server = require('store').server;
   var tenantId = server.current(session).tenantId;
   var username = server.current(session).username;
   var isAuthorized = rxt.permissions.hasAppPermission("GREG_ASSOCIATIONS", tenantId, username);
   return isAuthorized;
};


6) And then before displaying the menu item we can check for this permission in the same file. The menu item is displayed by the method associationMetaDataPopulator()

 if (hasAssociationPermission()) {
   log.debug('adding link');
   entry = {};
   entry.name = 'Associations';
   entry.iconClass = 'btn-lifecycle';
   entry.url = this.buildAppPageUrl('associations') + '/' + page.assets.type + '/' + page.assets.id
   ptr.push(entry);
}

Even though we hide the menu item still the API could be accessible. If we directly try to access.

eg: https://localhost:9443/publisher/pages/associations/soapservice/b1faa464-bfdd-475f-ab22-dc529ce86f2f we would be able to access it.

In order to protect the API you need to add the changes below.

7) In the file wso2greg-5.1.0/repository/deployment/server/jaggeryapps/publisher/extensions/app/greg-apis/app.js add the permission to the ‘association’ block as below.

 {
   url:'association',
   path:'association.jag',
   secured:true,
   permission:'GREG_ASSOCIATIONS'
},

In the file wso2greg-5.1.0/repository/deployment/server/jaggeryapps/publisher/extensions/app/greg-associations/app.js add the permission to the ‘association’ block as below. (attached greg_associations_app_js_diff)

 {
   title:'associations',
   url:'associations',
   path:'associations.jag',
   secured:true,
   permission:'GREG_ASSOCIATIONS'
}

Now we have done all the required configurations. We can now test the scenario. So lets login with the user which we created.

Since he has the 'Association' permission he would be able to see the menu item and navigate to the Associations page.

Now let's go to the management console and remove this 'Association' permission from the user's private role. Go to the roles section and select the private role where we added the Association permission before and untick it and update.

Now using the same user log in to the publisher and go to the asset details page. You would see that the 'Associations' menu item is not there now. Since we removed the permission.


Now directly try to access the Associations page by giving the direct url.
eg: https://localhost:9443/publisher/pages/associations/soapservice/d0c0e075-b4db-43f2-83f2-8ea5d41a69e5. You will see the user is unauthorized.





Now we have successfully restricted this menu item based on the user permissions. Simillarly you can try this for other menu options as well

References:

[1] http://wso2.com/products/governance-registry/
[2] https://docs.wso2.com/display/Governance510/Users+and+Roles


Comments

Popular posts from this blog

Processing large payloads with the esb script mediator iteratively

Overview WSO2 ESB uses Rhino engine to execute JavaScripts. Rhino engine converts the script to a method inside a Java class. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters, since the Script mediator converts the payload into a Java object. However, you can use the following alternative options to process large JSON data volumes. The script mediator which is used in ESB is powered by the Rhino engine. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters which is a limitation in the script mediator being used in the esb versions less than 5.0.0. In ESB 5.0.0 there is a higher capability to process larger payloads using script mediator. In order to process such large payloads we can follow the below two approaches. 1. Replace the javascript tranformation logic using java code by writing a custom mediator. [1] 2. Break down the large payload and execute them as sections using

Invoking external endpoints using the call mediator in wso2 api manager

Introduction In API Manager if you need to do any service chaining use cases the call mediator comes in handy. If you need to use the response received by invoking one endpoint and then use it to invoke another endpoint you can use the call mediator in API Manager. The call mediator behaves in a synchronous manner. Hence, mediation pauses after the service invocation and resumes from the next mediator in the sequence when the response is received. You can read more about the call mediator in the wso2 esb documentation [1] . In api manager 1.10.0 the call mediator works in the blocking mode. Prerequisite Before we can use the call mediator in API Manager 1.10.0 we need to make the following changes to some configs. We need to comment the jms transport sender in axis2_blocking_client.xml found in the location APIM_HOME/repository/conf/axis2. This will resolve the jms sender initialization issues.   <!--transportSender name="jms"                      class

Exposing a SOAP service as a REST API

In this post i will be explaining how we can transform a SOAP based backend to receive requests in a restful manner through the WSO2 API Cloud. Steps. First log into the WSO2 Cloud and navigate to the API Cloud. In the API cloud select the option to add a new API. We will be creating an API to demonstrate an invocation to the backend soap service ws.cdyne.com/phoneverify/phoneverify.asmx?wsdl Give a name, context and version to the API and add a resource name with a GET Method. The resource name can be anything which you like since we will invoke the actual service usiing a custom sequence. Mention the URI template as indicated in the below screenshot. Next go to the implement tab. And select the endpoint type as HTTP/SOAP Endpoint and specify the endpoint as http://ws.cdyne.com/phoneverify/phoneverify.asmx. There is an important step we need to do here. We need to set the SOAP version for this request. In order to do that we need to select the advanced option for the e