Considerations in your IAAM journey - Part II: Role Based Access Control the Unicorn of IAAM…or is it?

Before you read, catch up on Part 0: An IAAM system overview and Part 1: Who does what.

Role based access control (RBAC) is what we’re all aiming for in our IAAM solutions. Automated RBAC with your IAAM solution is really the nirvana of IAAM. That is, when you get the onboarding data from your systems (hopefully you’ve established who owns the input of this), your IAAM system will be smart enough to⁠—using those pieces of data it receives from the source system⁠—automatically provision the new employee, contractor, student, etc. with the right access to the right applications that she or he needs to do their job. That’s the theory that I’ve personally never seen in production. It’s really kind of impossible, frankly.

I’ve had to manage 10’s of thousands of applications in some of my CXO jobs. There’s no way I could⁠—based upon the relative skinniness of the source data⁠—get a new person all the applications she/he needed to do their job, but I could get close. I think in IAAM your target has to be that 80% that you hear about with the 80/20 rule. If you can get a new person 80% of the applications needed to do their job on day one, automatically, then you are in tremendous shape!

So, a major element in designing your RBAC is deciding which applications you should, not could, provision to your population. In an integrated suite of IAAM products, like Imprivata’s, we’d use the data from Imprivata OneSign to figure out what applications folks have been using. Then, you’d identify which digital ID belonged to which job description (or some other meta data coming from your source system).

I like to use the example of an ICU nurse. Give me the digital ID of 6-10 ICU nurses and then I can tell you the applications those nurses used over a period of time, using the OneSign data, and voila! You now know the group of applications the job description of “ICU Nurse” needs to perform their duties. The next time an ICU Nurse is onboarded through your system they’ll automatically be given that group of applications.

If you’ve had OneSign deployed for a time, or some other methodology for tracking which applications a digital ID has used over a period of time, you can do this with almost any entity you onboard. This cuts out the sometime painful process of starting upstream with the position/job descriptions and trying to rationalize those and then move on to the applications for those positions. This, from what I’ve seen, is where most identity governance projects get slowed down and ultimately fail. Instead of letting that happen, get the biggest bang for your buck as fast as you can.

One way to get that bang for the buck is to establish a set of “birthright” applications that everyone that comes onboard gets. By doing that, at minimum you’re capturing the digital IDs as they come onboard your organization. That “birthright” basket usually consists of an AD account, email, and the HR system.  When Imprivata deploys our solution, Imprivata Identity Governance (IDG), we take much the same approach so that we can bring you value that much sooner. We’ll generally do that birthright basket, plus your EHR, plus another application you feel is important to your business. By doing this, we can generally get an IDG program up and running within five to six months, rather than the years some other programs take. That’s the kind of timing you can use to measure how well your project is going.

This is all well and good to see quick value for your implementation, but there’s some really good reasons you won’t want to stop there. Or you might want to take a parallel path of managing applications within your IDG system, but not necessarily auto provisioning those applications in a RBAC scenario.

But, that’s for the next one in this series: What should I manage in my IDG system?