Note: This article is old and refers to Hyperglance v4.3 and earlier. (Click Here for Hyperglance v5.0 and newer).


How roles work in Hyperglance

Role-Based Access Control (RBAC) allows Hyperglance administrators to grant users access to different functionality or to different topologies.



There are 3 system roles:


  • HyperglanceUser - This grants read-access which is required to login to Hyperglance. All users must be given this role (including admins).
  • HyperglanceAdmin - This grants access to all functionality and to all topologies.
  • HyperglanceActionsUser - This grants access to all Actions (i.e. write-access).



Other roles grant access to individual topologies:

  • The name of the role is simply the name of the topology subset to which you want to grant access.
  • The name of a topology subset can be found from the Hyperglance client - click a node and the entity panel will be displayed. The name of the topology that this node belongs to is displayed in this panel at the top in the dark-blue section.
  • The name of the topology subset would usually be derived from the account alias that you have entered in the admin panel.
  • Be aware a topology subset named role will give an access to any topology subset with the same name across all of your datasources.
    Example: Assuming you have Azure and Openstack datasources and both have a "prod" topology subsets, adding "prod" role will grant access to both.


To create users and manage their roles Hyperglance can be integrated with an LDAP service. Alternatively a file-based user-store is available.


Instructions to configure Role-Based Access Control are given below. Any changes should be made while the Hyperglance Server is stopped.




1) Enable RBAC:


Open for editing: /opt/wildfly/standalone/deployments/hgs.ear/lib/common.jar/runtime.properties

Change the rbac.enabled property to true: rbac.enabled=true




2) Configure LDAP integration (optional):


Users and roles can be managed through an LDAP service like Active Directory.



Edit the file: /opt/wildfly/standalone/configuration/standalone.xml

 

Locate the LDAP login-module section. It starts with: <login-module code="Ldap"

You may need to provide values for each <module-option> tag within this section so as to be appropriate for your specific LDAP service.

 


Many of these settings have been configured or formatted for Active Directory already, so if you are using AD then the only the following options that you will need to alter are:


  • java.naming.provider.url - Please provide the URL to an Active Directory server. 
  • principalDNPrefix - Please provide text that will be automatically prefixed onto the username when authenticating, e.g. MYCOMPANYDOMAIN\ 
  • rolesCtxDN - Please provide the distinguished name to the context to search for user roles, e.g. OU=roles,DC=mycompany,DC=org



More details about configuring the LDAP integration are available online:




Note: The entire LDAP login module can be removed entirely if LDAP authentication is not desired.





3) Configure the file-based user-store (optional):


Besides using LDAP, users and roles can also be created and managed via configuration files.



To add or remove users edit the file: /opt/wildfly/standalone/configuration/users.properties

Entries take the format of: username=passwordHash


The passwords must be SHA-256 hashes that are Base64 encoded. There are online tools that can do this, for example: https://quickhash.com/  (To use this tool, set the 'Algorithm' dropdown to 'SHA-256 (SHA-2)' and the 'Output Format' dropdown to 'Base64 Encoding').



To assign roles to users edit: /opt/wildfly/standalone/configuration/roles.properties

Entries take the format of: username=role1,role2,role3



Note: By default these files are configured to create the initial admin user (with password: admin). This user can be removed or edited if desired.