One of the discussion which pops up in many advisories is around the terms and related object to use in Identity and Access Management. This is directly related to the question which attributes to use where and which to import from HR.
My best bet and experience is that customers should look at three levels ob objects:
- Persons, e.g. the human being
- Identities, e.g. a virtual representation. There might be several identities for one person. Someone might be the manager of several companies within an organization. Or someone is working as an internal in an insurance and as external sales person. Or someone is a customer and an employee.
- Users or accounts, e.g. the representation in specific systems. There might be one or many accounts associated to an identity.
If you like that model, you should be somewhat careful when looking at vendor implementations. Many vendors have an oversymplified model which doesn't support the person out-of-the-box. That could lead to some complex customization requirements and more complex provisioning tasks to keep person-related attributes in sync which then have to be stored per identity.
Now let's look at the attributes:
- Some of them are associated with the person - the ones which don't change per identity, like name, surname, date of birth, or sex. And a unique identifier.
- Some of them are associated with the identity, like the office location, the eMail address (most likely - there might be a primary eMail address defined for the person). And an identity-specific identifier which could change, like an employee number per company.
- Finally there will be few attributes per account, which are specific to the systems.
- Identifying ones - how can you clearly identify someone?
- Describing ones - what do you need for the yellow pages?
- Authorization focused ones - which do influence authorization decision, e.g. are in fact sort of "entitlements"?