Identity Management Series – Role- and Rule-Basing Part 3: Designing and Testing IT Roles

Now that enterprise roles have been identified and prioritized, it’s time to tackle IT roles, and figuring out IT roles is where the rubber meets the road. Chances are, neither the department heads nor the HR team can help on this one. It’s up to the identity management team and business “power users” to determine this based on brute-force analysis and tribal systems knowledge.

Developing a Strategy: Depth vs. Breadth

As with enterprise roles (and departments, for that matter), IT roles may require some prioritization, because:

Each enterprise role can have many (possibly dozens) of IT roles.

This means there are a LOT of roles to define, document, test and implement, which raises an important question: is it better to spend a lot of time on each enterprise role, identifying it end-to-end before moving on (depth), or is it better to tackle the priority IT roles in each enterprise role, and touch each enterprise role multiple times (breadth)?

There is no right or wrong answer to this question and in fact the answer could be different for different enterprise roles.

The strategy is ultimately driven by whatever is going on in the organization – such as complaints that the access services team is taking too long to grant access (or making too many mistakes), an impending audit, or a process improvement project. It also makes sense to use this opportunity to successfully address a current challenge to curry favor for subsequent steps.

The argument for breadth is security – go for the sensitive/complex access first across all systems to stop the need for copying access and reduce or eliminate the mistakes when implementing access. Many companies employ a “model ID” system: “Jane needs the same access as John.” This is dangerous if John actually has more (or different) access than Jane needs – it’s bad for security. Interestingly, it can also be bad for customer service if John’s access doesn’t give Jane everything she needs.

The argument for depth is customer service – fill out each enterprise role in its entirety before rolling it out to the end-users to avoid confusion. This isn’t about implementing the roles – it’s about end-users requesting them. If each enterprise role is only partially filled out with its IT roles, the communication to the end-user might look something like this: “Going forward, you no longer need to request access for email, internet, shared folders, and UNIX applications because these are now included in your role. But you do need to request access for mainframe and Windows applications.” How many users will understand this?? None! So either they will not submit the correct individual requests, leading to missing access, or they submit requests that they didn’t need to submit, causing duplication of work for the access services team. In this case, not only has the workload for the access services team not been alleviated, but it’s caused a customer service nightmare, too.

In a perfect situation, each enterprise role is fully fleshed out with all of its IT roles, enabling a one-time cutover of all users in that role with flawless communications and an easy transition to the new process for requests. More often, however, the situation will be a bit less “perfect” and require a stepped or phased approach. The more planned, mapped, and understood the process, the more effective the communication and the less friction experienced in the process.

Once the strategy is mapped out and commitment to communication made, it’s time to begin defining roles.

Discovery: as-is access

The first step in defining IT role(s) is determining the as-is permissions for the members.

For any given system, obtain a report that specifies what each user in a particular enterprise role has. Theoretically, all users in the same enterprise role should have the exact same access on any given system. Practically, they probably don’t. Newer users may have less access than they should, while users that have been around for a long time may have accumulated a bunch of permissions that they should no longer have.

It’s also important to verify the enterprise role at this stage – if the group of users that should have had the same access seem to have two different groupings of permissions, maybe the original assumption was wrong and the users should actually belong to two different enterprise roles. Validate this with the department head – not by just saying that some users have different access, but by naming names: “John and Mary have these extra three permissions that the rest of the team doesn’t have. Do they do something special/different that the others don’t do as part of their job, or is this access a relic because they both held the same prior job?” Whereas a department head may not think anything of the extra permissions, if they’re put in the context of the specific team members, it will resonate, and they should be able to say exactly why that access exists. If the users do perform an additional job function, an extra enterprise role should be added to the list – this is where normalizing is helpful (e.g., finance analyst, senior finance analyst). If the users don’t perform any additional job functions, be sure that that access is removed from their accounts – more on this in part 4.

The discovery process is a great place to engage someone with scripting skills. There’s nothing worse than collating and analyzing data by hand, or trying to run manual reports. A decent scripter can significantly decrease the discovery workload, and it’s likely that the effort put into creating the scripts will come in handy later as well – when the identity management system needs to be trained how to obtain the same data.

Design: to-be access

The next step is to identify what permissions the given group of users *should* have. For some systems, this is very simple. Take internet access for example – either it’s allowed, or it’s not. Email might have a couple tiers, like standard access and executive access (with more mailbox space). A lot of systems have a small number of canned permissions that can’t be modified, like read only, update, and administrator. When these types of systems come up, rejoice in the ease of defining the IT roles.

Then there are the systems with a TON of permissions – relational databases and mainframes are notorious for this. This is where that power user will really come in handy – they hopefully know how permissions map to access, or at least they know enough about the system that they can help with the business side of that mapping if they get some help with the permissions side from an access administrator.

Coming up with the right IT roles on these systems can take much iteration. Remember to begin with the as-is access and eliminate from there, rather than trying to build the roles from scratch (although some people’s access may be so bad that a full rebuild is necessary).

There’s also another element here: level of detail.

Some IT roles will not be permissions, per se. Rather, they will be an indication of ownership – like “cost center manager” or “xyz data owner.” In cases like these, smart design decisions need to be made to ensure that the number of roles does not explode.

For example, a large organization may have literally thousands of cost centers, and they change all the time for administrative reasons that only the finance people can explain. Having a separate IT role for each cost center would be a maintenance nightmare, but having just a single role called “cost center manager” is too high-level. In this case, the right middle ground needs to be determined – maybe each department, business unit, or division has its own separate role. But such a middle ground will require some workflow design to get additional information on-the-fly when it’s needed. We’ll talk about this more next month when we talk about hierarchies and vacancy management.

Testing

In the previous article, I mentioned that department heads can get very uncomfortable about changing an entire team’s access, for fear of interrupting business function. In addition to building a good relationship with them, another way to alleviate those fears is by thoroughly testing the new IT roles with one or two users (in a test environment if possible) prior to rolling out the changes to the entire team.

This might seem obvious, but it can actually be pretty challenging to get someone to remember what all they do on a system at any given time. Special care needs to be taken when working with users that have periodic tasks – ones that only occur monthly, quarterly, semi-annually, or annually. Typically, periodic tasks are time-sensitive and critical to the organization (e.g., finance people who have to “close the books” on time) – that is not a good time for a user to find out that they no longer have the right access to do their job.

Non-access roles

Remember that roles and rules can apply to non-access items as well – like equipment and facilities. Although provisioning of these things will never be automated, having a quick and easy reference for the people that provide these services will make their jobs easier and allow them to provide better customer service. Consider defining IT roles for computer hardware, computer software, communication devices (phones, pagers, etc.), facilities (cube vs. office), badge access, and so on.

Other resistance

When designing enterprise roles, everyone is willing to play along because it’s very esoteric. No one thinks twice about categorizing who does what. In fact, other groups may find their own uses for the information, since you’re putting all the time and effort into gathering it for them anyway. 🙂

When designing IT roles, unless the access management function is already highly centralized, some (possibly significant) resistance may be encountered – mostly by the people who administer the access today. If they are completely buried in work, the thought of automating some of it will be welcomed. If granting access is all they do, they will likely interpret the automation of their job as a pending pink slip for them. Of course they won’t put it this way, but when you hear, “my application can’t be role-based – there are too many special circumstances that need analysis” or simply, “automation won’t work with my system” what they’re really saying is, “I think your project is a threat to my job and I don’t want to participate.”

This is definitely a problem, but not one that the identity management team should be saddled with. Early in the process, it’s easy enough to skip these groups and keep going – there are plenty of other systems and applications to role-base, so the luxury of deferring the “problem children” certainly exists. But for those that can’t/can no longer be deferred, escalate the issue to management and let them deal with it.

Next, we’ll discuss documenting the roles and getting approval for their use.