Enabling access to Klocwork projects

In this topic:
About access control Creating and managing users (Basic access control) Creating and managing groups Setting up roles Default roles Available permissions Plan the roles your organization needs Creating and managing roles Assigning roles What you need to communicate

This article covers:

• user management
• roles management
• permissions management

Prerequisites

• An access control method must be configured. See Setting up access control.
• If you aren't the user with the "Projects root admin" role, the Projects root admin must give you permissions (such as "Manage roles" and "Manage users"). The permissions required for various tasks are noted below.

About access control

As a security feature, Klocwork allows the Klocwork administrator to control who will have access to Klocwork, what level of access, and to what projects.

Your organization chose an access control method for the projects_root from one of three choices: Basic, NIS and LDAP. These choices are described in Setting up access control.

Basic, NIS, or LDAP access control: You can control access to integration projects in Validate. You define roles. A role is a collection of permissions. Until you assign the roles to users or groups to control their level of access, they will not be able to do anything with your Klocwork projects.

NIS or LDAP access control: Users and groups already exist, and they can be changed only through NIS or LDAP administration. You can, however, create and manage additional groups. If you have NIS or LDAP access control, but you wish to set up your own groups as well, see Creating and managing groups.

How the groups you create differ from NIS or LDAP groups:

• you can create and delete custom groups in Validate on the Validate Server, but the NIS or LDAP administrator creates and deletes NIS and LDAP groups on the NIS or LDAP server
• in Validate, you can add or remove NIS or LDAP users to or from custom groups but not to or from NIS or LDAP groups
• custom groups are visible from Klocwork tools only

This means that in Validate it is possible to create a group, add NIS or LDAP users to the group, and assign roles to the created group. Custom groups remain after the Validate Server restarts and they update when LDAP information updates (for example, any users removed from LDAP also disappear from your custom group).

Where do I start?

For NIS or LDAP, you can begin by setting up roles. If you have Basic access control, begin by creating users.

Logging in to Validate for the first time with Basic access control

When Basic access control has been set up, when you log in to Validate, you need to enter the user ID of the user that set up access control, with no password.

Creating and managing users (Basic access control)

Prerequisite: The "Manage users" permission.

If you have Basic access control, you must create users and, if you wish, groups, before you can define roles to apply to them.

To create a user:

1. In Validate, click Users. The Users page appears.
2. Click Create a new account or group. The Add account page appears.
3. Type a user ID for the user, for example, "John Smith" or "jsmith".
4. If desired, enter a password and confirm the password.
5. Click OK.

   The user ID appears in the list of users. By default, the user is given the same role, and are included in the same group, as the 'guest' account.

To delete a user:

1. In Validate, click Users. The Users page appears.
2. Locate the user under Accounts and click the trash can icon to the right.

   The user is permanently deleted from the system.

To change a user's password:

1. In Validate, click Users. The Users page appears.
2. Under Accounts in the left pane, click the user. The user's details appear on the right.
3. On the Info tab, click change password. The password fields appear.
4. Enter a password and confirm the password.
5. Click OK.

Creating and managing groups

Prerequisite: The "Manage users" permission.

With Basic, NIS, or LDAP access control, you can create your own groups, if desired. Groups can simplify administration, by letting you control access for several users at a time and by letting you delegate. Users can belong to more than one group. Users assigned to a group can have the same or different roles. You can assign users to groups or groups to users. When you are organizing many users, assigning users to groups makes more sense. When you are adding or deleting a single user, it might make more sense to start from the user.

Note that if it is more efficient for you to apply a role to a group of users and then remove the role from one user, you have that option. See Assigning roles.

If a user has left your organization or should no longer have access to this Klocwork projects_root, you can remove that user from the Users list so that they no longer have any access. You cannot delete users or groups from NIS or LDAP in Validate. You can delete users or groups that you have created in Validate.

To create a group:

1. In Validate, click Users. The Users page appears.
2. Click Create a new account or group. The Add account page appears.
3. By default, a user account is created. Select group instead.
4. Type a name for your new group and click OK.

   The new group appears in the Accounts list, with its details in the right pane.

To add users to a group:

1. To add users to your group, start typing in the text field. Auto-completion will suggest matches.
2. Click Add. The user appears in the list of group members under Users.

To remove users from a group:

1. In Validate, click Users. The Users page appears.
2. Locate the group under Accounts and select it. The group details appear in the right pane.
3. On the Info tab, under Users, click the trash can icon next to the user you want to remove from the group.

   The user is removed from the group. (This does not delete the user.)

To delete a group:

1. In Validate, click Users. The Users page appears.
2. Locate the group under Accounts and click the trash can icon to the right.

   The group is permanently deleted from the system.

Setting up roles

Prerequisite: The "Manage roles" permission.

A role is a collection of permissions. You can grant a permission to more than one role. Some permissions apply to the whole projects_root (to all projects). Some permissions can apply either to a specific project or to all projects. For example, one user might have permission to analyze only a specific project while another user might have permission to analyze all projects in the projects_root.

Also note that permissions control what a user can access. For example, if a user is invited to a code review but receives a warning that they are unable to view, this indicates that they do not have the proper permissions for that project or file. In this case, they need to be given the proper permissions to access that project or file by the Project root admin.

Default roles

The following table shows the roles that exist by default, and their default permissions.

If you create custom roles, the implied permissions listed below for the Project root admin and Project admin roles are not available.

Role	Default permissions
Projects root admin	All (cannot be edited) Implied permissions for this role: Manage reports (make reports public) Change user passwords for all users (Basic authentication only) Manage application tokens for self Manage application tokens for all users
Project admin	Web API access Perform cross-project synchronization Create stream Change project settings Delete project Delete stream Create build Delete build Create CI build Delete CI build Auto-delete builds Assign role Access source files Manage modules Manage views Use local configuration Change issue status Change Issue owner
Stream admin	Web API access Perform cross-project synchronization Create stream Change project settings Delete stream Create build Delete build Create CI build Delete CI build Auto-delete builds Assign role Access source files Manage views Use local configuration Change issue status Change Issue owner
Build engineer	Change project settings Create build Delete build
Developer	Access source files Use local configuration Change issue status Change Issue owner
Manager	Access source files Change issue status Change Issue owner

When you create a project, you are assigned the role of Project admin by default.

Available permissions

Permissions that apply to the whole projects_root (all projects)

Name of the permission	A user (or group) who has the permission can...
Create project	create projects
Manage roles	create or delete roles; add permissions to roles
Manage users	create and delete users and groups; add users to groups; remove users from groups
Manage tokens for all users	create, delete, or modify user tokens for all users
Manage tokens for self	create, delete, or modify only their own user tokens
Manage user sessions	log users out of their Validate sessions
Manage reports	control which reports are made public for the entire team
Change user passwords	change user passwords for all users (Basic authentication only)
Access the Web API	access the Web API, which provides administrators with a scriptable interface to the Klocwork database
Perform cross-project synchronization	synchronizes issue status updates and comments, along with the ID of the user who made the changes, among projects that you specify

Permissions that can apply either to a specific project or to the whole projects_root (all projects)

Name of the permission	A user (or group) who has the permission can...
Access source files	access project source files. Note: To control access to source code, you must give users the access source files permission and you must set up modules and configure module permissions.
Assign role	assign roles to users or groups on a project
Change issue status	change the status of issues on a project. You can refine this choice. This permission includes an additional parameter--a list of from-to pairs of status names. If you select a pair, you give the user permission to change issue status from one status to the other.
Change issue owner	change the owner of issues on a project
Change project settings	manage configuration files and configure checkers for the integration build analysis
Create build	analyze a project
Create CI build	analyze a project (a continuous integration run)
Create stream	create a stream
Delete stream	delete a stream
Delete build	delete a build (an analysis run)
Delete CI build	delete a CI build (a continuous integration run)
Delete project	delete a project
Manage project modules	create, edit, and delete modules for a project
Manage views	create, edit, and delete views for a project Note: This adds the ability to make a view public which enables you to edit shared views. Only the creator of the view can delete it.
Use local configuration	use local configuration files on the desktop. Changes to local (desktop) configurations are not shared with the server.
Set up auto-delete option	manage 'auto-delete old builds' flag on the Builds page and set an auto-delete threshold. You can also manage the 'Do not auto-delete this build' flag or the 'keepit' flag for the update_build WebAPI command.

How permissions work with streams

When working with streams, permissions are handled as follows:

• Stream permissions are set on a 'per-stream' basis.

• No permissions are inherited from the parent or base-project streams when creating a new stream.

• Users creating new streams are automatically assigned the Stream Admin permission for those streams.

• If a user needs a specific role for a particular stream, and doesn't have it as a global role, this role needs to be assigned to them manually.

Plan the roles your organization needs

Think about who should be able to do what. What roles does your organization need? What permissions should each role have? Do different teams need different kinds of roles? Do you want team leaders to be able to change the roles you set up? Do you want developers to be able to change the status of detected issues?

Every organization is different. In one organization, a user may do all of the tasks that are performed by several users in another organization. In one organization, developers may have complete freedom and responsibility for code quality; in another, there may be hierarchies. The roles you need may depend on how large your organization is and how long you have been using Klocwork.

Creating and managing roles

If you create custom roles, the implied permissions for the Project root admin and Project admin roles are not available.

To create a role:

1. In Validate, click Roles. The Roles page appears.
2. Click Create a new role.
3. In the Name field, enter the name of the role you want to create (for example, Senior Developer). Use whatever names have meaning in your organization.
4. Click OK. The role you have created appears in the roles list with its details displayed on the right.
5. Select the permissions you want each role to have. See 'Available permissions' above for details on each permission.

   To allow the role to change any issue status to any other issue status, select Change issue status and leave the default Any > Any selected.

   To be more precise about how users with this role will be able to change issue statuses, click the drop-down menus, select from/to pairs, and click add as many times as necessary.

   For example, you want the Senior developer role to have some say about when to fix an issue, but not to be able to ignore it or say that it's not a problem. In the left issue status drop-down menu, select Fix. In the right issue status drop-down menu, select Fix in Later Release.

   To delete a from/to pair, select it and click remove.

To edit a role:

Select the role you want to change from the roles list and select or deselect permissions.

To delete a role:

Select the role you want to delete from the roles list and click the trash can icon next to the role. The role is deleted. Any users who were assigned to this role no longer have its permissions.

You cannot delete the roles "Projects_root admin" or "Project admin".

Assigning roles

Prerequisite:

• You need the "Assign roles" permission.
• Projects, users, groups and roles must all exist before you can match them up.

Users added to a group automatically inherit any roles assigned to the group.

There are a few ways to assign roles to users or groups, depending on your own permissions and whether you need to assign a role to just one or two users, or you need to make larger changes.

• For a specific project:

  From the Project details page, you can assign roles for a specific project. In Validate, click Projects and then click a specific project in the Projects list. In the project details on the right, click Permissions.

• For a specific user or group:

  In Validate, click Users. Click a user in the list. On the right, click the Roles tab. On this page, you can assign roles for either specific projects or the entire projects_root.

• From the Roles page:

  In Validate, click Roles. From the Roles page, click a role. On the right, click the Role assignments tab. On this page, you can assign roles for either specific projects or the entire projects_root.

If you remove all roles from a user or group, that user or group no longer has access to the project or projects_root, but the user or group still exists in the database.

What you need to communicate

Access control user IDs and passwords: Tell anyone to whom you have given access what user ID and password to use. In most large organizations, the system administrator in the IT department sets permissions and manages user IDs.

Who can do what: Explain to users what their roles are. Tell them the paths to their projects and/or servers.

Database password, if set: If you have protected the projects_root data with a password, give the password to build engineers and anyone using third-party reporting tools.

Related concepts