Ben Isherwood

HCI: Authentication and Authorization

Blog Post created by Ben Isherwood Employee on Jun 7, 2017

Hitachi Content Intelligence provides a REST API, CLI, and UI in the admin application for the custom management of both authentication and authorization.


Let's dive right into how this works...


Identity Providers


First, administrators register Identity Providers with the HCI system by selecting and configuring any of the available plugin implementations.


Currently, “Active Directory”, “LDAP compatible”, “OpenLDAP”, and “389 Directory Server” plugins are available today:



In order to integrate with other identity providers such as Keystone, IAM, Google, or Facebook, an "Identity Provider" plugin could be produced for each. Each plugin requires different configuration settings, which the UI displays dynamically.


Adding an “Active Directory” Identity Provider  (Admin UI > System Configuration > Security > Identity Providers):



Listing configured Identity Providers:





Next, you may use these Identity Providers to discover and map Groups into HCI.


Registering a Group from the “Active Directory” Identity Provider:



Listing all registered groups:





Groups may be assigned one or more Roles. Roles are groups of one or more Permissions. Each HCI service can register a custom set of permissions that can be enforced by the system. Administrators combine permissions into custom roles they would like to use for a specific application, and assign one or more of those roles to the registered groups.


Creating the “Admin” role:



Editing permissions for the “Admin” role:



Group assigned the “Admin” Role, effectively giving all permissions to that group:



Only groups that have been configured with specific roles will have the permissions required to access the corresponding set of services/APIs within the system. When granting permissions to a user, the corresponding areas of the UI will become available and REST API requests would be allowed. When disabling permissions for a user, the admin UI will also dynamically remove those sections of the UI to prevent them from being accessed and any REST API or CLI requests for those services would fail with an error.




When logging into any HCI application, users may choose the security realm to utilize, which will use the corresponding identity provider for authentication. Each security realm name associated with each Identity Provider is chosen by the administrator:




The application will then:

  • Authenticate the user against the selected Identity Provider
  • If successful, determine what group(s) that user belongs to
  • Given group membership, determine which roles and permissions have been assigned to that user
  • Enforce the that user can access services they have been granted permission to access, and cannot access services for which they have not been granted access.


I hope this demonstrates the ability of HCI to easily integrate to existing customer directory services and manage fully customizable roles for any given organization and any particular application.


Thanks for reading!