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 trying to log on to IBM UrbanCode Release. 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 Release 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 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 release security type, as the name implies, has a set of permissions that affect a user's ability to interact with releases. 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 that enable it to create releases but not configure security for other roles. The number of roles that you create and their functions are up to you. As shipped, IBM UrbanCode Release provides several roles, such as Admin, that you can modify as you see fit.
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 a release, for example, a team is associated with it. After being secured, only team members assigned a role with an appropriate permission can affect the release.
When a release is created, a team must be assigned to it. Once a release is created, only team members can affect the release, and then only in ways that are granted by their permissions. For example, a team member without a role that grants the edit segments permission cannot modify or change the release's segments.
The edit releases permission has an important characteristic. Because a team cannot be assigned to a release until the release is created, users with this permission can create releases as well as modify any release to which their team is assigned. The ability to create items as well as modify them is true for all edit-type permissions, not just the edit release permission. A user with the edit segments permission, for example, can create segments as well as modify existing segments.