Configuring Roles & Access

Quick Guide: Adding User & Role

Add User

1. Navigate to: Your Name (top right) > Users 
2. Select +Add User
3. Fill out Email, First Name Last Name
4. Save User
5. Email will be sent activation link and they will be able to log in.
   But user won't see any nodes or data until given a role

Assign User a Role

1. Navigate to: Your Name (top right) > Roles
2. On an existing appropriate role row, click: Actions> Edit
   1. If an appropriate Role does not exist yet, can Add Role (see below)
3. In Edit Existing Role, click Users
4. Tick the User(s) in left hand box ('Available') and move them to right hand box ('Active') with the arrows
5. Click Save Role
6. User should now have appropriate role after logging out/in.

Note: A User and Role is needed to access Darwinium Portal even when SSO is being used.

Roles

Users are granted access to various permissions in Darwinium through the use of Roles. A role consists of one or more priveleges assigned to a given set of consituent users. A user may be assigned to multiple roles.

The roles section of Darwinium is accessed via Your Name (top right) > Roles 

With the exception of the Administrator role, roles may be added or removed at will. The Administrator role, by default, has access to all resources on the system. It is best practice to avoid adding users who do not absolutely require access to this role.

Permissions explained

When creating or editing roles, you are required to define permissions.
Find in: Your Name (top right) >Roles > Edit (box in role row) > Permissions tab.

Darwinium has 2 types of permission:

• Scope permissions - These apply across the organization and across all node instances
• Workflow Permissions - These are permissions applied to a specific node (...a customer may have several nodes in the system eg: Production vs Staging vs Development)

Scope Permissions

• APIs:
  • Administrate : Users with this permission may sign certificates used for mutual TLS authentication with the API services, and define which nodes and/or Darwinium API services may be used by which certificate.
• Audit:
  • read: Can see internal Darwinium Portal user activity like logins, searches, user creation (Your Name > Audit Logs)
• Nodes:
  • Read: Users may list nodes in the system and view node deployment logs, but may not edit a nodes settings or delete a node
  • Delete : Users may delete nodes in the organizations node list
    
• Roles
  • Create: users may create new roles, and define their permissions, but may not update existing roles if they are not also granted the update role.
  • Delete: Users may delete existing roles
    
  • Read: Users may view the permissions and assigned users for an existing role, but may not make any updates or delete roles.
  • Update: Users have the permission to view and update changes to existing roles, but may not delete existing roles.
• Templates
  • administrate: can add or delete Portal Investigations templates 
• Users
  • Create: users may create new users, but may not update the details of existing users other than themselves if they are not also granted the update role.
  • Delete: Users may delete existing users other than themselves
    
  • Read: Users may view the users that exist within their organization, but may not make any updates or delete existing users.
  • Update: Users have the permission to view and update users, but may not delete users.

Workflow Permissions

These Workflow permissions exist for each node.

eg. A role may allow someone to deploy in test, but not in production 

Permission Level: [No Access | Read Only | Write | Write and Approve Changes ]
Denotes the level of access that the role has to Author updates to workflows (i.e. Journeys, Rules, Features that are published to a given site):

• No Access: User cannot see the workflows view at alll
• Read only: User may view the contents of the journey git repository, but may not submit any changes to it
• Write: User has permission to push changes back to any branch other than the master branch. Changes to the master branch are used to deploy changes to infrastructure, and thus they must be approved by a role that has Write and Approve Changes Permission
• Write and Approve changes: User may update the git repo on all branches, and their account has the ability to deploy changes to edge workers

Allowed to create/edit .journey.yaml files: Allows user to create completely new journey files

PII: [true | false] - Denotes whether users of this role have permission to decrypt Personally Identifiable Information (PII). If this value is unchecked, the user will see an elliptic-curve-hash representation of PII attributes. For more information on which attributes are PII, see Attribute Reference.

SPII: [true | false] - Denotes whether users of this role have permission to decrypt Special Personally Identifiable Information (SPII). If this value is unchecked, the user will see an elliptic-curve-hash representation of PII attributes. For more information on which attributes are SPII, see Attribute Reference.

Deployments::

• Allowed to view/edit deployment settings: Gives access to Node Settings pane. This is where Edge deployment target information exists, so usually restrict to DevOps / Engineering resources
• Allowed to deploy builds: Gives permission to initiate the deployment process, which pushes journey and decisioning changes to their targets (API endpoint or Edge workers).