Identity Management Series – Role- and Rule-Basing Part 1: Introduction

At this point in the identity management process it is time to consider what access the company’s job functions should have to begin creating roles and rules. This is the first step in automating provisioning and de-provisioning. Even without automation, creating and managing the roles and rules will make manual provisioning (and auditing!) quite a bit faster and definitely more accurate.

It’s taken this long to get here for a few reasons:

1. The initial user cleanups provided information on who’s who in the organization, and ensured that unused accounts were eliminated – no sense in role-basing users who aren’t around anymore, right?
2. The secondary user cleanups hopefully gave some ideas of what access users have, and provided the baseline data to do the discovery work that we’ll discuss this month.
3. The HR work set expectations of what’s available in the HR system, and also allowed the IDM team and the HR administrators to build a relationship and a common vocabulary. This will help the IDM team to ask questions in the right way, and the HR team to know how to interpret and answer those questions.

In the event the above exercises are still ongoing, I suggest you complete those as much as possible before starting on this one as they build the foundation for continued success.

Ready for roles and rules? Let’s get started!

But first, a little technical accuracy: Enterprise Roles and IT Roles

There are two different levels of roles – enterprise roles and IT roles.

An enterprise role is a high-level entity, like “accounts payable clerk.” The enterprise role generally corresponds to the person’s job title and is a larger bucket which contains multiple IT roles. However, since the enterprise role is a construct of identity management, it may not correspond exactly to a job code in the HR system. For example, the HR system may have a job code for “finance analyst,” which might contain the enterprise roles “accounts payable clerk” and “accounts receivable clerk.” More on this later.

An IT role is the set of permissions assigned to a particular enterprise role on a specific system. So using our previous example, the enterprise role called “accounts payable clerk” might contain all of the following IT roles:

• Email role of “standard email access”
• Internet role of “internet access denied”
• Financial system role of “accounts payable clerk”

In many cases, there will only be one IT role on each system that corresponds to an enterprise role, but that’s not always true. Similarly, multiple enterprise roles can contain the same IT role.

For the purposes of this blog, it’s not necessary to be quite so technically accurate. I will generally use the term “role” to mean enterprise role, and “permissions” to refer to whatever IT roles may apply. Where better accuracy is needed, I’ll be specific.

Roles vs. Rules

Rules transcend roles and either help the decision process of who gets what, or they provide caveats. For example:

• All roles in the IT department get “standard email access” except VPs, who get “executive email access.”
• The following Accounts Payable permissions may not be granted if the user is already assigned Accounts Receivable permissions
• Anyone above manager is entitled to “internet access permitted.”

The bulk of the work is actually in identifying the roles, so that will be the focus of this blog. Rules generally come after the fact, to plug holes and normalize permissions (i.e., they’re a higher level of maturity).

Approach

As with everything else we’ve done to date, this exercise is largely about brute-force effort coupled with some intelligent data analysis. At the end of the day the steps are as follows:

• Identify the enterprise roles (based on a combination of HR data)
• Design and test the IT roles/rules needed by each enterprise role
• Implement new IT roles (or full enterprise roles), and clean up old access

We’ll continue in the next segment by identifying enterprise roles.