Table of Contents	Introduction
	CEE Users and Roles
	Organizing Multiple Projects
	User Groups and Project Groups
	Public Projects
	Project Categories
	Conclusion
	Appendix A: Standard CEE Roles

User Groups and Project Groups

In the previous section we discussed two general ways to organize users into multiple projects and control access to those projects:

• For situations where the projects are part of a larger initiative and most of the users may need access to all the projects, you can create the projects as subprojects under a top-level parent project, and add the core group of users as members to the top-level project. The users can then access the subprojects using roles inherited from the parent project. In this scenario you may also have some users who should have access to only one or a few of the subprojects; they can be treated as exceptions, and explicitly granted roles in one or more of the subprojects as needed.
• For situations where the projects are independent and each has its own separate user base, you can create the projects as separate top-level projects, and add each person’s user-id to the particular project in which they will be participating. In this scenario you may also have some users who should have access to multiple projects; they can be treated as exceptions, and added to multiple projects as needed.

However when creating real CEE configurations you often need to create more complicated schemes for access control. In this section we discuss two CEE features allowing more extensive customization of access control: user groups and project groups.

User Groups

Previously in our examples we have granted access to projects on a user-by-user basis; in other words, to give to a person access to a project we either explicitly granted the person’s user-id a role in the project itself, or (in the case of subprojects) explicitly granted their user-id a role in the project’s parent project, with that role then being inherited in the (sub) project.

If your CEE system has a large number of users then granting access user by user can be time-consuming at times, especially if the users must have access to multiple independent top-level projects, where the projects have no parent project from which roles can be inherited. To help address this problem CEE allows you to create user groups consisting of multiple user-ids, and then to grant access by user group instead of by user-id.

User groups are useful when there are a number of users who need to participate in multiple projects, and the users can be classified into more than one distinct group, with each group needing a particular level of access. For example, suppose that we have a central 10-person “security team” consisting of developers who develop security-related code for several projects and who are responsible for responding to reports of security-related vulnerabilities in each project’s software.

We could add each of the ten people individually to each of the projects they are to work in, as described above, but this would require a lot of CEE administrative operations. In addition, we might want to distinguish the security team members in some way from the normal project developers.

We can address both these issues by creating a CEE user group containing a set of user-ids that can be treated as a unit when it comes to granting roles. In our example we could create a user group “SecurityTeam” consisting of the ten user-ids for the people on the security team. We could then add the SecurityTeam user group to each of the several projects in which the team is to participate, assigning to the SecurityTeam user group the Developer role in each project (or some other appropriate role).

You can do this in CEE as follows:

• Create CEE user-ids for all the people in the security team group, as previously described.
• Create a new CEE user group; specify the name of the new user group as “SecurityTeam”, and add a brief description of the group.
• Add the user-ids to the user group

• For each of the projects in which the security team is to have access, add the user group (not the individual user-ids) to the project, and grant to the user group the Developer role.

If the user group SecurityTeam has been granted the Developer role in a given project, then all of the user-ids that are part of that user group have the Developer role within that project, and can perform any action associated with that role.

Note that when a user has a role in a project solely by virtue of being in a user group granted that role, that role is considered to be a derived role as discussed above, not a direct role. Thus within that project the CEE interface will appear differently to the user than it does when the user’s role is directly granted within the project itself, as discussed earlier. So, for example, suppose a given person’s user-id is in the SecurityTeam user group, that the SecurityTeam user group has been granted the Developer role within a given project, and that the person’s user-id itself has not been granted any direct role in that project. In that case the CEE interface will appear as follows to the user:

• The project in question will not be listed on the user’s “My start page” if the project is private. However the user can access the project by going to the “Projects” page, by directly entering in the project’s URL into the browser’s location field, or by other means discussed below.
• The project’s home page displayed to the user will have a “Join this Project” link, even though the member already has a role in the project as a result of being in a user group granted a role in the project. However the user can simply ignore the “Join this Project” link and proceed to access project resources, as they would normally do.
• The project’s home page will not display the derived role that the user has in the project. However the user can determine their role in the project using the “Show derived roles” function of CEE, as described earlier.

As we discussed in connection with inheriting a role in a subproject, a user might have a derived role in a project and also have a direct role as well.

Returning to our example above, consider a member of the security team who has the (derived) Developer role in a given project as a result of that person’s membership in the SecurityTeam user group. Suppose that this person is then also placed in charge of the project activities, and is granted the Project Owner role in the project; this person then will have a direct role in the project (Project Owner) and also a derived role (Developer).

As we discussed previously, when a person has both a direct role and a derived role in a project, the user’s permissions in the project are the union of the permissions from the two roles; in other words, in our example the user can do anything allowed by the Developer role, as well as anything allowed by the Project Owner role. (As it happens, the permissions associated with the Project Owner role are a superset of those for the Developer role. However this may not be true in general when a user has two different roles; in fact, the two roles might grant completely different sets of permissions.)

Multiple User Groups

Although in our example thus far we have mentioned only a single user group, in fact a given user can belong to multiple user groups. For example, suppose that we have a separate group of Quality Assurance managers who oversee QA-related activities for multiple CEE projects associated with several development teams. We could create a user group QAManagers containing the user-ids of all the QA managers, and then add the QAManagers user group as a member to all the projects overseen by the QA managers, granting the user group the Observer role in those projects.

It may be that a given QA manager is also a member of the security team; in that case the QA manager would be a member of both the SecurityTeam user group and the QAManagers user group. It might happen that in a given project the SecurityTeam user group is granted the Developer role and the QAManagers user group is granted the Observer role. In this case our example QA manager would have two derived roles in the project: the Developer role (as a consequence of being a member of the SecurityTeam user group) and the Observer role (as a consequence of being a member of the QAManagers user group). As previously discussed, the QA manager’s permissions in the project would be the union of the permissions from the two roles.

In general there can be many user groups defined in a CEE system, and any user could be a member of multiple user groups. However note that user groups cannot contain other user groups as members, but only users (i.e., user-ids). Thus in our example suppose that we had a third user group, Managers, consisting of all managers, including development managers, QA managers, etc. Because of the restriction that user groups can have only users as members, we must first add all the QA managers’ user-ids to the QAManagers user group, and then separately add those same user-ids to the Managers user group; we cannot simply add the QAManagers user group as a member of the Managers user group.

Project Groups

We previously discussed organizing projects as subprojects under a parent project, with users granted roles in the parent project then inheriting those roles in the subprojects. Although a parent project may have multiple subprojects, a given project can have only one parent project. While this arrangement works well for many situations, some real-life situations are too complex to model using a standard parent project-subproject scheme.

In the previous section we discussed an example where we created two user groups: a SecurityTeam group and a QAManagers group, each containing a specific group of users (i.e., user-ids). In the example we explicitly granted to the SecurityTeam user group the Developer role in each and every project in which the security team members were to participate, and explicitly granted to the QAManagers user group the Observer role in each and every project to be overseen by QA managers.

It would be nice if we could avoid having to add the user groups explicitly to each and every project in which their members are to participate, in order to reduce the amount of CEE administrative work that needs to be performed. So, for example, we could take all the projects in which the security team is to participate, and make those subprojects of a parent project; we could then explicitly grant to the SecurityTeam user group the Developer role in the parent project. The security team members would then have the (derived) Developer role in the parent project (because their user-ids are in the SecurityTeam user group), and they would inherit the Developer role in all of the subprojects of the parent project. (In general any role which a user has in a project, no matter how obtained, will be inherited as a derived role in a subproject of that project.¹)

Similarly, we could take all the projects that the QA managers are to oversee, and make those subprojects of a parent project; we could then explicitly grant to the QAManagers user group the Observer role in the parent project. The QA managers would then have the (derived) Observer role in the parent project, and would inherit that role in the subprojects.

Ideally we’d like to combine these two schemes. For example, we could have a single parent project in which we’d grant the Developer role to the SecurityTeam user group and grant the Observer role to the QAManagers user group. However this assumes that all the subprojects have both the security team and the QA managers participating in them, since both the security team members and the QA managers will have derived roles (of Developer and Observer respectively) in all the subprojects.

On the other hand, we could have two separate parent projects: In one parent project we would grant the Developer role to the SecurityTeam user group, and in the other parent project we would grant the Observer role to the QAManagers user group. However this assumes that no project has both the security team and the QA managers participating it, since a project can have only one parent project: If we create the project as a subproject of the parent project in which the SecurityTeam user group has been granted the Developer role, we cannot also create the project as a subproject of the (separate) parent project in which the QAManagers user group has been granted the Observer role.

Thus we have a problem: What if some projects have only the security team participating in them, while other projects have only the QA managers participating in them, and some projects have participation by both the security team and the QA managers? How can we configure the CEE system to address this situation?

The project group feature of CEE provides an answer to our problem. Project groups are a generalization of the parent project/subproject feature we’ve already discussed: Like a parent project, a project group is a project that can contain other projects as members. As with a parent project and its subprojects, any direct or derived role that a user has in a project group is inherited in the projects that are members of the project group. However there is an important difference between project groups and parent projects: A given project may have only one parent project, but it can be a member of multiple project groups.

We can use the project group feature in our example as follows: We create one project group (call it “SecurityTeamProjects”) containing all the projects in which the security team is to participate, and in that project group we grant to the SecurityTeam user group the Developer role. We create a second project group (call it “QAManagerProjects”) containing all the projects that the QA managers are to oversee, and in that project group we grant to the QAManagers user group the Observer role. Any given project may be a member of the SecurityTeamProjects project group, a member of the QAManagerProjects project group, or a member of both project groups. If a project is a member of both project groups then members of the security team will have the (derived) role of Developer in that project, while QA managers will have the (derived) role of Observer in the project.

In CEE you can do this as follows:

• Create the SecurityTeamProjects project group as a new top-level project group. In the “Initial projects” field specify the names of the projects that are to be members of the SecurityTeamProjects project group, and then invoke the “Create group” operation.
• Add the SecurityTeam user group to the just-created project group and grant to it the Developer role.
• Repeat the steps above to create the QAManagerProjects project group, specifying all the projects that are to be members of that project group, and then add the QAManagers user group to the project group, granting to it the Observer role.

Note that a given project may be a subproject of a parent project, and also at the same time be a member of one or more project groups. You can create a parent project to organize multiple subprojects with similar access control requirements, and then use project groups in addition to take care of special cases where some groups of people need access to some (but not all) of the subprojects.

Previously in this document we discussed the example of a company that had a group of twenty people working together with representatives of ten partner companies. In the example we assumed that each of the ten partner companies worked on one and only one project, a project different than those in which other partner companies participated; we created each of the ten projects as subprojects of a top-level parent project, and we granted to each of the representatives of the partner companies a role in the particular subproject associated with their company.

 However suppose that each partner company might actually participate in several projects with the original company, and that in some cases two or more partner companies might work with the original company on a single project. How can we create an appropriate access control scheme in CEE?

We can start with the scheme discussed in the previous example: We create a top-level parent project, and grant roles in that parent project to the twenty people in the original company. (We could also create two user groups for the twenty people in the original company, one user group for the five people with observer status and a second user group for the fifteen developers; however this is not necessary for the purposes of this example.) We then create all the partner projects as subprojects of the initial parent project. In this example we might have dozens or even hundreds of such projects in total. As in the previous example, the twenty people in the original company will have (derived) roles in all the subprojects, either the Observer role or the Developer role depending on which role they were granted in the parent project.

As mentioned above, each partner company might participate in several projects, and several partners might participate in a single project. We therefore create a project group for each project; for this example we’ll refer to these project groups as “partner1-projects”, “partner2-projects”, and so on, through “partner10-projects”. (Recall that there are ten partner companies in the example.)

We then add all of the first partner’s representatives as members in the partner1-projects project group, granting to them the Observer role. If we’d like we can create a user group Partner1Employees consisting of the user-ids for all the representatives of the first partner, and grant the user group Partner1Employees the Observer role in the partner1-projects project group. However this is not strictly speaking necessary: We could instead just add to the partner1-projects project group all the individual user-ids for the representatives of the first partner.

We repeat this process for the second partner, adding all of that partner’s representatives as members of the partner2-project group and granting to them the Observer role in that project group. (Again, we could create a user group for the second partner’s employees, or just add individual user-ids to the project group.) We repeat this process for the third partner, and continue until we have added all of the partner representatives to one of the ten partner project groups.

We then consider each individual project in which partners are to participate (i.e., the subprojects of the parent project created earlier). If a particular partner is to participate in a project, we add that project to the project group associated with that partner. For example, if the first partner is to participate in a project “abc” then we add “abc” to the “partner1-projects” project group. All the representatives of the first partner will then have a derived role of Observer in the project “abc”, a role inherited from the role they were granted in the “partner1-projects” project group.

If two or more partners are to participate in a given project then we make that project a member of multiple project groups. So, for example, if both the second partner and the fifth partner are to participate in a project “xyz” then we add “xyz” to the “partner2-projects” project group, and then also add “xyz” to the “partner5-projects” project group. (Recall that projects can belong to multiple project groups, although they can have only one parent project.) The representatives of the second partner will then have a derived role of Observer in the project “xyz”, a role inherited from the role they were granted in the “partner2-projects” project group; the representatives of the fifth partner will also have a derived role of Observer in the project “xyz”, a role inherited from the “partner5-projects” project group

---

---