Role Based Access Control

(Click on images for higher definition view)

Access to all Sessions defined within PUM is allocated to one or more Roles.  A PUM User must be a member of a Role attached to a Session to be able to invoke that Session.  Any number of Users may belong to a Role, and any number of Roles may be attached to a Session.

Membership of the appropriate Roles also defines the administration rights that a PUM User/PUM Administrator has over the PUM objects that make up the PUM Database.  Access to all the objects is controlled in accordance with the organization's security policy by means of the allocation of access control objects which we call Capabilities.  Essentially, access to each type of PUM object is controlled by these Capabilities, as is the function that can be performed against the object.  

There are four types of function:Capabilities screen

  • Add
  • Update
  • Remove
  • View

Individual Capabilities are set for each function against each object.

Let's have a look at an example as shown on the right.  Auditors will typically need access to the PUM audit trails.  There is no reason however why they should be given rights to Add Users, delete Managed Servers etc.  So, we set up a Role called Auditors, and grant the members of this Role the Capabilities to View the four Audit Trails generated by PUM.  But nothing else.  If a member of the Auditor Role logs into the PUMAdmin web UI used to administer Access Policy, then all options will be grayed out apart from those to view the audit trails.  Unless they have picked up additional Capabilities via their membership of other Roles of course.

In this way we can control who does what within PUM both in terms of invoking privileged Sessions and in terms of granting administration rights to PUM Access Policy objects.