vRealize Automation Identity Service API

Identity Overview

The Identity Service is composed of two components: authentication and authorization. Further details on these components can be found below.

Authentication Overview

The authentication component manages tenants, business groups (formerly named subtenants), groups (both Single-Sign-On and Custom groups), users and identity stores.

Tenancy

A tenant is an organizational unit in a vRealize Automation deployment. A tenant can represent a business unit in an enterprise or a company that subscribes to cloud services from a service provider.

Each tenant has its own dedicated configuration. Some system-level configuration is shared across tenants.

User and Group Management

All user authentication is handled through single sign-on. Each tenant has one or more identity stores, such as Active Directory servers, that provide authentication.

The system administrator performs the initial configuration of single sign-on and basic tenant setup, including designating at least one identity store and a tenant administrator for each tenant. Thereafter, a tenant administrator can configure additional identity stores and assign roles to users or groups from the identity stores.

Tenant administrators can also create custom groups within their own tenant and add users and groups defined in the identity store to custom groups. Custom groups, like identity store groups and users, can be assigned roles or designated as the approvers in an approval policy.

Tenant administrators can also create business groups within their tenant. A business group is a set of users, often corresponding to a line of business, department or other organizational unit, that can be associated with a set of catalog services and infrastructure resources. Users, identity store groups, and custom groups can be added to business groups.

Authentication API Examples

Identifying and groups and users

Both groups (SSO and custom) and users use the same object for identification - the principal id. Principal id consists of name and domain and is serialized in the form of name@domain.

Example usages include:

• Getting a group by principal id: GET /tenants/vcac.local/groups/Administrators@vcac.local
• Getting a user by principal id: GET /tenants/vcac.local/principals/Administrator@vcac.local

• Search all groups using criteria instead of principal id: GET /tenants/vcac.local/groups?criteria=administrator

• Creating a group: POST /tenants/vcac.local/groups

{ 
  "@type": "Group", 
  "groupType": "CUSTOM", 
  "name": "Developers", 
  "domain": "vcac.local", 
  "description": "Developer Group",
  "principalId": { 
    "domain": "vcac.local", 
    "name": "DevGroup"
  }
} 

Authorization Overview

The authorization component manages authorization configurations as a set of triples

• Principal - The user or group to whom access is granted
  • principals are externally definded in authentication service and merely referenced in the authorization service.
• Permission - Identifies the action or data the principal is granted access to.
  • Permissions can correspond to atomic actions (e.g. "Power On VM").
  • They can also act as an abstraction for an entire set of activities (e.g. "VM Power Lifecycle").
• Scope - Defines the context within which the access applies.
  • A scope can identify an object (or an object representing a set of objects) upon which the action identified by a permission can be performed. (i.e. To define an Access Control List (ACL).)
  • A scope can be used to represent a group and the permissions identify the roles of different users within the group. (i.e. To define business groups, aka: sub-tenants)
  • Scope is optional

NOTE: Roles and Permissions are both a part of the PrincipalExtensionApi REST resource.

Role Management

Roles consist of a set of privileges that can be associated with users to determine what tasks they can perform. Based on their responsibilities, individuals might have one or more roles associated with their user account.

All user roles are assigned within the context of a specific tenant. However, some roles in the default tenant can manage system-wide configuration that applies to multiple tenants.

For more high-level details, see the "Foundations and Concepts" documentation located on the vRA public documentation site

Authorization API Examples

Getting a specific role by id

GET /authorization/roles/CSP_TENANT_ADMIN

Creating a new role (e.g: one for helpdesk personnel)

POST /authorization/roles

{ 
  "@type" : "TenantRole", 
  "id" : "HELPDESK_TENANT_ROLE", 
  "name" : "Helpdesk Administrator Tenant Role", 
  "description" : "Role representing helpdesk personnel" 
}

Adding a permission to a role (e.g.: adding permission to tenant administration GUI

PUT /authorization/roles/HELPDESK_TENANT_ROLE/permissions/assigned/GUI_MY_TENANT_MANAGEMENT

NOTE: For this PUT, there is an empty request body.

{}