Defining Roles: The Top-Down Process in Practice

May 12, 2015
Roles Definition- Part I

Our path to well-defined roles begins with the system owner who evaluates the applications and which users should have access. When he determines that a group does not belong, for example, the accounting folks should not be on a particular application or system, he removes them…All of them. This first pass eliminates users who should not have access at the functional or departmental level.

Once the department-level cleanup has been completed, our intrepid team of IdM analysts meets with each department manager and together they review application access by user function. During this conversation, we learn that Ken and Jessica have the same job function and both have access to a range of applications. Ken uses a few apps, and so does Jessica; however, Ken should not be working in Oracle Financials anymore - his access should look exactly like Jessica’s. So, we remove Ken’s access to Oracle Financials, which “cleans up the deltas” for users with the same job function.

At this point, we haven't built any roles yet, just cleaned up the applications. Ken and Jessica are in the same department and have the same access because of our clean-up. This makes it much easier to define roles and determine what applications a person should have access to and at what level. Now that all users in the same function also have the exact same level of access, we can start building the roles for our Identity and Access Management solution.

Read Part 2: Defining Roles for IAM – From the Bottom Up

More News