Permissions

TIBCO Enterprise Administrator permits access to objects and operations based on permissions, privileges, roles and requirements.

Key terms

User
Users are entities that need access to the system. Each user might need a different level of access. Users can be assigned to one or more roles. TIBCO Enterprise Administrator does not manage users; instead, it maps user information from external systems (such as an LDAP).
Group
A group is a subset of users within an organization. A user can belong to multiple groups and a group can contain multiple users. Groups simplify the administration of access. Instead of specifying the access permissions for each user, administrators specify access permissions for the groups to which users belong.
Realm
A security realm comprises mechanisms for protecting TIBCO Enterprise Administrator resources. A realm contains users and groups, and their security credentials. TIBCO Enterprise Administrator supports two kinds of realms: an internal database within the server (which is the factory default) and an LDAP. In an internal database realm, information about users and groups is stored in a file. In an LDAP realm, the information exists on an LDAP server, and the TIBCO Enterprise Administrator server requests that information from the LDAP server.
Permission
A permission is a string that TIBCO Enterprise Administrator uses to enforce access control. The agent determines the granularity of the permissions that it defines. For example, you could define a permission UpdateConfig which applies to only one operation. In contrast, the built-in permission full_control applies to all agents.
Privilege
A privilege is a collection of permissions. Define privileges to simplify the administrator's task of assigning permissions to users and groups.
Role
A role is a collection of privileges. Administrators assign roles to users or groups. A user receives all the permissions in all the privileges in all its roles.

Defining Permissions and Requirements

You can define permissions with the @TeaPermission and @TeaPermissions annotations.

For example:

@TeaObjectType(name = TomcatAgentUtil.TOMCAT, concept = TeaConcept.TOP_LEVEL, 
         description = "Tomcat TIBCO Enterprise Administrator SDK Agent")
        @TeaPermissions({
        @TeaPermission(name = TomcatAgent.LIFECYCLE_PERMISSION, 
         desc = "Permission to create/start/stop server, webapp"),
        @TeaPermission(name = TomcatAgent.UPDATE_PERMISSION, 
         desc = "Permission to update configurations of server, webapp") })

        public class TomcatAgent {
        ...
        }

Use the @TeaRequires annotation to specify the permissions that a user needs to execute each operation. If an operation method does not require any permissions, then any user can invoke that operation.

Effective Permissions

The server uses this algorithm to compute the set of privileges that apply to a user:

  1. Gather all the roles assigned to the user.
  2. Gather all the roles assigned to groups to which the user belongs.
  3. Gather all the privileges from all those roles.
  4. Gather all the permissions from all those privileges.

Built-In Permissions

These permissions are built into the server, and are always available:
TeaPermission.READ
Read-only permission.
TeaPermission.FULL_CONTROL
Full access to all objects and all operations.