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.
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 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.
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