Hitachi ID Identity Manager attaches access rights not to sets of users but to types of relationships, using user classes. This is essential to privacy protection, as illustrated by the following example:

  • Consider a very sensitive profile attribute -- scheduled termination date. This may be mundane as it applies to contractors, representing the end of an engagement. It may also be very sensitive, indicating when an employee is due to be terminated.
  • Who can access this data depends on relationships. For example, HR users should be able to access this data for all users -- except themselves. Managers should be able to access this data for their direct and indirect subordinates, but not themselves or other people who do not report to them.
  • The Identity Manager access control model allows organizations to define types of relationships, such as "recipient in HR, recipient and requester are not the same person." or "recipient reports to requester."
  • Access rights are linked to types of relationships, as above.
  • The search engine provided through Identity Manager respects these access rights, to protect against data leakage. For example, a manager might search for all users who are scheduled for near-term termination and will only see those who report to him -- but not himself or others.

Using relationships makes it easy to define various user support models. For example, users in a country-specific help desk can reset passwords for other users in the same country, or managers in some regions may be allowed to reset passwords for their direct (or indirect) reports.

Using this access control model makes it practical to manage highly sensitive or privacy-related data using the Identity Manager request portal and approvals workflow. Personal data such as date of birth, social security number, student or employee number, enrollment and deactivation dates, healthcare classification and more are all safe to manage using Identity Manager.

Hitachi ID Systems higher education customers leverage this security model to allow users to control what, if any, of their profile information is published to members of the campus community:

  1. Some profiles and attributes may be made visible to certain groups. For example, all user profiles for students should be visible to the admissions office; all user profiles for staff should be visible to HR, etc.
  2. Some profile attributes may be made visible within their department (requester and recipient share a department affiliation).
  3. Some profile attributes may be visible only if the requester has set another attribute that acts as a gatekeeper. For example, requester can see recipient's phone number if recipient.phone-visible is set to true, etc.

Note that access controls in Identity Manager extend even into search results. For example, a competitor IAM system might not display a user's age or contact information to another user, but might allow for search on these or other attributes, whereby the searcher could infer attribute values. The Identity Manager access control system protects against this type of search-and-infer attack against user privacy.