Kiuwan uses Role-Based Access Control (RBAC) to define and manage permissions for users and user groups. RBAC helps you control who can access what (applications/portfolios) and which actions they can perform.
Permission model: Subject - Role - Object
Kiuwan's RBAC system is based on a three-part model:
- Subject: A User (e.g., John, Mary, etc) or a Group of Users (Developers, Functional Analysts, etc.)
- Role: A predefined or custom set of permissions (e.g., Read Only, Write)
- Object: A Kiuwan entity (basically, Portfolios and Applications)
Note: Roles are not global. You must always define all three parts when assigning permissions. For example: John (Subject) → Readonly (Role) → Application X (Object).
This model allows you to create highly granular access policies.
Permissions
Kiuwan provides a set of permissions that you can grant to any user (or user group) over any portfolio or application.
| Permission | Description |
| View deliveries | View data of delivery analyses (defects, audit results, etc) |
| Delete deliveries | Delete delivery analyses |
| Execute deliveries | Execute delivery analyses |
| View application data | View analysis data (defects, metrics, action plans, etc) |
| Execute analyses | Execute baseline analyses (CS, CA, and IS) |
| Execute analyses in the cloud | Execute baseline analyses uploading the code to the Kiuwan cloud Saas |
| Delete analyses | Remove baseline analyses |
| Mute defects | Mute defects on baseline and delivery analyses |
| Change defect status | Change the status of a defect on baseline and delivery analyses |
| Save action plans | Create and edit actions plans |
| Delete action plans | Remove existing action plans |
| Export action plans to JIRA | Use the Jira plugin to create issue from action plans |
| View analyzed source code | View the defects together with the complete source code (this option is sold separately) |
| Upload analyzed source code | Upload the complete source code to Kiuwan so the defects could be inspected in the full source code |
| Upload source code fragments | Upload only the code line where the defect is found. |
Roles
Kiuwan provides several built-in roles. These predefined roles are commonly used and can serve as templates to create your own custom roles.
| Built-in role | Common use |
| None | No permissions (no access). |
| Readonly | Read-only access to analysis data (baselines and deliveries). |
| Readonly deliveries | Read-only access to delivery analysis data only (no baseline access). |
| Write | Suitable for users who should have full access to an application (execute analyses, delete them, etc) |
| Write deliveries | Execute and view delivery analyses only (no baseline access). |
Note: Built-in roles cannot be modified, but you can create as many custom roles as needed, selecting from the available permissions.
Note: Roles apply to specific Portfolios or Applications; there are no global roles.
Administration privileges
| Admin privileges | Description |
| Manage applications |
Create, edit, and delete Applications and Portfolios. Grants access to the Application Management module (classification in portfolios, assigning quality models and audits, etc.). See Applications management for further information on this subject. |
| Manage users |
Full access to the Users Management module. Allows:
Additionally, combined with Manage applications, the user will be able to:
|
| Manage models |
Create, modify, publish, and delete Models, and configure the Default Model. Granting this privilege to a user will allow full access to the Models Management module where the user will be able to create and manage Quality Models. See Models Manager User Guide for further information on this subject. |
| Manage audits |
Create, modify, publish, and delete Audits, and configure the Default Audit. See Audits Management for further information on this subject. |
| Manage reports |
Create, modify, publish, and delete Custom Reports. See Custom Reports for further information on this subject. |
| View governance |
Access the Governance module. Users see only aggregated data for applications they are allowed to access (at least the Read only role). See Kiuwan Governance Doc for further info on this subject. |
| View code analysis | Access to code analysis tab and its reports. |
| View code security | Access to code security tab and its reports |
- Full Admin: Any user granted All admin privileges becomes an admin.
- The account owner is the full admin of the account and can create additional admins by granting all the admin privileges.
Users and User Groups
You can create single Users as well as User Groups, and assign permissions to single Users or User Groups.
- If a user belongs to one group, they inherit that group’s permissions.
- If a user belongs to multiple groups, Kiuwan grants the union (OR) of all group permissions.
To ignore group inheritance for a specific user, enable Override user group. This applies only the permissions assigned directly to the user.
To override group inheritance, select Override user group. This grants users only the permissions assigned directly to them, ignoring group memberships.
Permissions on Portfolios and Applications
Applications can be classified according to the available Groups of Portfolios.
There are two built-in groups of portfolios: Business Value and Provider:
| Group of Portfolio | Description | Values |
| Business Value | Classification of the app according to this value from a business point of view |
Fixed and not-modifiable set:
|
| Provider | Classifies apps by the company responsible for their development/maintenance |
Empty by default:
|
You can also create additional custom portfolio groups. Every application will have a value for each portfolio group:
- A specific value, or
- Unassigned (if not explicitly classified)
Permissions on portfolios
If you want permissions to be driven by portfolio classification:
-
Select Permissions on portfolios.
-
For each portfolio value, assign a Role (set of permissions).
Note: If an application is Unassigned in a group, Kiuwan assumes the None role (no access) for that group. Applications can be classified into multiple portfolio groups, the effective permissions for an application are the union of the roles assigned across all relevant portfolio groups.
Example 1
- You define a user with ReadOnly permissions on apps with a portfolio value High in a Business Value portfolio.
- This means that for any application classified as such, that user will have the allowed actions defined in the ReadOnly role.
- Also, you define for the same user None as the role for apps with value South Africa in the Provider portfolio group.
What would be the permissions for an app that is High (in Business Value) and South Africa (in Provider)? As said above, it would be the union set, being in this case equal to the ReadOnly role.
Example 2
- You define a Mute defects role with only Mute defects action and a Create Notes role with only the Create Note action.
- You associate Mute defects with High and Create Notes to South Africa.
What would be the resulting set for any app classified as such? The user will be able to Mute defects AND Create Notes.
Permissions on applications (override portfolios)
Portfolio-based permissions take precedence by default. If you need to grant permissions directly to a specific application regardless of its classification:
- Select Permissions on applications.
- Select the Role for that user/application.
- Enable Override (if Override is not enabled, portfolio permissions will still apply).