You are here: 5.0 Virtual Private Clouds > Customizing VPC Functionality (vpcs.xml) > Managing VPC Users
|
|
5.1.6 Managing VPC Users |
Viewpoint has the ability to manage user roles and access to a VPC. This information is stored on the database configured with Viewpoint. You can configure user management options within the vpcs.xml file. This configuration is done through the <modify-users
> element. Within the <modify-users
> element, the "host" and "path" attributes are optional. In the Manage environment, when a user selects a VPC and clicks Manage Users, the Manage Environment Access page displays:
User roles are divided into role groups. In the above image, there are two role groups. An organization can have as many roles and role groups as they wish, but each role should belong to exactly one role group. Role groups are for display and organizational purposes only; the database is unaware of which roles belong to which role groups.
To specify a role group, use the <role-group
> element. This element requires one or more <role
> elements and an optional <description
> element. The description is displayed to the user as the section header. The individual <role
> elements require a description (which is displayed to the user) as well as a unique id. The id is stored in the database with the user that has that role.
Here is an example that configures two role groups and produces the example image above:
<role-group id="admin"> <description>Admin Access</description> <role id="acl"> <description>Admin</description> </role> </role-group> <role-group id="vlans"> <description>VLAN Access</description> <role id="dev_vlan" default="true"> <description>Development</description> </role> <role id="test_vlan"> <description>Test</description> </role> </role-group>
There is a special role that uses the keyword of "acl". If the "acl" role is used, the VPC users with the Access Control List (ACL) role are added to the VPCs ACL in Moab upon modification. If a user is part of a VPCs ACL, they are able to view, modify, and administer the VPC.
Every role other than "acl" is used to communicate the modification information to an external source. In order to communicate with an external source, a path that points to an executable script is required. The script is passed an argument of "id=<vpc_id>". It is expected that the script gets the user information from Viewpoint's database. By default, the script is found on the Web server. If the "host" attribute is set to the value Moab, the script is found on the Moab host. The Moab host is determined by the Moab connection information found in core.xml.
When the user clicks Modify, the script found in the path is executed. Execution of a script is expected to return a result of a particular interface. The XML looks something like this:
<response type="manage-vpc-users"> <result success="true"> The users were successfully modified. </result> </response>
The script defined in the path must be executable. |
With the <validation
> optional element, you can set rules to check if the inputs on the manage users dialog are valid. The user is notified that they should change their inputs to valid values. The validation requirements are evaluated every time the user wants to make a change. After each change, the validation is checked and the response is fired. If the current role setup is invalid, the user cannot select another user and cannot click OK until the conflict is resolved. As soon as the user enters a valid value, the warning messages go away and the OK button is re-enabled.
In order to accomplish role validation, you must specify a validation rule and the associated response. In the <validation
> element, create a child <rule
> and <response
>. The <rule
> element must evaluate to false for the response to occur. This element should be any boolean decider. The <response
> element describes the behavior of the GUI when <rule
> evaluates to false.
A <response
> element defines which components to invalidate and the corresponding error message. The <response
> element has a <message
> element as well as any number of <component
> elements that get invalidated with the message.
In this example, validation is configured to verify all VPC users have at least one role:
<validation> <validation-rule> <requirement logical-operation="or"> <value> <component id="test_vlan" /> </value> <value> <component id="dev_vlan" /> </value> <value> <component id="acl" /> </value> </requirement> <response strict="true"> <message>All users must have at least one role</message> <component id="test_vlan" /> <component id="dev_vlan" /> <component id="acl" /> </response> </validation-rule> </validation>