Troy Myers

Things we have learned about HCI Security setup and integration

Blog Post created by Troy Myers Employee on Apr 13, 2017

  An important part of the HCI (Hitachi Content Intelligence) setup and configuration is the user security settings.   HCI only comes with one default user, but HCI will have multiple end users and different sets of users and they will all
need to be made available through the Identity providers. We think of the users in groups by function.  The most common groups are HCI system admin, Developers, and End Users.  Each group is given specific security rights
for their particular function. The details and exact settings need to be determined with the client, below is our typical setup and how we configure security.

 

HCI System Admin

   The HCI system admin typically is responsible for the day to day activities in the System to include System trouble shooting, receiving system alerts, balancing of services on nodes, granting/applying security to users. 
Depending on the client security concerns the admins may or may not be allowed access to actually see/view the data.
In our example they will have full rights to everything in the system.  I am not referring to the default account, in this example.

 

Developer role

 

  The developer role is intended for the person that will create the workflows.  This includes the Data connectors, Pipelines, and Indexes.  They should also be able to import and export plugins and workflows into the system.  Certain sites may have different rules for a test versus production environment, but in our experience they will have
access to all data manipulation activities.

 

End Users 

 

  End users are the people who will be using the processed data in the Search GUI.  We typically have several groups of end users as certain users are allowed access to certain sets and types of Data.  In our lab we have two sets of End users groups.  So we can validate that one group can see the processed data and one group cannot.    The data in our lab system represents documents with a person’s social security number. (An American person
number).  This information is highly sensitive and has legal ramifications if the wrong people are accessing or
using that information incorrectly.

 

The first step in setting up HCI security is to link the HCI system to Identity Provider.  We have
mostly been working with LDAP but several types are supported to include 389 Directory Server, Active Directory (LDAP), LDAP Compatible, & OpenLDAP.

 

Go to

 

System Configuration→ Security→ Identity Provider

 

It will ask for your AD information

 

Type= 389 Directory Server, Active Directory (LDAP), LDAP Compatible, or OpenLDAP

 

Identity provider host name= example “dc.hcpdemo.com”

 

Transport security= None, TLS Security or SSL

 

Identity provider host port= this is the Network Port # to communicate with the Identity provider 

 

User name & Password=A user that has admin rights to pull back the AD groups.

 

Domain= Example “HCP.demo”

 

Search Base DN=  Example “  dc=hcpdemo, dc=com”

 

Default Domain name= Example “hcp.demo.com”  (this filed is optional, but should be used if missed/blank upon login into HCI the user login will have to include hcpdemo.com  so Tmyers@hcp.demo.com versus tmyers if it is completed)

 

Once that is completed hit test and then update if everything is correct.

 

Once that is done we will need to go to

 

System Configuration →Security →Groups

 

At this point you should Discover groups and be able to see all the AD groups in the system. 

 

System configuration →Security →Roles

 

Roles do not come preconfigured in HCI, at the beginning I mentioned an HCI System Admin, Developer and End users.  When you create a role you will have to go into the permissions where permissions are assigned to a role.  HCI has very granular security permissions.  If you look at Content classes you will see it is subdivided into Create, Delete,
Update, & Read.   

 

For the HCI admin we typically give them all permissions with or without the ability to Query as the Admins are not allowed to see the data.  Some sites also create a separate admin that can create or edit security.

 

For our Developer role we typically choose the features around data manipulation.  I.e. Workflows, data connectors, Pipelines, & indexes.

 

For end users we start by granting the group rights to search/query the data.  We can also tie
the Index to individual roles as one way of limiting access to view the data.    This is a two-step process
listed later on. 

 

When you are finished creating roles and assigning permissions to those roles you will need to link a role to the group.  This is done in System Configuration →Security→ Groups

 

Enabling Data security is a two part process

 

 

First enable security on the index

 

Workflows  →Indexes →  Example Index  →Query Settings

 

Create a Query setting and then you will be able to enforce security on this index, under the access control by changing it to enforce document security yes.  Once this is saved you must enable it and disable the public.  Once we have applied security to the index we will need to grant our end user groups/roles access to that index.

 

Link Index to the roles

  So go back to System Configuration →Security Groups

Choose your group and edit you will see an option for indexes, assign the index to the appropriate roles.  At this point in time you should be able to log into the search screen, and see the data assigned/ restricted as
appropriate.

Outcomes