Authorization at the Console API Layer

The Trusted model uses an ASCII file as a simple yet effective entitlement server. This has the benefit of being easily distributed to all nodes, making it a very scalable mechanism. A scan of the ASCII file for information about the user determines if the request is granted.

Users are explicitly granted or denied access through the access control file. A user who is not in this file is not allowed to perform any operations on the TIBCO Hawk system. Access control information is in a plain ASCII file located in the HAWK_HOME/examples/security folder.

Copy this file to CONFIG_FOLDER/security manually. See Access Control File, for more details.

Authorization at the REST API Layer

You can configure agent level authorization in Hawk Console. The user can only view the agents and the domains for which he has required privileges. This access control is also applicable over the statistics displayed on domain cards, i.e. the statistics (alert counts) displayed in domain card view displays the summation of agents based on the user privileges.

The authorization is implemented with the help of the configuration file hawkconsole_user_access_list.cfg. Make sure that you have performed the following tasks before implementing this authorization mechanism:

Uncomment the hawkconsole_user_access_list option in the hawkconsole.cfg file. This enables the Hawk Console to identify the users and their privileges based on the file path provided for that configuration option.
Ensure that the agent for which you want to implement this authorization belongs to a domain with a trusted security model.

Example of hawkconsole_user_access_list.cfg file

#
# This file is used by agent running with
"COM.TIBCO.hawk.security.trusted.Trusted" security model.
#
#
# Explanation of Settings:
#
# This file provides authorization or filter level for node/agent for
WebConsole application.
# This doesn't include microagent and methods level authorization, even
if the microagent and methods are defined, then those will be ignored.
# The node column can have a node/agent name or "agent dns domain" or
"agent:dns:domain" format.
# Wild card * is supported in both user and node column.
# Access restrictions can be defined for an user by starting record with
!
# In case of any conflict in grant and restriction, the restriction will
have the precedence.
# Examples
# 1: admin will have access to all agents/nodes and domains
# 2. user1 will have access to agent1 under domain1 with dns dns1.
# 3. user2 will have access to all agents/nodes under domain domain2
and any dns.
# 4. user3 will have access to agent3 if agent3 doesn't belong to
domain3
#
# File format:
#
# user node
# access
# &
# restrictions
#
# admin *
admin *
user1 "agent1 dns1 domain1"
user2 "* * domain2"
user3 agent3
!user3 "* * domain3