Security overview

MidVision uses role based security.

Users are authenticated via Form Login or Single Sign-On methods.

In the case of Form Login, the user is authenticated via an LDAP service or the internal MidVision database.

Single Sign-On configurations supported are Security Assertion Markup Language (SAML) 2.0 and Integrated Windows Authentication ( SPNEGO / Kerberos ).

Users can be assigned to one or more groups. A user may also be directly assigned one or more global roles.

A group may have a number of assigned users, projects and may be assigned one or more global and/or project roles. Global roles apply for the entire application scope. Project roles apply only to the projects that are members of the group.

Authorisation is decided by comparing the users directly assigned global roles, or via transitive role assignments based on the groups they are a member of.

Diagram

Entities relationship:

1. User Group - User: Users can be assigned to any User Group and vice versa.
2. User Group - Role: Roles can be assigned to any User Group and vice versa.
3. Role - Permission: Permissions can be assigned to any Role and vice versa.
4. Role (non global) - Project Group: - If Role is not set as Global, Project Groups can be assigned to any Role and vice versa.
5. Role (non global) - Environment: If Role is not set as Global, Environment can be assigned to any Role and vice versa.
6. Environment - User Group (Deployment Approval Group): User Groups can be assigned to Environment for deployment approval and vice versa.
7. Environment - User Group (Configuration Approval Group): User Groups can be assigned to Environment for configuration approval and vice versa.

   Note: mvadmin (Super User) is granted for all operations in RD, there is no need to add or change any security configuration for this user.

Examples of user configuration:

1. Administrator User:

   In this example, the user can manage any project and resources, view/edit system information, manage RD license and integration extensions. In RD there are built-in roles for general purpose. In this case is using one of these.

   User: admin assigned to Administrators user group

   User Group: Administrators (Users: admin, Allowed Roles: GLOBAL_ADMINISTRATOR)

   Role: GLOBAL_ADMINISTRATOR

   • Assigned to Administrators user group
   • Set as GLOBAL
   • Allowed permissions:
     • Projects: Add, Create Project Files, Discover Project, Download Project, Upload Project, Copy , Edit , Delete , SCM Plugin Operations, Edit Project Resources, Save Project Changes
     • Resources: (Add Server, Edit Server, Enable/Disable Server for Deployment, Delete Server, Discover Server, Server Transport Plugin Operations, Server Cloud Plugin Operations, Add Environment, Edit Environment, Delete Environment, Enable/Disable Environment for Deployment, Export Target Data, Environment Product Plugin Edition, Add Environment Installation, Edit Environment Installation, Delete Environment Installation, Add Orchestration Task, Edit Orchestration Task, Delete Orchestration Task, Upload Orchestration Library, Edit Plan, Delete Plan
     • Miscellaneous: View Admin System Info, Edit Admin System Info, Manage License, Manage Extension Integration
2. Requester User:

   In this example, the user can request new jobs and changes on some projects and environments that need approval. Approval workflow is a nice feature in RD to take over the job execution and changes on critical environments like production.

   User: requester assigned to Deployment Requesters, Configuration Change Requesters

   User Group: Deployment Requesters (Users: requester, Allowed Roles: DEPLOYMENT_REQUESTER)

   User Group: Configuration Change Requesters (Users: requester, Allowed Roles: CONFIG_CHANGE_REQUESTER)

   Role: DEPLOYMENT_REQUESTER

   • Assigned to Deployment Requesters user group
   • NOT set as GLOBAL
   • Allowed permissions:
     • Jobs: Run Project Jobs, Run/Save Deployment Job, Run/Save Installation Job, Run/Save Promotion Job, Cancel Job, Resume Job
   • Allowed Project Groups: My Project Group
   • Allowed Environments: NeedApproval

   Role: CONFIG_CHANGE_REQUESTER

   • Assigned to Configuration Change Requesters user group
   • NOT set as GLOBAL
   • Allowed permissions:
     • Projects: Edit, Request Target Changes, Request Target Promotion
   • Allowed Project Groups: My Project Group
   • Allowed Environments: NeedApproval

   Project Group: My Project Group

   • Projects: PROJECT_A, PROJECT_B, PROJECT_C ...

   Environment: NeedApproval

   • Deployment Approval: Deployment Approvers
   • Configuration Approval: Config Change Approvers
3. Approver User:

   This is an example of a user just only to allow or deny job execution and environment changes.

   User: approver assigned to Deployment Approvers, Config Change Approvers

   User Group: Deployment Approvers (Users: Approver)

   User Group: Deployment Approvers (Users: Approver)

Sample scenario:

You have two projects A and B and similarly two users A and B. Each user is supposed to have access to only her / his projects.

1. Create role SEC_ROLE1 that contains permissions related to project. Take a look at Security -> Role -> select role and add all permissions with project category.
2. Create role SEC_ROLE2 that contains permissions related to project.
3. Create user group SG_A and connect this SG_A with user_A and SEC_ROLE1.
4. Create user group SG_B and connect this SB_B with user_B and SEC_ROLE2.
5. Now create project group PG_A and connect this with project_A and SEC_ROLE1.
6. Create project group PG_B and connect it with project_B and SEC_ROLE2.

   When you have this security architecture user_A will have all permissions from SEC_ROLE1 on project_A and user_B will have permissions on project_B.