Role Details Window

Roles are the mechanism for controlling Privileges, which form half of Permissions management along with ACLs. Roles are managed in the Admin Access window of KeyConfigure. Assigning a Role to an Account grants privilege to that authenticated user.

    

Accounts Pane

Notice the External Group field. This is only useful when Admin Authentication is configured, but can be used with many built-in roles. It refers to a group as defined in the external authentication method (e.g. an AD group), not an internal Account group or computer Group. This can be used to automate logins and the applied Roles for an external source. For example, a Domain user tries to authenticate for the first time and has no account yet in KeyServer and therefore no role. The server finds they are a member of an AD group referenced in the External Group field of a role and therefore makes their account and applies that role and the user logs in with the desired rights.

Note that using this functionality can not be mixed with local role assignment that is out of sync with the external group. That is, if you apply a role that points to a group to an account that is in the external system but is NOT in the group, the role will be removed on login attempt and they may therefore be prevented entirely. Similarly, if you remove the role from the account in KeyServer but they are still in the external group, it will be re-applied at next login. When using external groups in a role, you need to manage membership in that external group, not in KeyServer.

This is not to say that automation is required. You can ignore this external group setting and manually assign Roles to manually created External type Accounts. If you do wish to use the automation, you must also ensure proper settings for Create as Needed in Admin Authentication.

The Name field simply shows a list of Accounts that are members of this Role.

Privileges Pane

This pane allows you to view and possibly edit Privileges for a Role. You can not modify these settings for built-in roles and they will show as grayed out. You can use a built in role as a starting point for modifications by right clicking on a Role and choosing Duplicate. The special Administrator Role always has all privileges. The buttons across the top offer quick ways to bulk set all privileges in the Role. To see all items under each section of privileges, right click in this box and Expand All. You can then easily see the results of clicking the buttons at the top.

Clicking on the expansion icon next to any group will show or hide the individual privileges within the group. Green items are a Read privilege, Black items are Write (change/delete) items. The privileges are turned on and off for the Role by clicking the check to the left of each item. Note that some of the privileges are “linked”. That is, if you disable or enable one, it may automatically disable or enable others as well. For example, in the Policy Privileges group, if all the privileges are enabled and you disable View Details of Policies, Change Details of Policies will also get disabled. This makes sense, since if you cannot even see the details of Policies, you clearly shouldn't be able to change them.

Privileges

The name of each Privilege is largely self-explanatory, as long as you are familiar with the KeyConfigure and Web interface. There are some that are used for internal purposes, future planning, or deprecated features however, so testing is advised and Sassafras Support is available to assist as needed. Below are some notable privileges and how they commonly impact desired permission results.

• Account Privileges - Largely deal with account management and not needed for non-admin types
• Logon in KeyConfigure - If someone will only use the Web UI, this is not needed
• View Own Account Details and Change Own Account Password - not useful if using External accounts
• Settings Privileges - Largely deal with system settings, and mostly not needed for non-admin types
• View Default Purchase Currency - may be needed for those dealing with purchases as it affects not just seeing the setting but seeing the result
• View Division Separator - Usually should be enabled to allow expecting display of Division names
• View System User Names - If trying to exclude system users from reports, this needs to be enabled to access the names to exclude
• Active Client Privileges - Largely relate to the Connected Clients window in KeyConfigure, but also impact some Widgets working that need access to this data.
• Location Privileges - As Locations are rarely used (network segmentation feature) these are generally not needed.
• Software Audit Privileges - Important for running Audit reports.
• Shadow Privileges - Relate to backup shadow servers which are almost never used anymore, thus can be ignored.
• Journal Privileges - Relate to the Admin Journal (log of admin actions), so rarely needed for non-admin types.
• Report Privileges - Mostly relate to the Reports window, but there are some KeyReporter specific items as well.
• KeyReporter Privileges - related to the Web UI. While in some ways independant of the above, there is also interaction that needs to be considered.
• Completed Reports - these items relate to completed report files as compared to On Demand or Scheduled report templates
• Report Schedules - these items relate to scheduled report templates as compared to on demand or complete report files
• Search for Objects in KeyReporter - Controls if you can use the Search on the Dashboard page to search for any object type
• View object details in KeyReporter - Controls if you can click on something like a Computer and see the details page for that system.
• View and Modify objects via REST API - Keep in mind the Web UI uses the REST API to perform tasks. As such View should almost always be on, and if the Role will modify anything then Modify needs to be on.
• View xxx List Page in KeyReporter - You can create interesting configurations if for example you allow a Role to edit computers in the above, but don't let them see the computers page in the Web UI! Or the inverse, they can see it in the Web, but you don't allow view on Computers so the page is blank.

Most sections like Policy, Product, Computer, Purchase, etc are self explanatory and you can simply consider what privilege you want to grant to those object types. Do keep in mind interactions between objects however. For example, if you want a purchasing agent to enter purchase records for software, but do not grant the ability to modify Products, they can't link the Purchase to a Product and a higher level user will need to do that part. Likewise, if you want to link a Computer to a Purchase but can't edit purchases despite editing computers, you can't make the link. One must carefully consider Roles as both workflow and technical limitation and find the proper balance between the two. This can often be a use case for granular Access rights, so that you limit a person to access only the objects within their department, but allow privilege to modify all said types.

Notes Pane

Notes as always are free form for your use. For built-in Roles this will have a description of the purpose of the Role for built in Accounts, or possible use case for other accounts.