Roles and Rules - Hitachi ID Identity Manager
(1) Hitachi ID Identity Manager can create login accounts using templates and roles:
- Rather than requiring an administrator to provide every
parameter when creating a new account on a target system, Identity Manager
can copy all relevant parameters from a template account.
In effect, Identity Manager implements a "clone user" operation.
- Note that not every user object on every target system can or should
be cloned. Requiring Hitachi ID Systems customer administrators to name the accounts
which should be available as templates
ensures that users whose profiles have accumulated excess
entitlements over time are not cloned.
- Change requests, automated processes or updates initiated
by administrators may specify attributes that override those copied
from the template. For example, a new account may be created by
copying a model account but overriding the employee number, phone
number, e-mail address, login ID, directory OU, home directory
server, mail server, etc.
- Attributes may be entered by a user or administrator (e.g.,
phone number), may be validated by a plug-in that implements
business logic (e.g., building code) or may be assigned
by a plug-in that implements business logic (e.g., login ID,
directory OU, e-mail address). Plug-ins embody business rules
and may be as simple or as complex as required.
- Template accounts and membership in security groups can be collected
into named sets called roles. This allows requests to
specify whole sets of entitlements, rather than individual accounts
and groups, should be granted or revoked. This simplifies the UI
for business users, who may not have a clear, technically accurate
idea of what entitlements to ask for.
- Roles may be functional -- i.e., encapsulating all the entitlements
needed by a given class of user.
- Roles may also be application-oriented -- i.e., encapsulating a commonly
used set of entitlements within one or more applications.
- Functional roles are appropriate for large groups of users with
identical business responsibilities.
- Functional roles are also an excellent baseline for all users.
For example, a functional role may be defined for "basic
network and e-mail access."
- Application-oriented or technical roles are appropriate for users whose
requirements are relatively unique.
- Roles can be nested, to simplify definition of complex sets of entitlements.
For example, functional roles can and typically should be composed of
application roles, which in turn encapsulate fine-grained entitlements
on target systems.
- Change requests may include adding or removing roles, adding or removing accounts, adding or removing group memberships and updating profile attributes.
(2) Identity Manager does not require that users be classified into roles.
Identity Manager can be configured to compare users' actual security entitlements on target systems to the entitlements that their assigned roles predict and to automatically make adjustments to bring users into compliance. This process is called RBAC enforcement.
RBAC enforcement is not a mandatory component of Identity Manager and indeed the scope of enforcement can be controlled at multiple levels:
- Users can be enabled/disabled for enforcement.
- Roles can be enabled/disabled for enforcement.
- Entitlements (i.e., accounts on target systems and security groups whose membership is managed by Identity Manager can be enabled/disabled for enforcement).
- The number of users whose profiles are subjected to enforcement per day can be capped.
These mechanisms allow Hitachi ID Systems customers to use RBAC enforcement -- or not -- based on the appropriateness of this mechanism to their environment. In general, we have found that RBAC enforcement is manageable for large numbers of users with identical needs (e.g., point of sale, retail, etc.) and to small numbers of high-risk users (e.g., finance/budget) but not usually cost-effective for other, unique, back-office user populations.
Attributes can be attached to templates, groups and roles in Identity Manager, to make them easier to find. For example, these resources can be classified by type and location and automatically assigned, filtered on search results, etc. accordingly.
In order to ensure that the numbers of templates and roles are manageable, Identity Manager supports request attributes, which override the detailed attributes of templates and roles.
Request attributes may be entered by users and are in general validated and filled out by plug-in programs, written to implement Hitachi ID Systems customer-specific business logic. These plug-in programs can be thought of as implementing rules.
The combination of roles and rules can be best explained using an example:
- A manager hires a new employee and uses Identity Manager to request
- The request includes:
- Identity attributes, including the new employee's name, department code, job code, employee number, telephone number and office address.
- A role, specifying basic network and e-mail access.
- An additional template account, specifying a particular type of access in an engineering application.
- An initial password.
- A plug-in program uses business rules to assign a globally-unique,
standards-compliant login ID to the new employee.
- Another plug-in program uses business rules to validate that
the department code, job code, employee number and telephone
number are all appropriately formatted and mutually consistent.
It also assigns:
- A directory OU based on the department code
- A file server name based on the building and floor components of the office address
- A mail server name based on the same parameters
- A final plug-in program is run, applying further business rules
to identify appropriate authorizers for the request. For example, the
plug-in can use reporting lines in an HR application to find a
sufficiently empowered manager that the first manager reports to.
- Identity Manager workflow then follows the request through an approval
process -- e-mail invitations and authenticated, secure web replies.
- Once approved, the request is passed to connector programs, which create
login accounts on applications and directories, set up a home
directory with appropriate privileges and initial content to the
new user, set up a mail directory, etc.
- When all of the operations in a request have been completed, a confirmation e-mail and a welcome e-mail are sent to the manager, to forward to the new employee.