Oracle Endeca (2.3) Record Level Security

A common task with any BI solution is to implement some type of security whether it be content, or data based. Tools for managing content security in Oracle Endeca Information Discovery are fairly prominent in the Admin pages within Studio, managed through a set of security objects: User Groups, Roles and Communities. Data security, on the other hand, is less obvious and although it is covered it the documentation, a lot of components need to be brought together to proved the complete solution. This blog post therefore will cover the basics of security within Endeca Information Discovery, as these basic security objects are required in order to explain the implementation of record level security.

If you are familiar with Oracle EID basic security please skip down to Assigning Record Security. Otherwise, the following scenario uses a simple ‘survey’ data set where one hundred survey have been carried out across two stores; Taylor Street (54) and Fishermans Wharf (46).

There is a also a requirement that only the manager of each store can see that store's data - something we'd call in relational databases "row-level security", and in the world of Endeca, "record-level security". In this example there are two users who manage different stores; "Angela Salesmanager" who manages Fishermans Wharf and "Paul Salesperson" who managers Taylor Street

To implement this example of record-level security, firstl start by creating two users within Studio, by clicking on the Welcome menu on the top left of the screen and then selecting Control Panel, like this:

Creating Users

On the left menu pane under the Portal section select Users and click on Add button.

Enter the users details (for example, "Anglea Salesmanager") and click Save.

Once the user is created within Studio, set their password by clicking on the password link on the right hand menu. Repeat this for the second user so that there are two new users; Angela Salesmanager and Paul Salesperson in this example.

Creating User Groups

The next step is to create two user groups to which we will add these users; this step isn't mandatory, but it's good practice to assign permissions to groups rather than individual users, for the sake of manageability. Click on the User Groups menu item then on the Add button.

Add the users group Fishermans Wharf and click Save.

Repeat this for both store groups; Fishermans Wharf and Taylor Street.

Assigning users into groups

 Once the groups are created within Studio, click on the Action menu and select Assign Members.

Now click on Available, then tick the appropriate user and click on Update Associations.

Assign the appropriate users into the correct user groups:
Anglea Salesmanager =  Fishermans Wharf
Paul Salesperson = Taylor Street

Creating Roles and mapping to User Groups

Next create two roles in the same way as User Groups, prefix them with DF to make them stand out as roles, which will be used for data filters.

Once the roles have been created click on the Actions menu then Assign Members to assign the respective User Groups.

Ensure Assign Members  is highlighted, then click on User Groups then Available and tick the corresponding User Groups then Update Associations.

Assign the appropriate user groups into the roles:
Fishermans Wharf = DF Fishermans Wharf
Taylor Street = DF Taylor Street

By this stage, there should be two users assigned to two different user groups and those groups assigned to two user roles.

User | User Group | Role
Anglea Salesmanager =  Fishermans Wharf = DF Fishermans Wharf
Paul Salesperson = Taylor Street = DF Taylor Street

Assigning Record Security

The basic security is now set up, next the record security needs to be defined.This is done by modifying the Data Source to effectively map a filter to a role, lets breakdown the configuration:

The default configuration is still required:

"datastoreName": "GCBC", "description": "Rittman Mead Training Data", "name": "GCBC", "port": "7770", "server": "localhost"

The property various security properties need to be set to true, the rolePermissionsMultiOr allows multiple values to be assigned to a filter.

"inheritSecurity": "true", "rolePermissionsMultiOr": "true", "securityEnabled": "true",

The next section is where the actual filters are defined and assigned. The filder can be give any name and the column that needs to be filter and its value are defined under the recordFilter.

"securityFilters": {
"FISHERMANSWHARF": { "class": "", "recordFilter": "OR(StoreName:Fishermans Wharf)" }, "TAYLORSTREET": { "class": "", "recordFilter": "OR(StoreName:Taylor Street)" } }

Its also worth noting that multipal values can be assigned in record filters and even on different columns. For example:

Name:Taylor Street,Month:01-2012)

Finally the securityFilters are assigned to an existing role.

"rolePermissions": {
"DF Fishermans Wharf": ["FISHERMANSWHARF"], "DF Taylor Street": ["TAYLORSTREET"] },

Here is the full configuration:

{ "datastoreName": "GCBC", "description": "Rittman Mead Training Data", "name": "GCBC", "port": "7770", "server": "localhost" "inheritSecurity": "true", "rolePermissions": { "DF Fishermans Wharf": ["FISHERMANSWHARF"], "DF Taylor Street": ["TAYLORSTREET"] }, "rolePermissionsMultiOr": "true", "securityEnabled": "true", "securityFilters": { "FISHERMANSWHARF": { "class": "", "recordFilter": "OR(StoreName:Fishermans Wharf)" }, "TAYLORSTREET": { "class": "", "recordFilter": "OR(StoreName:Taylor Street)" } }, }

Its really important to note that everything here is case sensitive and will probably be the cause of errors implementing this solution

Now we can log into the system using the uses we created earlier, and as you can see Angela can only see Fishermans Wharf and Paul can only see Taylor Street.



Subscribe to Rittman Mead

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!

Subscribe to Our
Monthly Newsletter!

* indicates required