In a previous article, we discussed the main motivations behind the implementation of an authorization model and answered a first set of essential questions one should think about when setting up or redesigning a model.
Let’s continue here with a few additional questions – and answers – to explore the subject in greater depth.
How many roles do I need to create? How many roles should each user have?
It may be tempting to design a model that can handle every use case identified during a requirements collection phase. However, we should bear in mind that the model will have to live and evolve with new applications, new organizational units, etc.
There is no general rule on the number of roles to assign to each user. It is perfectly possible to build your model so that only one role is assigned per user, just as it is possible to assign several.
However, a compromise must be found between creating overly specific roles, which quickly fall into the “1 role for each user” pitfall, and creating overly general roles that do not bring much benefit and lead to over-allocation of rights.
Aiming for 80% of rights allocated via the role model and 20% of discretionary rights should already prove to be a good goal.
Bottom Up or Top Down, which method should I use?
There are two main methods that can be considered when creating an authorization model.
The “Bottom Up” approach starts from the existing rights and analyzes them to derive a model. For example, if all employees in the Accounting department have the same rights, then a role dedicated to this department can be created, which will contain the corresponding permissions. In this approach, data quality is a prerequisite for successful modeling, as wrongfully assigned rights would add noise to the model and reduce its relevance.
The “Top Down” approach starts by defining the theoretical authorization model, on which the necessary authorizations are then projected. For example, a role for the Accounting department can be created and include the permissions that business representatives deem necessary to accomplish their mission.
In practice, it is common to adopt an intermediate approach.
It is also recommended to work iteratively and to validate the approach on a pilot scope before generalizing it. The involvement of business representatives in the definition and validation of the roles plays a key role here.
What tools do I need?
The high volume of rights to be processed and the multiple iterations required imply the use of a tool that can either be sourced from the market or developed internally (Excel tables, database, scripts…). A prior analysis of the needs will ensure the adequacy of this tool.
In addition to the ability to create roles or rules for assigning rights, which is increasingly facilitated using algorithms that take advantage of machine learning, the chosen tool must facilitate the data quality cleaning phase before the actual modeling phase. It is also useful to have a simulation function that highlight the over- or under-allocations generated by the new model compared to current assignments.
In nominal mode, the IAM solutions on the market offer various possibilities that can used advantageously: role hierarchy, automatic ABAC-style allocations, suggested allocations, multiple role dimensions, etc. However, care must be taken not to fall for a model too complicated to use and administer.
If the choice of the IAM solution that will handle the model has already been made, it is necessary to ensure that this solution can handle all the desired complexity, even if it means making some simplifications or adjustments to the model.
Should I build my authorization model before, during, or after the implementation of my new IAM solution?
Generally speaking, it is preferable to design your authorization model before the implementation of a new IAM solution as the model can strongly influence the choice of the tool, depending on the adequacy of the technical possibilities and the functional expectations.
If data quality is satisfactory, the implementation of the model itself can then take place at the same time as the implementation of the IAM solution. If necessary, it is possible to plan a transition phase where the old tool can coexist with the new one. The perimeters ready for the transition to the new model can thus processed in the new tool, which gives more time for the migration of perimeters that require more work and time, although a migration schedule should be defined and closely monitored to avoid any drift that would prolong this situation for too long.
How much time should I plan?
The implementation of an authorization model is usually substantial project that requires the consideration of many factors and has a significant impact on all the stakeholders involved in the authorization environment (application managers, user support, business lines, etc.).
It is essential to take your time during the framing and design phase in order to ensure the success of your project.
The modeling phase can be long and tedious, especially if the volume is high in terms of the number of roles or the number of entities to be covered, or if the data quality is unsatisfactory and requires remediation.
Change management should not be neglected, given the impacts that are clearly visible to users. Training and a strong support phase are most of the time necessary once the model has been implemented.
What governance should I establish to bring my authorization model to life?
An authorization model is never static. The authorization catalog is updated as new applications are developed or decommissioned, the information system and business undergo evolutions, and reorganizations are carried out. Right from the design phase, it is necessary to reflect on the principles of current governance to avoid building a model that is too complex and impossible to maintain over time.
While the management of the model is often handled by a team dedicated to authorizations, the involvement of other stakeholders is essential, particularly on the part of the business, which must communicate any changes in its needs. The appointment of authorization correspondents within the business departments can be a way of encouraging this involvement.
Final words
The perfect implementation of an authorization model probably does not exist. Even if there is no major interdiction, finding a compromise between expectations and possibilities remains a delicate exercise that requires careful planning, preparation and monitoring.
In a nutshell, here are five good practices for the success of an authorization model redesign project:
- Allocate sufficient time for the project.
- Frame and steer the project with the greatest care to avoid deviations in terms of ambition, priorities, workloads or deadlines.
- Communicate with and involve the right IT and business contributors.
- Know when to say “no” if covering a need would risk deteriorating the ease of use or the maintainability too much.
- Do not neglect the change management with the end-users.
It is worth note that these good practices remain perfectly applicable to any IAM project in general!
