What if I could show you a way that would reduce the size and complexity of managing
user identities by two or even three orders of magnitude? It would cut down on cost.
It would make the operation more efficient. And it would make it more secure because it
was more simple. And as I mentioned in other videos, complexity is the enemy of security.
So let's think about managing these identities without user roles and then with user roles,
and I'll show you the advantages of using roles. So what we think about first is we've got a bunch
of users here who need access to applications. Simplistically, it sounds like this: I'm going
to give this guy access here and here and I give this guy this access-- and that's all
they really need. That's what it seems like. But in fact, it's more complicated than that.
What happens is inside of these applications, there may be individual permissions that
are necessary. For instance, it could be an administrator access, it could be read-only
access. It could be read/write access. There could be a lot of different underlying permissions
that need to be granted. So, in fact, instead of this gross level of permissions that I'm giving,
in fact, what I really need to do is give this guy these access rights and this guy needs these.
And this guy needs these. And it continues. Before long, you end up with a spaghetti mess
that you've got to manage. Every user is a one off. Every user is unique. Every user is complex.
And when I have to unroll all of these access rights, when the user leaves the organization,
it gets even more complicated and more costly and more difficult to accomplish.
So, let's look at a different approach where instead of doing individual user-to-permission
or entitlement accesses and doing those mappings. I'm going to introduce another concept. Where
now in the middle, I'm going to have this idea of user roles. So I'm going to create a set of roles
at a business--I'll call these business roles. For instance, there's a role-- let's it that say this
is a hospital. So we have a doctor, we might have a nurse, we might have a lab technician. Those
are the business roles. So business roles or a collection of users. I'm also going to create
a second abstraction of application roles, and in this case, these are going to be high-level
functions that need to be performed. So maybe the high-level function is admit a patient,
or discharge a patient, or update a patient record. So those are high-level things. In fact,
those high-level features might involve multiple underlying permissions in different applications.
So now you see it gets a lot more complicated. But what I'm trying to do is reduce that complexity.
So once I've created these two different tiers of roles: business roles-- a collection of users,
application roles-- a collection of entitlements or access rights, then all I have to do is come
back and say, "Okay, to admit a patient, what do I need to be able to do?" Well, I need to be able to
have access to these two features along with this one, which is actually in a different application.
Imagine in a complex organization, there might be six or seven applications that need to be
involved in performing a high-level function. So to discharge a patient, maybe I need these and to
update a patient record, I need these. Now I've mapped out the application entitlements. Up here,
all I need to do is say "Which ones of these people are doctors?" Okay, here are my doctors,
here are my nurses. And here's my lab tech. Now I've created the collection of business roles
and those users, the collection of application entitlements, and all I have to do is connect the
dots. I'm just going to say: Doctors can admit patients, discharge patients and update patient
records. Nurses cannot admit and discharge, but they can update records and lab techs,
when they get in the lab results, can update patient records. That's all I have to do. The
beauty of this, then, is the flexibility that happens over time. Let's say later, I need to
add in a new entitlement here and this now is required any time I update a patient record.
Then, all I have to do is add in this and the update capability now involves that entitlement
and all the people who have the update capability-- in this case, it's all of
these users, now have this new capability. And if later I decide, for whatever reason, I'm not going
to allow nurses to perform a particular function, I just take that function out of the nurse role,
and all the nurses now lose that capability. Or, add something in, all of those users
instantly gain that capability. By separating these two different layers, I don't end up with
the spaghetti. I end up with something that is much simpler to manage. And it feels like now,
instead of managing what might be 5000 users, it feels like a managing three users, if I've
got three roles. So I've taken the magnitude of the problem and reduced it dramatically.
So let's think about what are some of the best practices then in role management if we want
to carry this through. And there's a number of things you can do here.
For instance, don't make the mistake of letting the perfect become the enemy of the good. In doing
so, I've seen organizations that try to define this in a perfect way that will meet all the
needs for all time. And the fact of the matter is, we don't need to do that. It needs to be flexible.
It will change over time. One organization I worked with took a year to define their roles.
That was a delay on the process because they were letting the perfect become the enemy of the good.
The second best practice is related to that first. Aim for more like an 80/20 split.
Try to cover your role entitlements and accesses with about 80% of the cases with something like
this, and then let the other 20% be exceptions and we can handle them as one offs more like this. But
I've still reduced the problem space dramatically. Other things I can look at is role design or role
engineering, where I sit down, as I've done here, kind of as a tabletop exercise and envision how
these roles should be. I can envision that these are the different types of users. These are the
different access rights, and we do that kind of an exercise. This is more of a top-down approach.
The bottom-up approach is more of a role discovery process, and there are tools that will allow you
to go out and see all of the entitlements that a user has and what function they perform. And
then you can go through and see all of these users who are peers seem to have the same access
rights. So let's create a role around that. And therefore, we're essentially discovering the roles
that already exist in the organization that just have not been explicitly stated. I would actually
recommend using both of those: the top-down and the bottom-up. The design and the engineering,
and let them meet in the middle. And then we apply some of these other principle principles that I've
talked about. In addition to these, we also should use good tools that allow us to do this
discovery. And there are enterprise-class identity governance tools that will allow to do this,
allow you to manage it, and manage this over time. As these roles need to change, we'll need to make
those kind of changes. And then, finally, the thing that I've illustrated here-- and that is use
multiple tiers of roles. Because if we try to use a single roll structure, we'll overload it. Here,
I separated out the groups of users from their entitlements. That way I have more separation.
I can change the entitlements without changing the users. I can change the organization of
users without having to change their underlying entitlements. That gives me the maximum level of
flexibility and it keeps me from that sort of analysis paralysis that I mentioned the other
organization I talked about hit. So you can see, I hope with this, that I can take a very
complex space, reduce it to a much more manageable space. Therefore, with this more manageable space,
it's cheaper, it's more efficient, and I'll argue even more secure. Because complexity
is the enemy of security. And this is simpler. Thanks for watching. Please remember to like
this video and subscribe to this channel so we can continue to bring you content that matters to you.