You're listening to the identity of the center podcast, this is the show that talks about identity and access management and making sure you know who has access to what let's get started. Welcome to the identity of the center podcast, I'm Jeff and that's Jim. Hmm. Hey, Jeff, how's it going? That's a bad yourself. Good. Good, you know, I feel like a big complainer. We always one of our favorite inside jokes is, oh, you bet sounds like a personal problem. Well, I've got good weather
problems, right? I'm I'm sitting here complaining, because his mid-40s, and the rain has finally stopped. It has been rainy and, and cool, and have the United. It's is under some kind of blizzard warning or digging out us know. I know you're in Chicago, you haven't had the best, whether it has been difficult. So, you know, I think for a large swath of the United States over the last several weeks and yeah, Chicago has been pretty snowy.
I think. I think we're close to setting a record for like number of consecutive days with, with measurable snowfall at least in the Chicago area, which is where I'm at. So, you know, and then obviously our friends down in Texas are certainly having some struggles with Power issues. So for those who are listening, it is Friday, February, 19th as Jim and I are sitting here kind of talking about this. So if you want to look back in the and The Archives of the internet, right?
You can probably kind of figure out what was going on in the world back then but yeah it the weather has been challenging but I am hopeful. I'm seeing above freezing temperatures on the radar and on the forecast as soon as maybe even this weekend or maybe next week, always plan a trip down to Cancún. I don't think anybody will protest outside for your house. Old, man. Oh, was that, that's not what you meant by the power issues, in Texas. Oh, you meant something else.
Sorry we usually don't go there on this show. We usually don't get political but yes, that that was not a good look for a certain individual and the the Texas political Spectrum, which is put that way. So what I'm going to talk about today I'd like to talk about role-based access control and all things associated. What do you think of that? I think that as a gigantic can of worms and I think we you should do it because roles are something that we hear a lot from our clients as something
that they want to get into. And it can be a little bit confusing sometimes because there's a lot of, you know, different competing directions that maybe things want to go in from a role perspective, right? You've got role-based Access Control, you've got attribute based Access Control, you've got policy based Access Control. There's a lot of acronyms and we're going to get into that today.
So I think what we want to kind of start off with the Is, you know, this is our thoughts and how you get started to eat this elephant, one bite at a time because it is, certainly a tends to be a rather large project for a lot of organizations. And a lot of times you are starting from, maybe not the best from a data quality perspective. And you may have to, you know, have a lot of kind of push and pull to kind of get things up hill.
Yeah, I mean it's what complication topic the most for me is that there's not a industry standard definition like we, if you ask somebody who's As in, there's a I am practitioner. What is multi-factor authentication mean? You get the same answer every time. You ask somebody what a role is you get a different answer every time and that's because a couple things from an organizational standpoint.
We talk about roles differently application, even within an organization, you might have application teams talking about roles within their applications and then you talk to the. I am team or the active directory Gene and they're talking about roles that. Totally different level.
And then from an authentication, side of the house or this is an identity management side of the house, whether that you're using roles to drive provisioning to apps, or you're interpreting those roles at the time of authentication to confer access.
And I think we had a an episode one of our original episodes back when we used to do a lot of Jeff Jeff and Jim episodes where we talked about kind of some of the most Confusing terms and identity access management and roles was probably number one. Yeah, that that highly liberal use of the word roles. You know, can certainly complicate the way that things get defined. So we're going to dive into it here and I think it's probably important before we get too far
along. Here is really when we're going to talk about role-based access control or our back is that we're really focusing on the provisioning side of things not necessarily the authentication side of things because like There are sometimes some definition of roles being assigned at the authentication level. What we're really talking about provisioning and really more authorizations. So why don't we dive right into
it? And why don't we start with what is a rule Jim Murray. And so I'd say like if we're to give it a dictionary definition, it's really the collection of one or more entitlements or groups, bundled together and assigned to one or more. People in order to confer access to a system. So there's a couple elements there one is that it's a grouping of access rights and it's assigned to people or it could be to non-human account. So maybe people isn't the right term, it's identities, but it
confers access. Right? So the point of putting a roll together is to bundle access and so when we talk about Even Frameworks. We look at that. It has an access pattern. Yes, or no, right. That's an important piece of. There's not an access pattern around a roll. Then there's not much sense in developing a roll.
Yeah. And I think one of the ways that I've heard it described in the past that I kind of like it really, it maybe oversimplifies it, but I think it's okay for this conversation is think of roles as a bundle of sticks. Right? Each stick kind of has its own, maybe unique properties, and you might pick up and have different bundles of sticks. And you might have just one
stick in your bundle, right? But, you know, each of those things, could essentially be an entitlement and that bundle ends up becoming what we kind of refer to commonly as a roll. So now that we kind of set the stage of what is a roll, why would someone who want to go down this? This hellscape that it's sometimes be of setting up access rules for their organization.
When I think about roles, I generally, think of, you know, the kind of the framework that You think about this is there's two types of roles and we're going to use some terms, right? And some of these terms are used or not used by different vendors organizations, but the two main ones for me, our Birthright roles and requestable roles. And when you think about Birthright rolls, the idea is that you can automatically assign access to a person based on something about them.
Some attribute about that person they're an employee. They work for a certain department or they work in a certain Certain location. Usually this is going to be an attribute that is stored on their profile, whether that's in the HR System or something. That's maintained outside, the HR System but it's data-driven that they are all this classification and because of that they should have this access and that whole process can be automated.
However, request will roles are something that we don't have that that driver of some attribute. That's going to say whether or not the person should have access and is ultimately a bundle that bundle Sticks that we want to make available and it's for convenience sake. And so having that bundle of sticks. Now, somebody in ideally in the business is going to have to either request or approve or both that access for a person or for like we said a non-person identity.
You know the more you try to narrow size these definitions the more it just sounds like a bunch of words so I'm probably going to stick to more the simple definition but If you have a request for roles that bundle of sticks that you're going to give to a person, you're doing it in a way that the business can understand what that that bundle is our. You're either going to tie it back to some job function or
maybe to a job overall. Yeah, I think you know, maybe let's stick with the bundle of sticks concept here is, you know, if you think you're on you're walking around and you know whatever Village and when you're born you're given a bundle of sticks, right? That's just what you get, that's
a Birthright roll. It could be, you know, whatever that little sticks might look like and then maybe you go to, you know, the shop inside your village and you see a bunch of different bundles of sticks sitting behind the counter and you say to the shopkeeper. Hey, I want that bundle of sticks, right? So that would be more of the
requestable role. So maybe we can, you know, that maybe a little again, little bit too simple, but I kind of like it, at least for the purpose of this conversation. And, you know, it's important to mention the business look like he just did because it's Very difficult to do rolls and it's compounded. If you do not have the business involvement as part of the definition of what those roles look like, who can have them, who's going to approve them, right? How do you make things that are?
You know, appropriate for the business to understand because really at the end of the day, it's the businesses data and it's the businesses rolls it. And by extension, the identity access management team or technologies that are associated with that team are there to kind of Port the business and to make them make help them make more informed decisions. So it's important to understand that this is not an easy task, it is something that a lot of organizations struggle with.
They are usually year long or multi-year projects depending on how complex the access Matrix might look like within an organization. So, that's something to certainly consider as part of this is not easy. And that's okay, right? We mentioned, it's an elephant. You got to start eating, that elephant, one bite at a time. And this is this, these are some ideas. On how we want to get started on that contrast.
What that, what we just talked about with the organization that doesn't have roles, and they really struggle to get identity and access management into a good place, where the business can make informed decisions about who should have access to what, and they're looking at, you know, a list of groups are, you know, entitlements that are not put in plain English and not
tied back to business functions. For example, it's hard for them to decide who should get The access and then part of doing role management. Effectively is reviewing roles reviewing the access that people have on a periodic basis and if you're reviewing and you don't understand, you're probably not going to start removing access that you don't understand what it actually is and since we have your employee, not have the access that they need to perform their job.
So what ends up happening is that people rubber-stamp during the access Requests and reviews. So that's a place that roles can be. Very valuable, especially roles of gun. Right? Are you name them in a way? That makes sense. You write descriptions descriptions should tie back to what, you know, what access this role confers and you have owners of those roles so they can do roll reviews effectively.
So we've talked a little bit about our back or role-based Access Control. What does that mean? I think we For my money, when I talk about our back, it's the overall process of role management and how roles Drive the access that people get. So it's, it's looking at it from kind of a 360-degree perspective from how you get the rolls, how those roles help Drive access, how people interact with those roles. Again.
Like we've been talking about its kind of we touched on a lot of the different aspects of what makes a good role and it's something Thing that the business can understand, they can assign to people. And then those roles really become the basis. For the assignment of who gets access to what what would you add to that? You pretty much covered everything. You know I think if we go back to the bundle of sticks, role-based access control is, how do you create that bundle of
sticks, right? Which sticks are going to go into the bundle and does that bundle make sense? Do the owners of those individual sticks agree to become part of that bundle, right? And this is an area that that does take some finesse. This is more of a this is not necessarily technology problem.
This is more of a business process and trying to make sure that you convert the Active Directory Group that is labeled, you know, I T Dash PR D Dash, you know, a PP 004, you know, translates into something that actually makes sense. Oh right, that is the server or the application that controls the cafeteria. You. All right. So being able to make that translation and put that in front of people to have them
make those informed decisions. As we're really role-based access control and the Frameworks that go around it. I think make the most sense, I know we've also talked a little about a back or attribute based Access Control. How is that different from role-based Access Control? One of the things we said early on is, we're going to focus more on the provisioning side. And so I think we're talking about a back. In provisioning, we're talking a
lot about that. Birthrate automation of access accounts where I really see a back as where I see organizations using it as more on the authentication side. In other words, applications are being given rather than here's the access to person has a given profile information about a person with a lot of attributes and that the applications that can then interpret those attributes. However, they see fit in other words. The the decision point is that the application in terms of what
access those attributes confer. So very much like, you know, policy-driven again, kind of on the provisioning side of the house I think is really the interpretation of those attributes for automating the provisioning of access. Yeah, I think you hit it right there. You know sometimes a back is also known as P back or policy based Access Control. It's more of a runtime or Time
assignment of access. What's interesting to me is that it really kind of layers on top potentially of role-based Access Control right if you're driving data into the application?
Say, you know, here is Jeff and he's in Chicago that attribute of me being in Chicago. May actually map back to a role within the application, but it's not being granted to me ahead of time because the application is determining determining, you know, in a more real time based on the With indication the authorization streams, what I should have access to versus something that I've always had access to, which might be, you know, that role that kind of sits behind it.
I think, what's similar in both Concepts is that you have centralized management of that data, which is going to ultimately Drive the access in role-based. You're determining what data drives people to be in what roles and then you're telling the applications put people in these roles Versus you just handing the data to the application and the application is deciding what access that person should have based on those roles and so.
But in both cases, you're centralizing that authorization data there is a scenario also where applications are completely doing their own authorization Management Group managing, enrollment or whatever you want to call. You want to call it or they call it. What I think is, that's usually a very early. Maturity step. That's where you have a lot of applications that kind of grown up on their own.
And maybe you've done kind of a level 1 integration, where you're doing single sign-on between the application. But you haven't really started to pull the authorization out of apps and manage it at least manage the data centrally. And so, that's kind of a, you know, step two or Phase 2 in kind of centralized in your applications, is that centralized management of offer. Relation.
But Jeff, my could I mean one thing I wanted to do earlier was my little rant as in my rent, goes back to when we talk about, what is our back, right? And kind of, how do you get that bundle of sticks? And you know, that the two methodologies that have gotten the most thought are around role mining. So kind of the Starting with the data and kind of building roles that way and roll engineering.
So kind of the top down approach in other words, a business saying, you know, we need to roll that does X, Y, and Z and then kind of building a roll around then and, you know, my ran, I'll just, you know, put it in black and white terms. I think role my role. My name doesn't provide a lot of value at least when I've seen it in and, you know, I'm sure this will get a lot of heat of. We had a forum where people who just a winner. Stupid.
You know, we got in so much value out of it, but, you know, when I've seen examples of role mining working, it's, you know, taking that data that you have about users entitlements and it saying looks like you've got an access pattern here that 80% of the people in this department have why not give that access to a hundred percent of people? And so my thinking is because we don't want to give people access that they don't need, right? It's funny. Percent of the people don't have
that role. That they're not banging on our door saying, we need that roll. Why would you create that rolling? Give that access to those 20% of the people. What are your thoughts on that? I mean, principle of least privilege. Every time you go into an organization, it seems like let's say 90% of the time. They've got a principle of least privilege baked into their policies and standards around
information security. So I don't see why you would want to give anyone access that they don't need. Let's take a couple parts here. I want to get into this because that was literally next question was are back and compete against that concept of least. Privilege.
They are competing Concepts. So what we're, you know, we're talking with folks, you know, and having these kind of conversations, it's okay, you know, we want to be more role-based and oh, by the way, we have this policy that says, you know, we're least privilege. Okay. Well, which is it because if you're assigning roles that have access has two things that people don't need, then you're violating the concept of least privilege and that's usually
kind of a thinking machine. When we're talking customers and, and kind of thinking, okay, well, house is actually going to work. And I think this kind of goes back to the whole roll mining on the roll engineering exercise as well. Because I do see some value in the role mining but I don't see and I see the value of the Roll engineering and I think that they're most effective when
they're done together. If you're trying to do one or the other, I think it's a lot more difficult to see the True Value out of it because The way I see it is, you know role mining is basically digging deep into these applications or systems trying to figure out what are all the different access rights. That could be in place for that application and then basically just coming up with inventory.
So the mining is, you know, you're going it out into this, you know, this this mind and down into the shaft and you're trying to find, you know, the different nuggets of gold ore and those gold or might be different entitlements within the application. It's great that you found them. But what do you do about it? And I think that's where roll engineering comes in, is okay. Now that you know what those nuggets are, what are we going to do about it?
Do we take this gold and refine it down to this purpose, right? Or do we leave this as a raw material for some other purpose? So I see the role mining more as a Recon effort. Let's figure out what's out there which is good right? You want to know? Because if you're trying to protect an application and you don't protect you Applicant, you know, the rights that allow edit access to a database table and things go Haywire. That's not going to be good
either. So you kind of have to know both and then the engineering comes from working with the businesses. They okay. Let's talk about what are we going to give access to people and then does that, how does that work with these privileged? And the concept of rules because there certainly is a lot of risk-based decisions that. I think that can be made there around, you know, let's, let's take the cafeteria menu for
example. We really care if everyone has access to that, you know, maybe it was not granted and it's a certain people, maybe it was a mistake or maybe it's a new app that just didn't get back filled to two people who were here before the app, right? Probably not right. The risk is low. Do we really care for having chicken on Friday or, you know, or ribs or whatever?
Maybe you know, that's okay. But if there are more sensitive accesses then yeah you probably do care and maybe the role that you thought would be good for For an entire team or a department, needs to be split up because you want to keep with that, you know, concept of least privilege. So I think there are I think there's value in the role Engineering in the mining and the mining isn't just finding
the applications, right? It's also or the entitlements that it can also be what do the people have? And I see that as just an intelligence report that comes back to eventually someone in the engineering side of things whether it's the role owner, the role developer, you know, whatever it might be, whatever persons handling that Say okay. Yeah. Jim and Geoff, both have this access, but General Jin has this other access but Jeff doesn't is that appropriate? Maybe it is.
Maybe it isn't. Right. And I think, you know, whatever the differences are comes down to risk. If it's because Jim can knows that we're having chicken on Friday and Jeff walks into the cafeteria, you know, back in the day when we could actually go
into into buildings. You know, any surprise when the menu comes up, maybe that's a risk were willing to accept or maybe I'm just really picky eater and I need to have Have the menu in front of me before, I'm going to waste my time walking down the cafeteria, just to find out, we're having the same old thing. So, that's how I kind of look at it. You know, between the two, I think, if you take a real philosophical approach, that's probably not the right approach, right?
It's good. Value out of doing a data mining. And, you know, we use the cafeteria menu example because Nobody cares, right? Everybody has access to the cafeteria menu. Like, no one, no one should care anyway. But they're, you know, made me think of a few things.
One was I saw a really good presentation and then we'll know who attributed to, but it got into have access management, fatigue managers getting so many requests for Access that eventually just started rubber-stamping because they didn't have have time to think about it. You know, we're all busy during the day. We're doing our job. Then you layer on all this kind
of red tape. But if you really boil that down to only send a question to the approver, when it's actually something that is worthy of an actual review, then you can get to the point where you actually have deep thought put into it. So you never asked about the cafeteria menu, but you always ask about access to sap or whatever. The financial system are and then it's, you have to decide everything in between whether or not that requires somebody to
review that approval. Another thought I've run into overtime is with least privilege applying that to privileged access menu. So it's kind of the same concept around assigning. What is the risk to the access? And that's an area where roles can be very valuable, right? Because You know, if you have, I think philosophically speaking anyway, you should have fewer rolls than you have entitlements, right? Yeah, ideas.
Should be you're bundling those sticks and you're not creating more bundles of sticks actually, there were sticks. So, if you can get to that smaller number, it becomes an exercise that is more feasible. In terms of actually assigning a risk value. Something that can be used to determine what are the Operator controls around that, around that access you touched on the design, their right a little bit around. You know, what are these bundles look like? How does someone get started
designing roles or going down? The are back or a back path for their organizations? Well, I think it's, I think it's probably like a lot of I am things and you have to look at trying to get your low-hanging fruit first. Great. As I always think about with our back, is you start talking about? Are back with people. I tend to think, people think
it's all or nothing, right? You're either doing everything through our back here, doing nothing through our back and when you see organizations that are actually on the are back path, they usually never have to finish line right there. Doing a lot of things with our bag and where I think organizations to get the most value is the things that they
can automate. So it's that Birthright access getting someone started on day one so that they Whatever it is 80% of the access that they need in order to do their job and then beyond that, it's now you have to start getting into the tougher stuff. So building those roles that are around functional teams or functional jobs within the organization and tying off the access, and it really requires somebody with expertise on what is the access that you need in
order to make that successful. Successful. And so you need to pull in people from the business and really where I think I am teams and it teams should spend their time. There is with the business units that really want to step to the table and invest the time to do this. So in other words, if somebody's going to play along, you're going to get a lot further than if you feel like you're dragging them into it and there you're making them do something that they don't want to do.
I think, And those other groups that are not participating. You see this success as being bred by the teams that are participating, they'll want to participate as well.
So that's kind of I think the approach is think big but know that you have to kind of start small and where you start is with the low-hanging fruit stuff you can automate from and then when it gets into the tougher stuff, you know, first work with the teams that really see the value and are willing to invest their time into making this successful. Yeah, I like the The concept of starting big and starting micro, you know, maybe it's macro micro so, right?
When I say that what I mean, is, you know, let's figure out. Are you an employee, right? It's kind of a basic decision. Maybe your, maybe an employee. Maybe you're a contract or maybe you're a vendor or an intern, you know, whatever. Maybe start with those giant rolls that you can answer relatively easily and try to figure out if there are things that are in common that all employees. Get, maybe it's VPN access. Great. Now, you've got something, you can edit that maybe it is the
cafeteria schedule, right? Maybe it's a company intranet site, something like that. So you start with these very broad roles and that's okay because you got to start somewhere and then I like to start by dogfooding rolls with my own team. So what I mean by that is designing roles for my own organization and seeing what works, what doesn't work so that I can really kind of refine the process before I go to the next area, right? Another business unit other team Etc.
And I would certainly start with teams that are friendly to, you know, this this process. It's a lot easier with a willing partner, that's for sure. And knowing that, you know, you're there to try and help it and that there are going to be pain points, right? Let's figure it out together but the idea is to at some point roll this out to the rest of the organization and being able to design those roles and figure it out from a macro micro type of way.
I like that approach personally because I think You don't push off the value. That might that you might be getting by trying to design a whole bunch of rolls at the department level. You can get value out of our the employer their contractor, right? That could be enough to make a difference. And you can say all employees, when they on board, they get an active directory account with these two adgroups and this Office 365 or Microsoft 365 license.
That might be, you know, a good enough win to solve a couple of pain points, maybe from an onboarding perspective, right? It shows that you have Have some capability to get this done for right? So you start to build confidence, he organization and that, you know, the money and the time that's being invested into this is working. So I think that is, you know, a big part of it.
And then, you basically make a circle bigger from there or you make the circle smaller from there, depending which angle you're approaching from. And you can do both at the same time, you know, with with the proper, you know, management around how you'd like that to work. I think I really like your house of growing.
Your own dog food. I think that works really well with the And your, whatever your I am group or some small contained group, I would say that I key generally is one of the hardest departments to take on in terms of Designing roles for, you know, system administrators database administrator. That's where I'd like becomes almost impossible and so you might feel like you're swimming Upstream. If if you start with it, other departments can be more stable HR.
Finance things like that because they those roles generally tend to not change as much overtime as some someone and I can do or be as cost in that group. Yeah, that's the point. I think, you know, IIT is this is probably the hardest. And if you can start with something simple, write your ear, again, showing the values sooner rather than trying to tackle the really hard stuff, right? Get the 80% that will get value out of the stuff that you do know. And then either punt or figure
out later down the road. How you're going to handle the rest? And, you know, it's okay, I think to not have a role for every single thing that's out there. That's just, that's the real is, you know, the realistic way to a kind of approach. This is different teams, different organizations, different business units, different geographies. Those will all play into whether or not a are back. Model makes sense. Right?
You may have a more mature role based access control for certain teams on a less mature in other areas. Using the console we've kind of talked about, maybe it really only has An employee role. Whereas, you know, Finance maybe has an employee role and a finance role. And you know what accounts, receivable World, write something like that and I think that's okay. You just have to be able to manage it effectively and know. And when no one know when and where to pick your battles I
would say. One other thought I was having is we were talking about something like finance and we think about, you know, Erp systems a lot of times they'll already have a complex role structure. Then the Erp system. And so I think as an I am practitioner when you're looking to do, Enterprise are back, you have to kind of set what your scope is. I think is a dangerous place to you know, volunteer that you're going to go into the application to solve the role needs within
the app. You have to start with an expectation that the app has good enough application Level roles but you know, so I think that's an important point and the other thing I was going Going to say is just that, you know, I think finances really good place to start because that's where you're also going to find a lot of segregation of Duties types issues and the IGA platforms that can really, you know, identity governance and administration platforms that
can tend to help build our back models and manage our back. They do a pretty good job generally speaking in terms of identifying segregation of Duties and then baking those into the access request. Access review process. So kind of get a double benefit if you focus on on that area and you're able to roll in s0 D as part of role management.
I'm glad you mentioned segregation of Duties because that's something that we definitely see a lot especially in you know Erp and finance apps, things like that. And that's usually where we see relatively decent if not good. You know, controls around what the roles do because there is some you know, more judicious. Thinking around who should have access to what in a financial systems.
Those sorts of things where we see a lot of organizations, kind of fall down is cross application, ssds. So they may be really good at managing sap and, you know, having the appropriate checks and balances there. But where the challenge comes in is if you have, you know, across different applications. So maybe not only are you an administrator in sap. Maybe you're also an administrator on this other application. That is kind of outside the purview of finance.
That makes a toxic combination, you know, something. Introduces more risk to a certain process, you know, things like that. So this is I think also an area where there is the potential to leverage roles and the different axis controls. Once you're aware them to say, hey we have more visibility now of what people have access to and what they can do. Not only within a system but across systems. Does that make sense?
Do we want to keep that going or do we need to think of A control to, you know, address that I think when we have these conversations it's one other thing that has everyone who's listening these to keep in mind is that, you know, we try to make it as generic advice, right?
Or a generic copy. They were talking about, but especially when it comes to, like roll management at the segregation of Duties within Erp system, it's going to be a lot different for 500 person, organization versus a 50,000 person organization and You know, he's going to have to take the advice and then kind of feed it in as one data point, but I'm sure either way are our fellow. I am practitioners out there.
They become expert at doing within their organization and kind of are able to take these data points. It's something where we're really talking here around, kind of like guiding principles. And how do we, how do we move forward with this? It is very hard to do. You know, I said it before, these are generally at least a year, multi-year long projects to do. The mining right, finds the entitlements, and then figure out. What do they do?
Do they make sense? How are we going to, you know, construct, those bundles of sticks, right? Those sorts of things. So, it is difficult and it is something that can be done, but don't get, you know, don't get to, I think Lost In The Weeds if especially if you can start to address some of the macro type of roll situations.
So maybe we should talk a little bit about some of the guiding principles for role management that we've kind of Talked about, you know, around here in this conversation but also maybe some more things we haven't mentioned yet. Maybe we can start with what makes a good role versus not a good role. One of the things there is a good role is going to be used a lot. The business is going to understand what it does and it's going to apply to more than one person.
It's going to confirm more than one small piece of access. So the Moores used the more people applies to the better. The role is Is what are some of your thoughts are? Yeah, I like to keep it simple, right? Don't create roles unless you need them. Gets it's the same thing. As you know, don't create an active directory group, you don't need it. Don't create, you know, any type of entitlement you're just creating more work for no reason.
So, take a look at the way things are constructed and figure out if you actually need to spend the time doing it. And maybe, you know, if one person has this access and they use it, you know so infrequently. Maybe it does make sense to leave out of a roll and make it more, you know, on demand. Requestable or however, you kind of like to work through that. So I think that makes sense, right? What about a framework.
So we've talked a little bit about Birthright and requestable roles, and I feel like that's a pretty good framework to kind of start with when it comes to getting started with, how do you want to, you know, figure out which bundles of sticks, you want to create and how they're going to be constructed. Maybe we can, we can talk a little about that, right? Yeah. I mean, I think a framework means a way of thinking about, About a problem and something
that is reusable and solvable. So to me, it's setting yourself up with a series of questions that you can ask about, you know, as kind of a workflow almost of questions you would ask yourself in terms of building roll, is it a good Earth re-roll? That's what you would want, ideally, right? Because I think you want to automate access where possible if not. Can you make a good requestable roll? And if not does Even make sense to have as a role.
So, kind of questions you get, as yourself are, can I define the user type? So if we're using the example of interns, yes, I can, you know, interns are distinct group of people does an authentic authentication or authoritative Source exist for that user type. So maybe in our HR System we have in turn as it goes ignition. If we do, we can still go down that path. That it could be A, you know, we could still be going down the path of having a birth very role.
If it's not in the in the authoritative Source like the work they system or the HR System, then it would have to be a request Will Roll, right? There's no way to automate the idea that somebody is is in that grouping. Another question would be kind of defining entitlement pattern
or access pattern. So in other words do interns actually have to you know, access the same Soup of data across all the entire intern population or do those is there some subset of data within the organization that they do all need access to? And then is the membership volatile. So example, I'm going to give here is that I worked with an organization that they would change their cost centers very frequently.
And so even though it seemed like at one point your cost center could be used, it was coming from an authoritative Source. It did Define some access patterns because if you're in a certain Cost centers. It kind of meant that you needed access to certain things. However, it was volatile it change so often for people as they did. These re organizations that it actually did not make a good roll. So if the interns hype is usually not volatile, right?
People are yes they're interns and then they can move on to something else or leave the organization but they're not switching different types of in Terms all the time.
If they are then it would potentially As qualified as, you know, potential birth re-roll, that to me is what the framework is all about is being able to kind of walk yourself through a questionnaire and being able to determine whether or not you're creating a birth rate role of requestable roll or you know that population doesn't make for a pretty good roll.
Yeah. I think you touched on a couple of important things there and especially around data quality and coming from HR and other authoritative sources like workday sap, Oracle etcetera. Is, you know, a lot of these access decisions are going to be driven by the quality, and the timeliness of the data in those systems. So that's something that you also want to take into consideration when you're talking about how these roles
are going to be constructed. And then, where is the data going to come from and, and from in, from when right, if someone gets loaded into work day, the day of their higher that might not be a good spot to drive automation from a Birthright, real perspective to maybe that you know, things end up being more of a request. Double role because you don't have the data in the time that you need it to be most
effective. So I think that's something that also kind of consider, you know, any talk about automation, right? And I think this is something that you grow into. You don't want to automate all the things all the time. You probably want to pick where you get the biggest bang and where you feel the most comfortable and safe from a maturity standpoint, to be able to assign access in an automated fashion.
You don't want to, you know, create a role and it has the wrong access it and they just gave it to everybody and put your organization at risk. Yeah. There's something else there with the The, the automation pieces, typically organizations are getting that data from an HR System, right? So those HR processes get bound to your prophecies for assigning access, right? So there is some some governance required there and that kind of also comes down to how stable that that data is right?
If it's being changed. If you know, you're trying to drive access off of something that you know, the Code or job code. There's job codes wind up changing every couple of years. You could, you know, create Havoc. Yeah. Absolutely. It's got to be. This is where the tight integration between HR and I am really kind of hits the most because it's okay to make those
changes. What's not okay, is to not let the, I am team know and those changes are being made because that certainly affects me a lot of things down the stream. So you had a good relationship with HR HR, It Whatever the right, you know, term is for your organization and where that Authoritative data is coming from makes sense, and maybe it's not HR, right? Maybe contractors or vendors are managed by Finance team or maybe they're not being managed at all. See it a lot, too.
So trying to design around those types of issues, you know, we're not going to have the answer right here in this conversation, but at least bring it up so that it can be addressed as part of what is the overall rule strategy? That's right. So I think, you know, we've covered quite a bit today and it, you know, there's some other things that we probably could probably touch on, you know, you
want to have measurable. Results when it comes to that you don't want to create rules that are unnecessary, right? Keeping it simple making sure that their roles are easily understood. So using plain language to describe what the role is and what it does, you know, that'll help people not only request it but also approve it and hopefully that you get out of the rubber stamping situation where, you know, a manager or whoever is responsible for the access. You know.
Just says yeah, it's okay because of apathy, they don't care or because of fear, right? There may be afraid to take away something because someone can't do their job and it ends up to become a, you know, 3M call on a Saturday or something like that. I think you also think about the fact that you know, people retire and leave the organization over time.
Other people are going to inherit that ownership of roles and they need to be able to inherit them and understand what they do. Yapping, The Inheritance is a strategy that if a lot you don't want to break the chain, right? So if someone owns a role and they lead the organization, My basic philosophy is okay that person's manager should now become the owner of that role on the till they tell me who is
going to do it instead of them. So that way you don't have this role hanging out there that doesn't have an owner or has a gap, you know, in some way, whether it's approval structure, whatever. So I think being able to come up with, you know, standard processes around, that doesn't mean that they permanently own it, but someone has to own it and you want to make sure that, you know, you keep that link between the two things in place. Yeah. And you mentioned something about Measurable.
I think that can be using some measures or some metrics. As you're rolling out, roles to know how many roles have owners or even if you're a little kid, like groups, they have owners that they have descriptions, that are, are usable, you know, you can use that to make sure that you're closing the Gap. But then also, as you've really gotten a head of steam around using rolls, how many rolls are, you know, how many, People belong in a roller. How often is that role assigned?
What you find, if you have low use of a roll, it's probably one that you want to reach out to the business. Say hey, do you still need this right? See that you're not using it very often or there's only one member of the role is just you know, is this something that's worth us? Investing our time into having a role like this? Maybe it is, maybe it isn't. But that that's where that data can potentially, you know, use
Is metrics. Don't only have to be to communicate out to the organization and hey this is what a, what a great job we're doing. But also having those metrics to do a better job of managing yourself. Yep. Fulfilling that role accessed rewrite. Sometimes you got to do some pruning and that's healthy and a way to keep it, you know, manageable.
So I totally agree with that. We've been going on for quite a while here, role-based access control and, and other things around it. Is there anything that you want to bring up before we decide to call it for this week? We did talk a little bit about it, but I think the technology side of this is really the identity governance and administrator IGA space. And so, you know, if you're kind of looking to do additional research, one thing I would also say when it comes to roles, right?
Taking it from this philosophical discussion that we've had today and turning it into something that's going to be very tangible and restart using specific terms of me specific. Things is your To adopt technology. I recommend that if you're going to adopt that technology that you try to adopt the practices and best practices built into that technology, IGA is the space that typically does role management. And so I just wanted to point that out.
That if you go down the route of say, implementing a cell Point type system, they have definitions on what roles are business, roles, application roles things like that. Use that terminology try to adhere to their best practices as well because if not you're going to kind of be swimming Upstream. Yeah that's a good point. You know you buy a lot of these Technologies not only for the technology itself but the process that comes with it,
right? And this is what those Technologies. Do sale points, avian clear sky, a whole bunch of these other IGA players. They have a process that they follow and generally it works otherwise their application will work. So you want to try and stay within the bounds of that and try it. I decided to adopt those those processes into your business so that you're not having to get into this world of customization and exceptions.
And, you know, all the kind of things that come out of using technology in a way that it wasn't meant to be used, which you certainly want to try and avoid as much as possible. Yeah. All right. Well, I think that's a pretty good spot that maybe we can leave it for this week. I feel could cover a lot of ground, on our back, a back P back and I'll bunch of other
acronyms. I'm sure that we threw in there as well, so don't forget that you can, you know, Visit us on the web at identity at the center.com you can see us on Twitter at idac podcast. And with that we're going to go ahead and talk with you all in the next one. Thanks for listening. Thanks for listening to the identity at the center podcast. If you like what you heard, don't forget to subscribe and visit us on the web and identity at the center.com.