From a high level, the security system consists of an authentication realm, authorization realm, roles, and teams. The authentication realm verifies the identity of the user or system that is trying to log on to IBM UrbanCode Deploy. The authorization realm manages user groups. Roles manage permissions. Teams join users with roles and secure product areas.
A good starting point for learning about the team-based security system is to understand permissions. IBM UrbanCode Deploy uses the term permission in a way familiar to most readers: each permission controls access to a product area or product function. Most permissions refer to typical activities such as create, read, update, and delete. Permissions define what can be done, not who can do it
A product area that can have permissions that are defined for it is referred to as a security type. Each security type has a set of permissions that affect how users interact with it. The component security type has a set of permissions that affect a user's ability to interact with components. The permissions that are available for the agent security type affect agents, and so forth.
Most security types can have more types that are defined for them. Each eligible security type is delivered with a "standard" type that is defined for it, such as "Standard Agent" or "Standard Component." Each additional type within an area shares the same set of permissions. For example, each agent type has the same set of permissions: edit and view. See Security types.
A role is a set of granted permissions. Defining a role consists of granting permissions for all security types that are affected by the role. A developer-type role might have permissions for creating applications but not running them in production environments. Alternatively, a deployer-type role might be able to run applications but not create them. You decide the number of roles and their functions. As delivered, IBM UrbanCode Deploy provides one role, the administrator role, which has all permissions that are granted for all security types.
Importantly, a role by itself does not impart its granted permissions to any actual user. Like permissions, roles define what can be done, not who can do them. Roles and their associated permissions are applied to users by teams.
A team is a construct that associates users or groups with roles. When a user is added to a team, that person is assigned to a role; users cannot be added to a team without a role assignment. Role members are automatically granted all permissions that are defined for the role. Groups can also be added to roles, in which case all group members are automatically granted the permissions that are defined for the role.
When a team is created, all users and groups are available for assignment, and all roles are available to use. Users can be assigned to more than one role. If a user is assigned to one role that grants a particular permission and another role that does not grant that permission, the user is considered to have the permission.
Teams secure resources. To secure an environment, for example, a team is associated with it. After the environment is secured, only team members assigned a role with an appropriate permission can affect the environment.
Clearly, the IBM UrbanCode Deploy security system enables fine-grained customizations. What might not be clear is how all the elements come together. More clarity about permissions is provided.
Permissions are of two types: types with specific scope, and those types with more general scope. The environment security type has four permissions: create, edit, execute, and view. Except for create, these permissions affect only a specific resource; they are scoped to a specific environment. If a team with the execute permission is attached to the Production environment, for example, then only team members with that permission can run applications in the environment. Team members with other roles that do not grant the execute permission cannot run applications there. Members of teams that are not attached to the environment cannot run applications regardless of whether they have the execute permission.
The create permission is different from other permission types. The create type is not scoped to a specific resource but is more broadly scoped. Team members with a create-type permission can create resources of the related type without first being attached to a specific resource. To continue the environment example, users with the create environment permission can create environments even if their team is not attached to a specific environment.
In the following figure, the productionTeam team is attached to the tutorialProdEnvironment environment. The productionRole role has the execute permission for environments. Team members with that role, such as prodDeployer, can run applications in the environment. Team members without that role, such as developerLead, cannot run applications even though the team is attached to the environment.