The CLM Book - Optimized Component Lifecycle Management with Sonatype CLM
Sonatype CLM not only limits access by login, but it also distinguishes the level of access, what a user can or can’t do, using an intuitive system of roles. Each role has a specific set of permissions. Users are then assigned to these roles, granting users the ability to perform various functions or limiting access to points of data within Sonatype CLM.
Needless to say, the roles and permissions management system inside of Sonatype CLM is powerful. Unfortunately, powerful can sometimes translate to overwhelming. To help ease you into managing Sonatype CLM permissions, this section of the Security Administration Guide will walk you through everything you need to know. This includes:
- Organizations and Applications
- Roles and Permissions
- Assigning Users to Roles
Whether or not you will ever interact with elements of Sonatype CLM outside of Security Administration, you will still need to understand the impact Organizations and Applications have on how roles are managed. Mainly granting at the application level is exclusive to that application, while granting at the organization level allows access to view and make changes across any assigned applications as well as the organization itself. This is due to a concept called inheritance, and it can be used to vastly reduce the need to add every user to each application.
While, we do cover this in our other guides, we should start by taking a basic look at these two areas. The image below gives an example of how we can reduce repetition of users by choosing to manage by organization.
- Applications
-
Applications are created in Sonatype CLM. They allow users to identify a specific project, and then track the health of components in that project. Each application must have a specific name, a unique identifier (Application ID), and an organization. Each application may also have policies (rules) and other associated policy elements (e.g. license threat groups and labels). Finally, an application will inherit policies and policy elements from its selected organization.
The important piece to see here is that applications are very singular. Changes made here will have an impact, but will be isolated to the particular application. This is very different compared to organizations.
- Organizations
-
Similar to applications, an organization will have a specific name, but it does not need a specified identifier. Organizations may also have policies (rules) and a number of associated policy elements (e.g. license threat groups and labels). However, unlike applications, organizations aren’t tied to a specific project / application. Instead, they function more like a container to hold multiple applications. Given this, in cases where an organization has policies or policy elements, any application that has selected this organization, will inherit all those policies and policy elements.
Again, the important piece to pay attention to here is that users assigned to an organization have the potential to view and/or interact with not just the organization, but also any application attached to that organization.
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:
- Mapping a user to a role for an application grants access to only that application.
- Mapping 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 mapping 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.
![[Note]](images/icons/note.png){kind=icon}
|
|
|
In the image above, inherited users (or groups) are indicated by the arrow pointing up, located to the left of the corresponding name. |
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]](images/icons/tip.png)
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.
|
|
|
|
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. |
Mapping a user (or group if you have configured LDAP) to a role simply means finding a user, and assigning them to the desired role. Doing so grants the user the level of permissions for the role. These permissions were described above, with possible scenarios for using each one. Below, we’ve described the typical process for mapping a user to a role.
-
From the security tab of an application or organization, click the Edit icon (it resembles a pencil).
Remember mapping a user to a role at the organization level will grant that user the same role and permissions to any associated applications.
-
A search widget will be displayed. In the search field, enter the user’s name exactly as it is entered in your LDAP server. For example if you are looking for Isaac Asimov, you would enter that complete name. In cases where you don’t know a user’s complete name, leading or trailing wildcards (*) can be added. Using the example above, if I only knew the first name of the user, I could simply enter Isaac A*.
![[Warning]](images/icons/warning.png)
Use of leading wildcards can greatly impact user search times.
Wildcards are only applicable for users of Sonatype CLM including, and beyond, version Sonatype CLM 1.11.1. All prior versions of Sonatype CLM do not support wildcard usage when mapping users to roles, as this is automatically appended/prepended to the search text (i.e. searching for smith is equivalent to *smith* in 1.11.1 and later).
You may notice that below each user, there is additional information. Most often this is the email. However, to the right of the email you will see the Realm (e.g. CLM). Use this to ensure you add the appropriate account (e.g. when working with CLM the local realm, and LDAP).
-
Once you see the user you wish to add in the Available column, click the Plus icon to move them to the Applied column. Click the Save button to save your changes.
To remove users from a role, follow the same process above, just click the Minus icon to move the user from the Applied column to the Available column.
|
|
|
|
Global roles are managed via system preferences
|
- Special Instructions When Groups Are Excluded From Search Results
-
Mapping a group to a role utilizes elements that are configured via the LDAP System Preferences area. If you go with the default options, groups will be included with the search results. That is, when you enter something into the Find User field, both groups and single users will be returned.
However, because the size of LDAP implementation can vary, you may want to consider not including groups with your search results. This option can be adjusted when using Dynamic Groups settings.
Making this change will then allow you to manually enter group names. However, when entering groups this way, no search or validation will be performed.
