Configuring Elastic Security Plugin

To view Kibana reports based upon user authorization, you can configure ElasticSearch Plugin for:

• Role and User Based Authorization
• Field Level Authorization

You can enable this feature by configuring different combinations of role, user Id, user assigned profiles, and Index. Configure appropriate Elastic queries and field restrictions in the Configuration tab of the Admin module.

To update the Elastic queries:

1. Access Admin Portal and Login.
2. In the left navigation pane, click Configuration. 
3. Click Manage Role. The Manage Role screen appears.
   
   
4. Click Specify Role Access. The Assign appropriate access to the role dialog box appears. 
5. Click Reporting and expand Data Access.
   
   
6. Make appropriate changes for various Roles defined based upon your business needs and then Save the configuration.

Role and User Based Authorization

Kibana reports can be viewed on the basis of the attributes of the user- Role, UserId & Profile and others. Users are authorized to view only those records that they are assigned to. This is applicable to both types of roles- inbuilt & custom.

You can update configuration based upon the below mentioned attributes:

• Role: The role assigned to the user as per the authentication system. For example, Admin, super Admin and so on.
• UserId: The userId of the user as per the authentication system indicated by ${attr.jwt.userId}
• User Profile: The list of profiles assigned to the user as per the authentication system indicated by ${attr.jwt.profile}. The list is currently configured for both basic authentication and custom authentication.

This section discusses about a business use case example where few roles, profiles and users have been taken into consideration. All the below data is used to configure Elastic Security plugin to generate Kibana report.

 

Role	Profile	User
Role1	Profile1	User1
Role2	Profile2	User2
Role3	Profile3	Profile3

 

 

 

 

 

 

 

A user-role mapping and a user-profile mapping is done below:

 

User Role Mapping
User1	Role1
User2	Role2
User3	Role3

 

 

 

 

 

 

 

User Profile Mapping
User1	Profile1 Profile2
User2	Profile2 Profile3
User3	Profile1

 

 

 

 

 

 

 

The following sample data is available in the Elastic:

 

No. of Records Associated with Profile
Profile1	7 records
Profile2	5 records
Profile3	6 records

 

 

 

 

 

 

Configure below Elastic queries for Role1, Role2 and Role3 respectively.

Elastic Query configured for Role1:
 

Role1: {"terms": {"TransactionProfileName": "${attr.jwt.profile}"}}

 

Elastic Query configured for Role2:

 

Role2:     {"terms: {"TransactionProfileName": "${attr.jwt.profile}"}}

 

Elastic Query configured for Role3:

 

Role3:      {"terms": {"TransactionProfileName": "${attr.jwt.profile}"}}

 

Once the configurations are done, generate report in Kibana. Detailed sample description of the report is given below:

• User1: gains access to 12 records as user1 is assigned profie1 and profile2 of rpa-trans-* index
• User2: gains access to 11 records as user2 is assigned profie2 and profile3 of rpa-trans-* index
• User3: gains access to 7 records as user3 is assigned profie1 of rpa-trans-* index
   

Search Query Execution

When the Elastic plugin receives the index search query from Kibana UI, the plugin attempts to fetch the user information, such as username, user role, and assigned user profiles list.

Elastic plugin compares the received information with the restrictions defined in the configuration. If index successfully matches the restrictions for a particular role, it fetches the restriction query and checks the possibility of injecting any value either in profile list (profile1 and profile2 in this case) or username before executing the query with restriction. 

 

Below is the syntax of Elastic Query: 

 

• Bool Filter

You can use bool filter to combine multiple filter clauses such as ‘must’, ‘must_not’ and ‘should’ clause. Validate that the:

• must clause matches the Boolean expression in all the documents
• must_not clause excludes the documents that contain the stated Boolean expression
• should clause matches any one of the Boolean expression in the documents
• If there is no must clause available, at least one of the should clause must match a document

For Example:

 

“bool”: { “must”:    { “match”: { “title”: “quick” }}, “must_not”: { “match”: { “title”: “lazy” }}, “should”: [ { “match”: { “title”: “brown” }}, { “match”: { “title”: “dog” }} ]

 

 

The result from the above query includes any document whose title field contains the term ‘quick’ and excludes those documents that contain ‘lazy’. While the should clause that contains two Boolean expressions implies that a document is not required to contain either the term ‘brown’ or ‘dog’, however, if any of these two terms are present then consider it as more relevant.

For example; The result from the above query checks if the TransactionProfileName field contains the given profile or none of the profile is assigned to it. To know more about Elastic Query Syntax, refer, https://www.elastic.co/guide/en/elasticsearch/guide/current/bool-query.html

 

Field Level Authorization

AssistEdge Kibana reports enables you to apply field level restriction on a particular Elastic Index based upon User Role. As a result, you can view records with only non-restricted fields that you are authorized to. This is applicable for both type of roles- inbuilt and custom role.
You can perform configuration in Admin module based upon the below mentioned attributes:

• User Role: The role assigned to the user as per the authentication system.
• Index Name: The name of index on which Field Level Security (FLS) restrictions needs to be applied
• Field Name: The list of fields of index on which restrictions needs to be applied.
   

This section discusses about the FLS (Field Level Security) with an example. Below are the accesses (inbuilt in the product) and their corresponding example of queries:

 

Role	Fields	Index
Super Admin	Arguments, AnonymizedArguments	datareport*
Role1	MaskedArguments, AnonymizedArguments
Role2	MaskedArguments, AnonymizedArguments

 

• Super Admin: Has access to all the fields except MaskArguments
• Role1, Role2: Has access to all the fields except Arguments
• datareport*: Is the Elastic Index that contains all kind of customized business report data
   

 

Data in Elastic Index- Datareport*

 

[  {     "Arguments": {       "name": "Arguments1"     },     "AnonymizedArguments": {       "name": "AArguments1"     },     "MaskedArguments": {       "name": "MArguments1"     }  },   {     "Arguments": {       "name": "Arguments2"     },     "AnonymizedArguments": {       "name": "AArguments2"     },     "MaskedArguments": {       "name": "MArguments2"     }  }]

 

Field Level Restriction configured for Role1:

 

 

Field Level Restriction configured for Role2:

 

 

Once the configurations are done, generate report in Kibana. Detailed sample description of the report is given below:

 

• For Role1

 

[ {         "Arguments": {       "name": "Arguments1"     },     "AnonymizedArguments": {       "name": "AArguments1"     }  },   {     "Arguments": {           "name": "Arguments2"     },     "AnonymizedArguments": {       "name": "AArguments2"     }  } ]

 

• For Role2:

 

[     "AnonymizedArguments": {       "name": "AArguments1"     },     "MaskedArguments": {           "name": "MArguments1"         }  },   {     "AnonymizedArguments": {       "name": "AArguments2"     },     "MaskedArguments": {       "name": "MArguments2"     }  } ]

 

Search Query Execution

When the Elastic plugin receives the index search query from Kibana UI, the plugin attempts to fetch the user information, such as username, user role, index name and fields of elastic index.
Elastic plugin compares the received information with the restrictions defined in the configuration. Search result is displayed if index successfully matches the field level restrictions for a particular role.