Sonatype CLM Server - Security Administration Guide

4.2. Roles and Permissions

If you skipped to here, we understand, you are in a hurry to get Sonatype CLM working in your business. However, in bypassing our basic organization and application overview, we will assume you are familiar with those concepts. If you haven’t, go take a look again. Even if you don’t plan on using CLM beyond a role of installation, deployment, and/or security administration, the previous section can help prevent unwanted access and reduce unnecessary repetition.

If you are still dissuaded, here is the abbreviated version:

Adding a user to a role for an application grants access to only that application.
Adding a user to a role for an organization grants access to the organization AND all attached applications due to a principle called inheritance.

OK, so we know to be careful when adding a user to a role for an organization or application, but what is a role exactly?

Great question, a role is a set of permissions that have been predefined by Sonatype. These permissions are based on the concept of being able to either view data or manipulate. And by manipulate, we mean the ability to create, edit or delete. In Sonatype CLM, two standard roles are included:

Owner - allows a user to view, create, edit and delete.
Developer - allows only the ability to view.

figs/web/role-management-roles-example.png

Figure 4.2. Example of Roles

In both cases, the second most important aspect of roles is where the role is assigned, either at the organization, or the application. To understand this a little better, let’s look at a few examples.

Using the Developer Role

First, I have a member of the development team for my application, Awesome App. I only want this team member to be able to view aspects of Awesome App, such as the report displaying policy violations, or see the policy itself. This team member shouldn’t be able to edit, and again I only want them to see information for Awesome App. In this example, I would assign my user to the developer role for Awesome App.

Using the Owner Role

Alright, now lets look at a slightly different example. A member of your security team, responsible for ensuring components in applications meet your business’s specific standards, needs access to review policy and violation results for all applications. He/She is also responsible for managing policies, meaning he/she will need to make changes. However, they are only responsible for Awesome App, so the access this individual needs is Owner access, and like before, this would be at the application level. Specifically, I would make them an owner for Awesome App.

Inheriting a Role

Well, it seems easy enough to assign a role to an individual, but what happens if you need to add someone to all the applications under an organization, say like the Director of Development? OK, one more example then.

The Director of Development, who is also responsible for managing policies and setting up new applications, needs access to Sonatype CLM. The director will need to have full access to create, view, edit and delete multiple application. Now, we could go in and make the Director an owner of each application. However, just like policies and policy elements (what we discussed previously), applications also inherit role members based on their organization. So, all we need to do for our direction, is assign them as an owner for a specific organization, or perhaps even multiple organizations, if you have set CLM up that way.

Tip

You can use inheritance when assigning developers as well. Just like the example above, if you want a user to be in the Developer Role for all applications in an organization, simply add the individual to the Developer Role at the organization level.

Obviously, there are lots of examples we could run through. However, just remember that the level of the Role you are assigning a user to is as important as the role itself. Now that you know, let’s go assign some users to roles.

Note

We specifically left out one role, Administrator, which is identical to the default admin account that ships with Sonatype CLM. It is considered a Global Role, and if you are looking to grant a user access to full rights in Sonatype CLM, this is the role you would use. It is important to note, that limited use of this role is suggested, and modification must be made by an existing member of the Administrator role.