Filtering Responses by User Role
When you work with data services, you can control access to sensitive data for specific user roles. This facility is called Role-based content filtering. It filters data where specific data sections are only accessible to a given type of users.
To use this feature, it is necessary to ensure that the data service is secured with a UT policy. Note that you need to use WSO2 Integration Studio to apply security policies to a data service. Therefore, if you have already created the data service using the management console as explained below, import your data service file to the tool and apply the UT security policy.
See the instructions on using WSO2 Integration Studio to develop data services.
Define user role-based result filtering
When you work with data services, you can control access to sensitive data for specific user roles. This facility is called Role-based content filtering. It filters data where specific data sections are only accessible to a given type of users.
Follow the steps below to filter a data service according to a specific user role.
Log on to the management console and select Services > List under the Main menu.
The Deployed Services window appears, which lists out all the currently active services and service groups. Click the data service you want to edit to open its dashboard.
In the dashboard, click the Edit Data Service link. You can directly edit the XML file or use the management console. We use the latter in this example.
Navigate to the Queries page of the data service, select the query you want to edit and Edit Query.
In the Output Mappings section of the query, edit the field that needs to be filtered and tick the appropriate user role in the Allowed User Roles section.
Once all the required roles are set, the result entries of the Edit Query page look as follows in this example:
Save the changes.
Extend role-based filtering via a custom authorization provider
In the ESB profile of WSO2 EI, you can filter content to specific user roles by taking roles from the primary user store of the server. However, this extension provides the flexibility for you to develop data services by plugging in a mechanism to provide those role details from any preferred external source (e.g., third party identity provider, JWT token etc.). Hence, in data integration scenarios where data needs to be filtered based on the user who requests those data, follow the steps below to plug in a custom authorization provider.
Create a Java Project and create a Java class (e.g.
SampleAuthProvider), which extends theorg.wso2.carbon.dataservices.core.auth.AuthorizationProviderinterface and the below methods.SampleAuthProvider Class
public class SampleAuthProvider implements AuthorizationProvider { public String[] getUserRoles(MessageContext messageContext) throws DataServiceFault { String[] roles = {"user", "manager"}; return roles; } public String[] getAllRoles() throws DataServiceFault { String[] roles = {"admin", "client", "user", "manager"}; return roles; } public String getUsername(MessageContext messageContext) throws DataServiceFault { return "saman"; } public void init(Map<String, String> map) throws DataServiceFault { } }Build the project and place the JAR file in the
<EI_HOME>/lib/directory.Start WSO2 EI and open the Management Console. For instructions, see Running the Product.
Create the data service. For instructions, see Creating a Data Service from Scratch .
When you invoke the data service you created, you will view a response as shown in the example below.
Since the sample Java class above returns hard-coded “{“user”, “manager”}” roles, the response below returns only the rows those roles can view.
<Persons xmlns="https://localhost:9443/carbon/ds/addQuery.jsp?queryId=query1">
<Person>
<PersonID>4</PersonID>
<FirstName>john</FirstName>
<Address>12, seren street, TN</Address>
</Person>
<Person>
<PersonID>1</PersonID>
<FirstName>Tom</FirstName>
<Address>34, baker str, London</Address>
</Person>
<Person>
<PersonID>2</PersonID>
<FirstName>Jack</FirstName>
<Address>324, Vale str, PN</Address>
</Person>
<Person>
<PersonID>3</PersonID>
<FirstName>Allan</FirstName>
<Address>23, St str, NW</Address>
</Person>
</Persons>You can extend this functionality to extract required roles from the JWT tokens, or invoke third-party identity providers to fetch roles etc. to do role-based filtering in data services.