Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »


Kiuwan Users Management


By “Users Management” we will refer also to Permissions Management, Access Policy, and all the security-related issues of the Kiuwan account.

User Management module can be selected at the top-left drop-down menu.

Single Sign-On


If you Kiuwan account is Single Sign-On (SSO) enabled, please visit How to integrate Kiuwan with SAML SSO - SSO login vs username-password login




Users Management module contains 3 tabs that allow to manage different aspects of users and permissions.

  • Users 
    • Allows to manage Users (creation, modification and deletion) as well as different actions on selected users (password setting, permissions granting, etc.)
  • User Groups 
    • Allows to manage Users Groups, i.e. to create sets of users that shares the same privileges.
  • Roles 
    • Allows to manage Roles, i.e. named groupings of permissions that can be further used to grant privileges to users and user groups.


Use of these sections is straightforward if you clearly understand the concepts. So, in these document we will focus on explaining the concepts.


Permissioning Model

Role-based Access Control (RBAC)


Kiuwan implements a role-based access control approach that allows you to fully define the permissions of your Kiuwan installation.


Permission model is based in the tuple :  Subject - Role - Object

  • Subject means a User (John, Mary, etc) or a Group of Users (Developers, Functional Analysts, etc)
  • Role means a grouped set of permissions (for example, Readonly, Write, etc)
  • Object is any Kiuwan entity (basically, Portfolios and Applications)


common misconception is to think that somebody can be assigned a role (John has Read role) that applies to all the objects. This does not work so.

 The three components of the tuple (Subject, Role and Object) are always needed.

This permission model lets you to define at a very fine-grain level your access policy.





Kiuwan provides a set of permissions that you can grant to any user (or user group) over any portfolio or application.




View deliveries

To view data of delivery analyses (defects, audit results, etc)

Delete deliveries

To delete delivery analyses

Execute deliveries

To execute delivery analyses

View application data

To view analysis data (defects, metrics, action plans, etc)

Execute analyses

To execute baseline analyses (CS, CA and IS)

Execute analyses in the cloud

To execute baseline analyses uploading the code to the Kiuwan cloud Saas

Delete analyses

To remove baseline analyses

Mute defects

To mute defects on baseline and delivery analyses

Save action plans

To create and edit actions plans

Delete action plans

To remove existing action plans

Export action plans to JIRA

To use the Jira plugin to create issue from action plans

View analyzed source code

To view the defects together with the complete source code (this option is sold separately)

Upload analyzed source code

To upload the complete source code to Kiuwan so the defects could be inspected in the full source code

Upload source code fragments

To upload only the code line where the defect is found.





Role is a concrete set of permissions.


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


Empty set of permissions. It means no-access at all.


Users that only should be granted read-only access to analysis data (baselines and deliveries)

Readonly deliveries

Similar to Readonly but restricted to data coming from deliveries analyses, not granted to see baseline’s data


Suitable for users that should full access to an application (execute analyses, delete them, etc)

Write deliveries

For users that should only be allowed to execute (and view) delivery analyses, not being permitted to access baseline’s data.


Built-in roles cannot be modified but you can create as many custom roles as you need, selecting among the available permissions.


Bear always in mind that roles are assigned to Portfolios or Applications. There are not global roles, a role always applies to some object.



Administration privileges



Additionally to permissions and roles, there are some Administration privileges that can be granted to users or group of users.



Admin privileges


Manage applications

Any user with this privilege is allowed to create, edit and delete Applications and Portfolios.

Granting this privilege to a user will allow full access to Application Management module where that user will be able to create and manage Kiuwan apps (to classify the app on portfolios, to assign a quality model and audits, etc).

Please, see Applications management section for further info on this subject.

Manage users

Granting this privilege to a user will allow full access to Users Management module where that user will be able to:

    • Create and delete account users
    • Change the account owner
    • Grant Admin privileges to users

Additionally, combined with “Manage applications”, the user will be able to:

    • Create user groups and new roles

    • Assign permissions on portfolios or applications to users (or group of users)

Manage models

To create, modify, publish and delete Models,as well as to configure the Default Model.

Granting this privilege to a user will allow full access to Models Management module where the user will be able to create and manage Quality Models.

Please, see Models Manager User Guide section for further info on this subject.

Manage audits

To create, modify, publish and delete Audits as well as to configure the Default Audit.

Please, see Audits Management section for further info on this subject.

Manage reports

To create, modify, publish an delete Custom Reports.

Please, see Custom Reports section for further info on this subject.



Important :

  • Any user granted with ALL admin privileges becomes an “admin

  • Account owner is the full “admin” of the account and can create additional admins by granting all the admin privileges.


Global permissions


View governance

Access to Governance module.

Even with these privilege, the user will only see aggregated data from “allowed” applications (i.e. at least with Readonly role)

Please, see Kiuwan Governance Doc section for further info on this subject.

Support Enabled

Access to Kiuwan Technical Support (chat or ticket-based)


Users and User Groups 


Kiuwan allows to create single Users as well as User Groups, and consequently to assign permissions to single Users or to User Groups.

  • If a User belongs to one User Group, the permissions granted to that user will be those granted to the User Groups he belongs.

  • If a User belongs to more than one User Group, the resulting set of granted permissions is the union (OR) of every user group’s permissions, i.e. the user will have permissions from one group plus the permissions from the others group.


If you want to avoid this “user group’s inheritance”, select “Override User Group” and that user will be granted only with the permissions exclusively assigned to him, regardless his membership to any user group.


Permissions on Portfolios and Applications

Any Application can be classified according to the available Groups of Portfolios.

There are two built-in group of portfoliosBusiness Value and Provider


Group of Portfolio



Business Value

Classification of the app according to this value from a business point of view

Fixed and not-modifiable set:

  • Critical, High, Medium, Low and Very Low


Company in charge of developing / maintaining the application

Empty by default,

  • custom values can be defined


Besides these built-in groups, you can create as many custom groups of portfolios as you need.


Any application will always have a value for each of the existing groups of portfolios:

  • either a concrete value

  • or “Unassigned” (if that app has not been explicitly classified into that group


Then, if you want to grant permissions based on Portfolios just select the option “Permissions on portfolios”.



Then, you will be able to select the specific access Role (i.e. the set of permissions) to every portfolio of the available groups.


IMPORTANT: If some application is “Unassigned” in some group, None role is assumed (i.e. no-access)



As any application can be classified in several portfolio groups, the final permissions set for the app is the union of allowed actions for every role assigned to every portfolio group.


Let see with an example.

  • You define a user with “ReadOnly” permissions on apps with portfolio value “High” in “Business Value” portfolio. 
    • This means that for any application classified as such, that user will have the allowed actions defined in “ReadOnly” role.
  • Also, you define for the same user “None” as the role for apps with value “South Africa” in “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 ReadOnly role.


Another example.

  • You define a Role “Mute defects” with only “Mute defects” action, and role “Create Notes” with only “Create Note” action. 
  • You associate “Mute defects” to 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”.




Because every application is always classified into every group of portfolio, permissions on portfolios take precedence to permissions on applications.

If you need to override this behaviour and grant permissions directly to the application (regardless its classification):

  • select “Permissions on applications”,
  • select the Role and 
  • be sure to check “Override” (otherwise the portfolios permissions will apply).

Users Management

The User Management section in the Setup menu allows you to manage the users and their permissions associated to your account.



At CSV option menu you can export to a CSV file a full listing of users and permissions.


Add a new user

Clicking on the Add button you get access to the New User form.



  • Username field is the unique identifier of a Kiuwan user. The user needs to specify this username whenever accessing Kiuwan. Username must be unique so it’s recommended to use a suffix that identifies all users in your organization.
  • Email field is the email address of the user so any Kiuwan notification will be sent to that email address. Email does not need to be unique, so there might be users with the same email address.
  • Name and Lastname fields are descriptive fields to further identify the user.
  • Enabled check allows to enable/disable the user to access the Kiuwan account.
  • By checking the Generate password checkbox, Kiuwan will send a new password to the user. New users can not access Kiuwan until they receive their new password.


Set user as owner

In the dropdown menu of each user, you can select Set user as owner to change the account owner.

Any Kiuwan account has a unique “account owner”. The account owner is granted full permissions on account administration, applications and portfolios.

Any user can be set as Account Owner by the current owner, and by assigning this role to a new user the current owner will cease to be the current owner. Once a new user is set as owner, the old owner will be set with default permissions (none).


Confirm this action in the pop-up window that will show up once you have selected the Set as owner option for any user:


Set a new password

In the dropdown menu of each user, you can also select New password for the selected user.

Selecting this option will generate a new password and sent to the user’s email address.


Set administration privileges

Administration privileges can be granted to any users, which enable them to manage applications, users, quality models and/or audits as if they were the account owner.



For a full explantion of admin privileges, see Administration privileges 


Set permissions on portfolios

The account owner (or any user with “Manage Users” privilege) can assign application permissions based on the app classification in portfolio groups.

Permissions can be assigned to portfolio values by selecting a Role (i.e. a defined set of allowed actions) for every portfolio value.


Please, see Permissions on Portfolios and Applications section to fully understand permissions assignment.


Important: Permissions based on portfolio values take precedence over app permissions.

In case you want app permissions to take precedence over portfolios permissions, you should check “Override” button in Application Access Permissions.


Set permissions on applications

The account owner (or any user with “Manage User” privilege) is entitled to assign specific application permissions.




By selecting the Override checkbox, the role assigned to that user and application will be prioritized over the role selected on Access permissions to Portfolios.


Please, see Permissions on Portfolios and Applications section to fully understand permissions assignment.


Bulk actions

If you want to set the same option for several users at once, you can do it by selecting those users and, then, choosing the corresponding option on Bulk actions dropdown menu, as showed below:


User groups

A User Group is a set of users that shares the same permissions (admin privileges and/or permissions on apps and portfolios).


Whenever you need to assign the same permissions on the same entities (apps and portfolios), you can define a User Group, define the set of privileges and assign users to that User Group.

Doing this way, with one click you will be able to grant all the users of that group the same permissions instead of granting one by one.

For example, you can divide users in development teams, so the users in the same user group will be able to manage the applications they are working with the same set of privileges.


Any user can be assigned to many user groups. In this case, a union of all user group's permissions will be granted to that user.

  • If a User belongs to one User Group, the permissions granted to that user will be those granted to the User Groups he belongs.

  • If a User belongs to more than one User Group, the resulting set of granted permissions is the union (OR) of every user group’s permissions, i.e. the user will have permissions from one group plus the permissions from the others group.

In case of conflicting permissions on the same entities (apps and portfolios), the most permissive set is applied.



Once a user belong to a User Group it will be not possible to assign individual permissions for that user.

If you want to avoid this “user group’s inheritance”, select “Override User Group” and that user will be granted only with the permissions exclusively assigned to him, regardless his membership to any user group.

Doing this way, individual permissions will be granted instead of user group’s permissions.


Create new User Group

To create a new User Group, click on Add button and drag&drop users from Not Members Users to Group Members.


You can manage the different user roles by clicking on the namesake button in User Management section.


Please visit Roles section for details.


Create new Role

You can add new roles and select their enabled actions by clicking on “Create New Role” button.  



You can manage the actions the different roles can perform by selecting the appropriate checkboxes for each role.




  • No labels