Users and Roles

CodeScene lets you create users and grant them various levels of access depending on their roles.

First Time Access

When accessing CodeScene for the first time, you will be prompted to create an account by entering an email and creating a password. This email-password combination will serve as your login credentials for all future logins. The account with those credentials will have full administrative privileges and is connected to the license key. You will receive an email with your license key and user name. In case you forget your login credentials, you can use the user name-license key combination to log into your account

In case of a manual license activation, you will need to create an admin account inside the “Authentication & User Management” configuration.

Assigning Roles

The system comes preconfigured with a number of roles. You can assign roles to the users in your system to grant them specific access.

Admin

Full configuration access, including user management, global configuration, and deletion of projects.

Technical

Technical and architectural analyses only. No social analyses.

Developer

Technical, architectural and social analyses ; run delta analysis

Test Leader

Technical, architectural and social analyses; plan goals; run delta analysis

Technical Lead

Technical, architectural and social analyses; plan goals; run analysis

Architect

Technical, architectural and social analyses; plan goals; run analysis; project configuration; create new projects; delete projects

Manager

Full access and configuration privileges; create new projects; delete projects

Full Read-only Access

All analysis results, but cannot perform any actions such as running analyses, changing configs, or planning goals.

Bot

This role is intended for third-party integrations like code review or continuous integration bots. This role is allowed to trigger a delta analysis and access the overview of the result.

Roles can be assigned to users on the global level separately for internal and SSO users. Doing so will mean that the users you give access to will have at least that level of access across all configured projetcs.

You can also assign roles at the group or project level to give users a specific access in a smaller scope. Note that role permissions are always additive and any access given at the global level can not be restricted at group or project level.

Permissions by Role

This is a more detailed description of various permissions associated with the CodeScene roles.

Role

Permissions

Technical

  • Technical analyses - warnings, hotspots, temporal coupling, code churn trends

  • CLI tool analyses - access to restricted commands in the CodeScene CLI

Developer

Same as Technical plus:

  • Analysis process branches (branch statistics in Project Management -> Console)

  • Social analyses - networks, knowledge map, parallel development, code churn by author, warnings, modus operandi

  • Architectural analyses - hotspots, temporal coupling

Architect

Same as Developer plus:

  • Project configuration including Access Management and authorised to Delete projects

  • Run a project analysis

  • Project management - Costs and Risks in Project Management

  • Analysis monitor (Project config -> History -> Monitor)

  • Off-boarding simulation

Test Leader

  • Analysis overview

  • Technical analyses - hotspots

  • Social analyses - knowledge map

Manager

  • Analysis overview

  • Analysis process branches

  • Technical analyses - hotspots

  • Social analyses - networks, knowledge map, parallel development, code churn by author, warnings, modus operandi

  • Project management - Costs and Risks

  • Analysis monitor

  • Off-boarding simulation

  • Project configuration including Access Management and authorised to Delete projects

Full Read-only Access

  • Analysis overview

  • Analysis process branches

  • Technical analyses (same as Technical)

  • Social analyses (same as Developer)

  • Architectural analyses (same as Developer)

  • Project management (same as Architect)

  • Analysis monitor

Bot

  • Analysis overview

  • Run a project analysis (used for delta analysis)

Personal Access Tokens

Users can create Personal Access Tokens, which are tokens that allow access to APIs with that user’s permission. These are also used by VSCode plugin and CLI tools. Administrators can also list and delete other users’ tokens.

The button Personal Access Tokens, can be found under Users/Authentication tab, section Internal User Management.

It is important that you check and delete user’s tokens when offboarding a user, to prevent further access.

Adding Internal Users

By default, CodeScene operates with an internal user database. Adding internal users requires Admin privileges.

By clicking on Configuration and the Authentication tab in the top navigation bar, you can access the Users configuration page. As an administrator, you should see the Users configuration, as in Fig. 249.

Adding new users

Fig. 249 In the global configuration you can add new users to the system.

Enter the user name and password, and click “Add User” to finish. The password can be changed later if needed, either by the administrator or by the users themselves.

Password Policy

CodeScene by default enforces a minimum length of 8 characters for the password.

Password Policy

Fig. 250 In the global configuration password policy section you can modify that.

Your CodeScene administrators can modify that to comply with your organization’s password policy.

It is recommended using Single Sign-On as outlined below.

Role Settings

In the table of existing users you can see the currently assigned roles. Click on the Role select box, as shown in Fig. 251, to change the assigned role of a user.

Changing the assigned roles

Fig. 251 By clicking the Role select box you can change the assigned role of a user.

Single Sign-On

As an alternative to the internal user database, you can configure another authentication provider, such as LDAP/Active Directory or OAuth2/OpenID Connect, to perform identity verification for your users, thus avoiding the duplication of your users’ accounts in CodeScene. Users can then log in using the same credentials that they use for other services within your system. When using OAuth2/OpenID Connect, the users are redirected to the configured provider to authorize CodeScene at first login.

LDAP Authentication Provider

A generic LDAP server or Active Directory can be used for user authentication.

LDAP authentication is turned off by default and the configuration fields are hidden as shown in Fig. 252.

Inactive LDAP authentication

Fig. 252 Inactive LDAP authentication

Activate LDAP Authentication by clicking on the “Use LDAP Authentication” checkbox and fill in the details as shown in Fig. 253.

Active LDAP authentication

Fig. 253 Active LDAP authentication

You will need to configure the “LDAP host” address and the “LDAP search base” settings. CodeScene provides default values for the remaining settings, e.g. port and connection timeouts.

The “LDAP search base” is used as a root for LDAP queries searching for data about users and their groups. Make sure to specify a proper base for the search to not miss any relevant user data. See Components of an LDAP Search: for more details.

The “LDAP Bind DN format” is used to create a proper full login name accepted by your LDAP server. It’s usually a full “Distinguished Name”, although Active Directory supports various formats like the “User Principal Name” (e.g. username@mycompany.com) or sAMAccountName. You will use {username} placeholder to configure the username expansion - see the examples on the Configuration page. You can leave this field empty if your users always enter the full login name manually.

We also encourage you to use the “Secure LDAP” connection by checking the “Use Secure LDAP connection” checkbox. In this case, you will need to change the LDAP port too; secure LDAP connections often use port 636.

LDAP Roles Settings

Like normal CodeScene users, users authenticated with the LDAP authentication provider also need to have a “role” assigned to them. This is done with the “LDAP Roles Settings” as shown in Fig. 254.

LDAP Roles Settings

Fig. 254 LDAP Roles Settings

When user data is fetched from an LDAP server, the user’s “identifiers” and his LDAP groups are matched to CodeScene roles based on the “LDAP Roles Settings” configuration:

  • To identify a user, you can use his username, sAMAccountName (Active Directory only), bind DN, or full DN.

  • To identify a group, you can use full DN or Common Name - note that using Common Name isn’t recommended and is provided only for backward compatibility reasons (the Common Name attribute isn’t guaranteed to be unique and it isn’t possible to use it in Project Access Management).

In the example configuration, you can see that the user juraj.martinka has the role Developer and all members of the LDAP group CN=CodeScene Managers,OU=CodeScene,DC=mycompany,DC=local are Manager-s.

Nested groups are supported; that is if the LDAP user is a member of the group “Managers” which is a member of the group “CodeScene Managers” then that LDAP user will have the CodeScene’s Manager role too.

If no matching CodeScene role is found for the LDAP user, the value of “Default CodeScene role” is used. By default, this is set to Full Read-Only Access, but it can be changed to a more restrictive role or even a special No Access role which will deny access to all LDAP users who aren’t mapped explicitly. You can see this in Fig. 255.

LDAP Roles Settings - default role: "No Access"

Fig. 255 LDAP Roles Settings - default role: “No Access”

OAuth2 Authentication Provider

A generic OAuth2/Open ID Connect server can be used for user authentication. CodeScene supports the Authorization Code Grant flow, and uses the token received through the authorization process to access user and team info from configurable URLs at the OAuth2 provider.

OAuth2 authentication is turned off by default and the configuration fields are hidden as shown in Fig. 256.

Inactive OAuth2 authentication

Fig. 256 Inactive OAuth2 authentication

Activate OAuth2 Authentication by clicking on the “Use OAuth2 Authentication” checkbox and fill in the details as shown in Fig. 257.

OAuth2 Provider Settings

Fig. 257 OAuth2 Provider Settings

You will need to register CodeScene as an application/consumer at the OAuth2 provider. The provider will then create a Client ID and Secret that you use when configuring the provider in CodeScene. The other settings are specific for each provider, and the buttons at the top can be used to set these to typical settings for some common providers. Note that the scope requested must be such that it gives access to the specified user/team URLs and fields.

OAuth2 User and Team Settings

Fig. 258 OAuth2 User and Team Settings

The User URL setting supports URLs like the OpenID Connect UserInfo endpoint, i.e. an URL that, when given an access token, returns claims for the logged in user.

Similarly, the Teams URL supports URLs that, when given an access token, return a list of the teams that the logged in user is a member of.

Note about the User Name and Team Name fields:

  • The User Name field is a JSON Path that selects an attribute in the user API response that represents a user’s identifier.

  • The Team Name field is a JSON Path that selects names of all teams in the teams API response. Check the typical settings for providers. Some providers return teams as a top-level JSON array while others (like BitBucket and Azure AD) return them wrapped in another top-level JSON object. Yet another providers (e.g. PingID’s groups attribute) don’t provide a proper list but instead return a simple string where groups are separated by a comma (CodeScene has special support to handle this scenario - so for PingID you would just use $.groups).

E.g. Bitbucket Teams API may return following API response:

{
  "pagelen" : 10,
  "values" : [ {
    "username" : "empear",
    "display_name" : "empear",
    "uuid" : "{f19d05a0-693c-4327-bd80-58eff5a64d04}",
    "links" : {
      "hooks" : {
        "href" : "https://api.bitbucket.org/2.0/teams/%7Bf19d05a0-693c-4327-bd80-58eff5a64d04%7D/hooks"
      }
    },
    "created_on" : "2018-04-16T13:38:09.387625+00:00",
    "type" : "team",
    "properties" : { },
    "has_2fa_enabled" : null
  } ],
  "page" : 1,
  "size" : 1
}

To extract the team name, which is stored as the username field in the values array, we use the following JSON Path syntax: $.values[*].username. The * symbol selects all the elements (teams) in the values array if multiple teams are returned in the response.

In summary, the steps to follow for configuring OAuth2 authentication are:

  1. In CodeScene, make sure the CodeScene Host URL is set to a URL where CodeScene can be reached from the OAuth2 Provider.

  2. Note the Redirect URL in CodeScene’s OAuth2 Provider Settings.

  3. At the OAuth2 provider, register an application/consumer and set the Callback/Redirect URL to CodeScene’s Redirect URL.

  4. Note the Client ID and Client Secret values.

  5. In CodeScene, set the Client ID and Client Secret values.

  6. Set the other OAuth2 Provider Settings to values specific for the OAuth2 provider.

OAuth2 Roles Settings

OAuth2 role settings and matching works exactly as described in LDAP Roles Settings with the difference that the matching in this case is done using the username and team names acquired from the User/Team URLs as defined in the Oauth2 Provider Settings.