ID-Synch Roles and Rules

(1) ID-Synch® provisions new users with templates and roles:

Rather than requiring an administrator to provide every parameter when creating a new account, ID-Synch copies all relevant parameters from a template account. In effect, ID-Synch implements a "clone user" operation in place of a "create user" operation.
Note that not every user object on every target system may be cloned. Requiring customer administrators to specify template accounts ensures that users whose profiles have grown over time, and which contain inappropriate security privileges, are not cloned.
Change requests, automated updates or actions initiated in the consolidated or delegated administration modules may specify attributes which override those copied from the template. Examples of request attributes that affect new IDs are 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 are collected into named into sets called roles. This allows requests to specify whole sets of new privileges, rather than one account or security group at a time. This simplifies the request process for users, who may not have a clear, technically accurate idea of what accounts or group memberships they require.
Normally, a role represents every system access required by a user who does a particular job. Roles may also represent functional groups, such as "network access" or "e-mail access."
Roles may be nested, to simplify definition of incrementally larger access privileges.
Requests for access may incorporate any combination of roles, template accounts and group memberships. They need not be purely role-based.

(2) ID-Synch does not require that users be classified into roles. While policy-based provisioning, where users' real access privileges are compared to those predicted by their role membership is technically possible with ID-Synch, Hitachi ID recognizes that most organizations will be unable to reliably and fully classify existing users into roles, so user/role classification and policy reconciliation is not an ID-Synch pre-requisite.

Search tags are attached to templates and roles in ID-Synch, to make them easier to find by end-users. Search tags include type and location. Resources such as templates, roles and managed groups also are associated with authorizers.

In order to ensure that the numbers of templates and roles are manageable, ID-Synch 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 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 ID-Synch to request systems access.
The request includes:
- Personal identifying information, 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.
ID-Synch workflow then tracks the request through approval.
The request is passed to agent 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 is done, a confirmation e-mail and welcome e-mail are sent to the manager, to forward to the new employee.