Role to Privilege Authorization

Privileges

Privileges are used to control access to specific resources, for example administrative commands.

Privileges are granted to roles. Each role defines a set of privileges associated with a specific resource. The only valid privilege for administration commands is AdminRunCommand. The AdminRunCommand privilege indicates that the command specified as a resource can be executed by the associated role. Administrative command resource names are specified as <target>.<command>. Other resource types support different privileges and resource naming conventions.

Roles and their associated privileges are defined using configuration. For example, the following configuration file allows the administrator role to run the start mytarget and stop mytarget administrative commands, and the monitor role to run the display mytarget command.

name = "my-target-role-mappings"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    RoleToPrivilegeMappings =
    {
        roles =
        {
            administrator =
            {
              privileges = [
		    {
                      resource = "mytarget.start"
                      privilege = "AdminRunCommand"
                  },
                  {
                      resource = "mytarget.stop"
                      privilege = "AdminRunCommand"
                  }
		  ]
             }
            monitor = 
            {
              privileges = [
		    {
                      resource = "mytarget.display"
                      privilege = "AdminRunCommand"
		    }
		   ]
              }
         }
    }
}

Once the above configuration is activated, the security service will enforce that only principals who have been assigned the administrator role are allowed to run the start mytarget and stop mytarget commands and those who have been assigned the monitor role are allowed to run the display mytarget command.

Warning

Failing to grant privileges to an administration command will prevent those commands from being run by any principal.

Roles

The security service supports a set of predefined roles that are used to grant privileges to principals.

The predefined roles are:

  • administrator — allows modification of the operational state of a node. This includes control of a node's lifecycle, e.g. Installation, starting, stopping, and removal.

  • monitor — allows monitoring of the operational state of a node.

Each of these roles is described in more detail below.

Administrator Role

The administrator role assigns administrative privileges to principals. The administrator role is automatically granted to the user who installed the node. That user always has full administrative control of the node when logged in on the same host. All operations which modify the operational behavior of a node may only be executed by principals which have administrator role privileges. Operational control of a node occurs via epadmin and JMX. This role should be granted to principals that can perform operations that modify the node state.

Monitor Role

The monitor role assigns system monitoring privileges to principals. This role is granted run permission to all display-type administrative operations. Consequently, this role should be granted to principals who can monitor node status. Such principals will be able to display the state of a node, but will be unable to run administrative operations which change the operational state of the node.

Role to Privilege Authorization

Node administration exposes the ability to create user-defined roles with any mix of command privileges. Users can be members of more than one role.

Authorization consists of checking whether one of a user's roles has a particular privilege, optionally on a specific resource (such as a LiveView table or alert, a StreamBase stream, or a node administration command). You specify information to perform authorization checks in a RoleToPrivilegeMappings security file.

You can have any number of role-to-privilege mapping configuration files active on a node; they are all merged into one database. You add mappings by activating a new configuration using the epadmin activate configuration command, remove them by deactivating the configuration with epadmin deactivate configuration, and update them by activating a new version of an existing configuration.

StreamBase supports a fixed set of privileges for node administration, LiveView engine operations, EventFlow engine operations, and LiveView Web create permissions.

A RoleToPrivilegeMappings configuration file grants privileges one at a time to named roles. If no resource property accompanies a privilege, then it is granted to all resources of the appropriate type.

For example, a LiveView-specific configuration file might take the form of the following partial example:

name = "node24privmaps"
version = "4"
type = "com.tibco.ep.dtm.configuration.security"
configuration = {
  RoleToPrivilegeMappings = {
    roles = {
      LVAdmin = {
        privileges = [
        {
          privilege = "LiveViewAll"
        }
      ]
      }
      LVUser = {
        privileges = [
        {
          privilege = "APIConnect"
        },
        {
          privilege = "LiveViewTableList"
        },
        {
          privilege = "LiveViewTableAll"
          resource = "ItemsSales"
        }
      ]
}}}}

This example grants the LVAdmin role full rights over all LiveView server actions. It grants the LVUser role the ability to connect to the server (APIConnect), the ability to list all tables (because no resource is specified), but grants full control over the ItemsSales table.

There are many LiveView-specific privileges grantable, but only a few StreamBase and LiveView Web specific privileges. These are listed in the RoleToPrivilegeMappings section of the security documentation page.

You can also grant or withhold permission to run epadmin administrative commands. Specify these privileges with a two-part resource name consisting of the epadmin verb and target linked by a period. Thus, you can grant the rights to use install.node, display.services, activate.configuration, or any other combination of commands. For example:

configuration = {
    RoleToPrivilegeMappings = {
        roles = {
            administrator={
              privileges = [
		  {
                    privilege=AdminRunCommand
                    resource="tunable.get"
                },
                {
                    privilege=AdminRunCommand
                    resource="tunable.reset"
                },
                {
                    privilege=AdminRunCommand
                    resource="tunable.set"
                }
		 ]
            }
         }
      }
   }

Role to Privilege Mappings

The RoleToPrivilegeMappings object defines the roles and their associated privileges. Figure 1, “RoleToPrivilegeMappings relationships” shows the relationships to other configuration objects.

RoleToPrivilegeMappings relationships

RoleToPrivilegeMappings relationships

A detailed description of the configuration object properties is in RoleToPrivilegeMappings object properties and a snippet for these properties is in Example 1, “RoleToPrivilegeMappings object snippet”.

RoleToPrivilegeMappings object properties

Name Type Description
privileges Associative array of Privilege objects keyed by role name. Role definitions with associated privileges (see Privilege Configuration). Required.

Example 1. RoleToPrivilegeMappings object snippet

name = "my-target-role-mappings"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    RoleToPrivilegeMappings =
    {
        privileges = [
          {
            administrator = [ ... ]
            monitor = [ ...]
        }
      ]
    }
}


Privilege Configuration

The Privilege object defines permissions for a resource. Figure 2, “Privilege relationships” shows the relationships to other configuration objects.

Privilege relationships

Privilege relationships

A detailed description of the configuration object properties is in Privilege object properties and a snippet for these properties is in Example 2, “Privilege object snippet”.

Privilege object properties

Name Type Description
privilege Enumeration. Valid values are ADMIN_RUN_COMMAND. Privilege type. Required.
resource String Resource name specified as <target>.<command>. Required for administration commands, optional for other resources. No default.

Example 2. Privilege object snippet

name = "my-target-role-mappings"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    RoleToPrivilegeMappings = {
	roles = {
	  administrator = {
		privileges = [
		  {
                  resource = "mytarget.start"
                  privilege = "AdminRunCommand"
                },
                {
                   resource = "mytarget.stop"
                   privilege = "AdminRunCommand"
                }
		]
		}
	    monitor = {
		privileges = [
		  {
                  resource = "mytarget.display"
                  privilege = "AdminRunCommand"
                }
		]
	     }
	   }
      }
}