Access Management for Teams
Authors: Andrea Baader, Georg Sander
Introduction
UMS Teams is a service provided by IBM Cloud Pak for Automation that provides the functionality to create and use nested teams of users for all components of the IBM Cloud Pak. The teams are global in the sense that a team defined by one component can also be used by all other components. Teams can be used for many purposes, and the most common purpose are authorization decisions: who can perform an action on a resource? You can define a team for this purpose.
The UMS Teams service is no LDAP, but rather an intermediate facility between LDAP and IBM Cloud Pak components. Customers often do not want to modify their LDAP groups for temporary needs of global teams, in particular when they are using a company wide LDAP server. The UMS Teams service allows to model dedicated, shorter living teams for specific business needs of the IBM Cloud Pak, while LDAP groups are usually long-living. Also Ums Teams service teams can be administered and edited independent of a LDAP administrator.
Why Access Management for Teams?
Access Management for Teams deals with the topic who is allowed to create, read, edit and delete such a team. If we compare with a company wide LDAP, there is usually an LDAP administrator who can edit the LDAP groups. However, UMS Teams has a more fine grained access management model. If we have only one global administrator, then everyone who needs to be able to create or edit teams wants to be part of the global administrator role. This leads to security conflicts if one person edits a team that another person has created. The access management model of UMS Teams allows to avoid such security conflicts as it enables you to specify who can do what with each team, for instance who is allowed to see a specific team, and who can add members to the team. This allows a team owner also to hide own teams from other users of the UMS Teams service.
What is it?
Different Personas
The Access Management in the UMS Teams server gives a more fine grant access policy to teams. You can specify users that have overall administrative rights or only specific rights on a dedicated team. To achieve that there are three predefined teams in the UMS Teams service and also access management specification per team. With this concept persons like overall UMS Teams service Administrator, Creator of teams but also dedicated team Administrators or Managers or simple team Members are represented.
Access Management per team
Teams in the UMS Teams service organize the Access Management via teams and specific users. Each team has an Creator and must have an Owner. In addition an Administrator Team, a Writer Team and a Reader Team can be specified to give more fine grained access rights to users.
The Creator is the users that created the team. The Creator itself does not have access rights to the team, but if nothing is specified at creation the Creator also becomes the Owner of the team.
The Owner has all rights in the team, he can read and write all aspects of the team. Basic data (team display and distinguished name), set membership of the team like users, groups or other teams and can also edit the Access Management for the team.
Members of the Administrator Team of a team have the same access rights as the Owner. Therefore they can change all aspects of the team.
Members of the Writer Team of a team are allowed to edit basic team information and modify the team membership data. They can add and remove users, groups and teams as members of the specific team. They can not read or change the Access Management for the team. Thus these users can manage the day to day demands of changing team membership without contacting an UMS Teams service administrator.
Members of the Reader Team can only see the basic team information and the team members, but are not allowed to edit the data. Therefore these users have the knowledge of the team existence and its specification, they can give feedback if specification are not correct.
Members of a team can not see any information about the specific team just because they are members of the team. This might seem very strict but even the team name or description or who else is member of the team might be something I'm not allowed to see, e.g. if the team includes people of the same salary grade, or people who should be fired.
Predefined teams
Besides the Access Management specified for each team there are three predefined team that grant certain rights in the UMS Teams service.
The predefined Administrator Team (dn: cn=admins,ou=teams,dc=internal) allows to specify multiple users to be allowed to administer UMS Teams service. Members of this team are allowed to read and write all aspects of all teams in the UMS Teams service and they can create new teams. Therefore choose wisely whom to add to the predefined Administrator Team.
Members of the Creator Team (dn: cn=creators,ou=teams,dc=internal) are allowed to create new teams. So these team members do not have any overall administrative rights in the UMS Teams service. They do only have access to the teams they created and only if they specified the respective access rights for these teams. Therefore grant these users the right to create teams who need that in there day to day work. Thus they do not need to contact the UMS Teams service administrators for this task.
Members of the Repository Readers Team (dn: cn=repository-readers,ou=teams,dc=internal) can access users and groups independent of a team from the user repository like LDAP via the UMS Teams service. Users with at least writer rights to a team can access users and groups of the user repository related to the specific team in order to change team membership. The three predefined can not be deleted from the UMS Teams service.
How to use it?
In environments where there are many teams or many people having only limited access rights it might be helpful to follow certain usage patterns.
Organize teams for multiple departments
Teams are identified by an uuid and a distinguished name. These identifiers need to be unique over the whole UMS Teams service.
Where the uuid is generated the team distinguished name is specified by the creator. In a large organization it might be helpful to establish certain rules on how to set a team distinguished name to help creators and team administrators to keep the name unique.
Therefore the LDAP distinguished names concept could be employed to provide a naming schema. The LDAP distinguished names are structured hierarchically.
For example start with a domain component dc, followed by a organization unit ou. To differentiate the operational area like the application or case the team is used in specify oa or any other abbreviation that suites you. At the end the common name cn is specific to the team purpose. Thus a team that is used in an approval scenario for sales contracts could be identified by such an team distinguished name: dc=ibm,ou=sales,oa=contract,cn=approvers .
You can organize the hierarchy with more or less levels and denomination depending on your needs.
For ease of use the naming schema you prefer for your organizations UMS Teams service teams you could document in the description area of your predefined Creator team. How to accomplish read access for the respective users follows in the next paragraph.
Authors of teams
Members of the predefined Administrator and the Creator team can create teams. With the Creator team one can give users the right to create teams without giving them any other overall administrative rights on the UMS Teams service.
Now if you have only a few users which should be should allowed to create teams you can add them directly to the Creator team. Otherwise you can use teams added to the Creator team to organize the creators. These member teams of the Creator team could even be managed by the different departments depending on the Access Management specified.
Self Organized teams
If you want a team to be managed or at least be readable by the team members, you can specify the team itself as its Reader or Writer Team or even Administrator Team.
Thus it is allowed to use a team in its own Access Management specification. Therefore you can give team members as much access rights as it suites the specific purpose of the team.