A user is a natural person who has a contractual relationship with the company and who can be given access to IT resources.
Mistake No. 1: Confusing the HRIS with the user repository
"Can you give me a list of all the employees please?". This is the request that the IT department sends to the HR department for a list of users in the company.
In this request, there are 2 problems: the request is addressed to the HR department and we're talking about "employees".
Why is this a problem? Because this HR repository is only partial. HR departments generally manage internal employees, those who are part of a recruitment process and who have a pay slip.
By requesting information from the HR department, you create a blind spot for a sometimes significant number of users: temporary staff, external service providers, consultants, etc.
Users (in the IS sense of the term) are not just employees: temporary staff or freelancers, for example, have a contractual relationship with the company and need regular access to internal applications. We therefore need to deal with these "HR edge" categories of users, who are absent from the HRIS.
Mistake #2: using an identity repository as a user repository
In the IT department, the question is: how can we have a list of all HR and non-HR users currently present in the company?
And then the idea sprang up like a victory cry: "we already have a place where we store all the users! It's the AD!"
Quite apart from the fact that shouting this phrase confuses"users" (physical persons) with "identities" (access accounts), it's very dangerous to use a technical tool like AD to centralize users: if you want to use this repository to determine the legitimacy of user authorizations, it's a bit like a snake biting its own tail.
That's not whatActive Directory is for, and you mustn't twist its original use to fit all users into it. What about, for example, a temporary worker who you enter into AD to declare his arrival, but who doesn't need an AD account?
The AD is not an HR source, and even less a "golden source" (it contains many system accounts that should be excluded to have a clean list).
Finally, it is generally not an "open" database: it is difficult to synchronize or import other HR data sources that may exist within the company.
What is a user repository?
A user repository is a list containing the administrative data of all users who have a contractual relationship with the company.
It must be :
- Always up to date.
- Multi-source (data from HRIS (es) and from temporary workers' declarations from managers, for example).
- Compatible with several import technologies (csv, bdd etc...)
- Contain all the attributes needed to arbitrate on authorizations: the most obvious are date of arrival and date of departure (to know whether he is authorized to have authorizations or not), then function, department... to define more precisely which authorizations (access rights...) he is authorized to have.
How do you build a user repository?
- Identify information sources
The first source of information is generally the HRIS: this is the "golden source" that contains contractual information and is therefore considered reliable.
Other users are often known to managers: a temporary worker joining a team is declared by the manager, who knows all the information needed to create the user's accounts: arrival date, departure date, function, etc. To simplify the manager's work, it's best to give him a way of transmitting the data in a structured way. If they have to send an e-mail or create a ticket, they'll be perplexed: what information do they need to communicate? What do they need from IT to create access?
It's better to give them a form to fill in, in which all the information can be entered, as this will limit the back-and-forth between the IT department and the manager.
- Standardize input
You don't need to have 50 pieces of information about a user to be able to create his or her accesses, so don't ask too much of HRIS or managers in the form you make available to them.
What's important is to be able to restrict yourself to the minimum necessary, and to adapt the information requested: the fields to be entered for a temporary worker or freelancer are not the same as those for an employee arriving on a permanent contract.
It's also important to provide multiple choices for data entry, rather than free-form fields, to standardize information and create your own repository.
- Automate imports
This is the cornerstone of building a repository: automation. If the repository is updated manually, these updates will be cumbersome and of uncertain regularity. Imports from HR sources must be automated.
- Handling exceptions
A final point is the handling of anomalies or exceptions: duplicates, true homonyms, multi-contracts, changes of contract (a temporary worker becoming a permanent employee...). These points need to be dealt with in the repository: either upstream in the HRIS, or directly in the repository to maintain its quality.
A single user repository is the foundation for HR and, above all, IT. It's impossible to build a clean information system when you don't know who's there, who's coming, who's leaving and who's changing jobs.
HR has to do double entry for itself and for the IT departments, which adds to their workload. There can be oversights, and the same goes for IT.
HR sources are multiple, and this is a challenge to be taken into account. That's why it's not really feasible to create a repository by hand, as it's constantly changing. As soon as it's done, it's already obsolete.
That's why an IAM tool is perfectly suited to this kind of time-consuming and crucial exercise.
With a reliable, up-to-date user repository, you can build your authorization management strategy. Security for your company.
