HQ Users and Roles

Hyperic HQ offers the ability to configure fine grained access to resources that are defined in the inventory. This is done using the HQ Role Based Authorization model. In this model a role defines a set of permissions, a role contains groups of resources on which the permissions apply. Then users are added to the role which gives those users the configured permissions on the resources in the role.

Users

To create a new user, use the New User... link on the Administration page. The following fields are required:

Name - There are fields designated for the new user's first and last names.
Username - This is the login name the user will use to use HQ.
Email - This is the email address that will be used for email-based notifications or alert escalation messages.
Password - The password for logging into the account.

The Phone, Department, and SMS Address fields are all optional.

The SMS Address is an email-to-SMS gateway email address for the user's SMS device. For a cellular phone on the Cingular network, this might look like 4155551212@mobile.mycingular.com. Check with your service provider for details about your email-to-SMS configuration.

Note If you use basic alert notifications to notify HQ users or roles when an alert fires, notifications will be sent to the email address AND the SMS address defined for each user. Both messages will be in the format of the regular email alert message (long format), which can result in up to five separate messages on the SMS device each time notification is sent by HQ. If, on the other hand, you notify a user or role by SMS in an Escalation Scheme, the SMS message is formatted in a way that is more useful on mobile divices (short format). As a best practice, it is recommended that SMS alerting is used in conjuction with Escalation.

Users authenticating using an LDAP directory must log in the first time to create their user in the HQ system. To edit or remove users, use the List Users link on the Administration page.

By default, a new user does not have access to any of resources in the inventory. To grant permissions on resources, the user must be assigned to a role.

Roles *

Hyperic HQ uses the concept of roles to manage the permissions individual users have to perform various tasks within Hyperic HQ. Roles determine whether a given user can view, create, modify, monitor, and control a specified Resource Type. Resource Types include:

• Users
• Roles
• Groups
• Platforms
• Services
• Applications

A role will define a set of permissions. Those permissions do not apply to anything until a group of resources is assigned to the role. When a group of resources is assigned to the role, the permissions will apply to those resources. In order to grant those permissions (on those resources) to users, simply assign users to the role.

Common Problem One of the most common problems when setting up new Users and Roles is that the new user cannot see anything. The missing piece is that the Role the user is a part of does not have any resources assigned to it. To solve the problem, add the resources you wish the user to see to a group and add that group to the Role.

There is one special attribute on the New Roles page. This is the Administer HQ Server Configuration attribute. This is NO by default. If this is set to YES, any user in this role will have the ability to configure the HQ Server Settings.

Roles are cumulative. So a user can be assigned to multiple roles and have multiple permissions sets on multiple resource sets.

Role Based Alert Notifications Roles are very useful for alert notification to groups of people. One good way to do this is to define a role with no permissions and no resources assigned to it. Assign the users to be notified to the role, then add the role to the alert definition.

Because the platform, server, and service resources "stack" (in the sense that services run on servers that in turn run on platforms), permissions are also stacked. For instance, the permission to create a server (or any child object on a resource), is predicated on the parent resource allowing you to do so. For example, the permission to add a server is really associated with a platform.

Permissions If a user is designated as the owner or a resource, that user will have unlimited permissions for that resource. Some examples of possibly unexpected (but correct) behavior: If a user owns a platform, that user can create servers on that platform even though he does not have permission to create servers through a role. If that same user has permissions to create servers through a role, that user can create a server on any platform (whether he owns it or not) as long as that platform is a member of a group assigned to the same role.