Listen to Identropy's Jim McDonald and Jeff Steadman on their podcast at "Identity at the Center".



Both Jeff and Jim have over a decade of experience in the Identity & Access Management space and guide companies on their IAM Program journey through Identropy's Advisory Services arm.

On this episode # 4, Jim talks with Jeff about his idea in an upcoming article he is writing about the IGA lifecycle: Approve - Provision - Collect - Verify

Brought to you by

Want to join the conversation? Leave us a message here:

We hope you enjoy this episode and please subscribe to the podcast for updates on new episodes!

LISTEN HERE or read the full transcript below.

*Disclaimer from Identropy: These transcripts are produced using automated tools, so may not be an exact word-for-word transcription. (i.e. - if you read something that sounds wrong, it's the tool's fault!) As always, for a better experience, please listen to the actual podcast.

Podcast #4 Full Transcript:

Identity At The Center #4: The Circle of (IGA) Life

Jeff: Welcome to Episode 4 of Identity to The Center. Jim, you've been working on a blog around the cyclical nature of Identity Governance.

Do you want to give people a sneak peek of what that is?

Jim: Sure. So this is a blog. Jeff, I want to pitch to you and get your feedback and get some you know, hopefully I'm going to publish it in the week, next week or two. And it's a total stink, got to go back to the drawing board. But I'd like to do with my blog as I like to lean on. Actually, the way I look at things when we're doing our consulting engagements. And so this is kind of the more technical guy in our group. I like to go in and spend a lot of time looking at the architecture of things. And so this blog is about the architecture of Identity Administration and Governance. That's what the space is called agenda governance and administration. A lot of the clients we work with are doing Identity Administration. I would say at some form or another. But the idea of the circle is that there's really two parts at Identity Administration is what should be you're somewhere essentially saying, Jeff has this entitlement. And then what actually is. So, eventually that Jeff gets an account in any system and has a role or entitlement in that system. And what sometimes can happen is if there's not the circle, what should be and what actually is can get out of sync. And that's mostly because if there's any kind of backdoor administration taking place on the system, counts can get added or removed. So I guess that's the idea. That’s what I look for, is that there is a closed loop in this process. So I guess that off you. Do you think that I'm onto something there?

Jeff: There's something there at the cycle.

It's difficult sometimes to come up with a new paradigm for measuring this type of stuff, right or concepts, etc., because it feels like there are so many these out there and is very trite but true ones. So, how does your circle start?

Jim: Ok. So all I've got four parts, it's what I call a approve provision then collect and verify. And so its start with approve and the ideas that approve breaks down into two parts, the Identity and the Access. So approve could be a physical approval or an implied approval. And what I'm talking about, the Identity, the idea is that the Identity would be coming in from either an authoritative source section as an H.R. system, or it could be getting manually created in the Identity management tool. Somebody could be coming in and saying, I just hired a new contractor, for example, and they need to be set up. I need to create an account for this person and then get them access to X, Y, Z systems. So, starting with that, Identity having the approval come from either an authoritative source, this here’s what I find. I'd like to know how you think about those, but the most organizations are using that. They have a good authoritative source for employees, which the H.R. system. And then when it gets outside of that group, whether it's contingent workers or gas or board of directors or whatever user populations are dealing with other than employees, it gets a little more murky.

Jeff: Yes, I would say not as mature definitely as what the employees typically have for whatever reason. And this is nothing new and probably not shocking to people who would listen to this. Employees are typically well managed, but not all employees. Some folks do a good job of it and they have very similar process. Others they don't. They're using a spreadsheet. They don't have unique identifiers. It's really just not great. But there's a lot of ways that could be solved around that.

Well, you could always try to put them in H.R. system, but that tends to be a protracted battle that you may or may not win, depending on the position of HR. You can put them in a spreadsheet. This is the manual dirty way of it. But that's doesn't really scale very well.

Or you can build something, which is something that comes up quite a bit where typically the IAM team and by extension, I.T. has to manage not employee identities in some way because of the lack of a centralized tool to do that. Then you've got the third like third parties, like field glass and like other systems that specialize in non-employee management. So, but all those could be tied to some level of approval to get into that authoritative system.

Jim: I'll tell you. Another use case that came to my mind was universities where they could have people who are members of the community who they allowed to get library cards. So, this is a scenario that I actually ran into with a client where they have a website where people can go up and sign up for an account. And just having that account has some very rudimentary access.

But you apply the implied approval is it's a low level of affiliation. It doesn't require any kind of Identity proofing process. And really, until the kind of upper level that account, they're not going to be able to do a whole lot with it anyway. So the approval is implied in that. We're not too worried if people go and create an account and check out a library book.

Jeff: The risk is probably low to right at that point, if it's something implied, it's a service or access that's generally not need to be security that we're thinking.

Jim: Exactly. And really, I think so in terms of the blog, in terms of this idea that I'm pitching is the ideas that we have to go in and look and make sure the. The identities are coming through some process and in process the level of risk is appropriate with the level of approval that it goes through, whether that's implied or somebody, there is some kind of workflow where the person is actually approving the Identity. Again, the Identity is tied off to a human being. In most cases, or the identity could be tied off to kind of an IOT type device. The next thing, though, is around it within that approved spaces. Now approving, giving the person access. And so, we have the Identity and let's say, for example, the Identity is a person who lives or works out of the Boston office. And based on that, they could be granted. So if, say, they're an employee in the Boston office and based on that, they could be given access, given an account and active directory and added to a few groups. Given an account and the travel management system and to the employee portal and to some to the parking system in the Boston office, things like that.

Again, that's kind of an implied approval because of what we would call it, kind of like birthright access. And the other way would be what I call ad-hoc approval or ad-hoc access requests, where they go in and requests somebody requests access for them or they request access and manual approval is required. So if they need access to the finance system, perhaps their manager would request it for them before maybe before they even show up for the first day. And the person who is responsible for the act for the accounting system would have to go ahead and approve that access.

Jeff: You put an awful lot of faith in managers during the first day of starting.

Jim: It is  the idea at least in terms of the blog, is not to dig into too much detail, but more or less to say, those are processes that we have to look at, make sure that they're appropriate, make sure there's appropriate level of automation and that there is a paper trail.

Jeff: Yes, and I get it. And that was probably more of a dig towards managers not doing what they're supposed to do, which is what every IAM person feels like. It's not happening. Kip Right up, automations it in time, they don't request access. From my operations background, it's Friday four o'clock and. Oh I have a person starting on Monday. Let me put this access request in. It's like oh now those two weeks ago.

Jim: Now I was stomping too.

Jeff: Yes, exactly. So then you start rushing things.

Jim: Maybe a future blog topic Jeff. I saw a really good presentation someone did it at a conference off the take it up and I'll remember who it was or even what company they were from. But it'd be a great one to do a blog on, which was the idea that they're moving toward things where if the risk was low enough, that they would just let approvals go through.

And because the ideas that some managers get asked to approve access dozens of systems and hundreds of times a week, or even if it's not that much, at some point you get to a point where you're just like enough is enough. I'm just going to approve but if you know, the only time that approval requests ever come to you is when the risk is high enough. You're gonna take a more seriously.

Jeff: I feel like that's almost its own topic itself. Is that whole approval inundation that sometimes people get that could be for the manager, could be for an access owner, a data owner, really the whole intent of the reason you want is an approval is to make sure it's appropriate, if it's always appropriate than there needs to be some sort of implied situation, maybe it's a role or attribute or something that becomes the trigger to get that access and doesn't require approval and almost treat it like a birthright or a predefined role that gets very good every once in a while. Spam from your IAM system is there are good things you want to make sure that you're only sending things out when it's absolutely needed.

Jim: Yes, if things from your IAM system are ending up in people's junk mail, that's a problem.

Jeff: Yes, I got a problem for sure. So, that's a proof. What's the next thing Your cycle of IGA.

Jim: So, the approve step really gets them into this should be. So if you went into that IAM system and said what access does Jim have? You should be able to go and see a full list of all the accounts on entitlements I have. Now we need to somehow get that from the Identity Management System over into the applications and I call this area provision. So the idea here is how do we go ahead and take that and put it into the application or platform and the best case scenario is that most of that is automated.

When I look at an organization's process for provisioning I don't expect them to be 100 percent automated. But the more automated they are, the better. So there's automated and manual in terms of automated kind of within the blog, I was thinking about going through and talking about the different types of automation. I've got proprietary provisioning connectors using APIs what I call least common denominator, which is sending flash files. There’s a custom process, which a lot of times we'll be in place for custom applications, Enterprise Service Plus.

So, a lot of organizations using E.S.P and then just in time provisioning,  So, if you're using some kind of single sign on system based on the Samwell 2.0 standard, you can use the just-in-time provisioning calls to create an account. And define a roll or entitlement through that call.

Jeff: So we get a lot of always a provision I went for as a way to simplify it in a way that API covers more than one area, because that's kind of what I think of API. I think of the kind of Chrome cast that programmatic way to do a provisioning. What about manual provisioning? Because, like I said, not to be automated and I don't think it doesn't make sense to automate something. It has like three users in it sending a ticket to the appropriate queue or for provisioning or email like that. Maybe that can be included.

Jim: Exactly. Sometimes I start these blogs like they end up as like 10 pages. You. This is way too much data. I get on these tangents sort of get in terms of the automated provisioning, I just rattled off a whole bunch of ways that it could be done manually I think is a little more simple in that I think the right ways to do it are to integrate into a provisioning says or I'm sorry, a ticketing system like a ServiceNow and drop provisioning event in the right queue for provisioners to go and fetch their ticket. Go ahead and create the access. Create the account and go back and close the ticket within ServiceNow and have ServiceNow and go back to your Identity Management tool and say the works been done.

Jeff: Now, where would you put the approval on that stuff? Would it? I guess what would carry the approval? Would it be something before ServiceNow, for example, or do you have the approval within service now?

Jim: I think a lot of organizations really want to do everything within ServiceNow. So they want to have even the access requests generated in ServiceNow, ServiceNow is workflows and etc... And, I see that done it can be successful. So I guess within the scope of what this blog is, that's fine.

But really, the way I see most organizations who've invested in Identity Management System is that workflow for requesting and approving access will happen within the Identity Management Systems user interface. It will send a ticket then to ServiceNow to the provision and the provision will go ahead and do the work and close the ticket and ServiceNow will send a message back to the Identity Management System saying the work is completed.

Jeff: I think that's something that typically most teams want to see is don't give me work that's not approved. The assumption would be that if I receive a ticket in that scenario, I don't need to chase down approvals I can just do the work. It certainly decreases things like SLA that are typically how those groups might get measured how quickly does this ticket get worked, I know I've had this challenge quite a bit is in the past is, we're at non-approved and a matter either doesn't respond or they're on vacation or something and sets throw SLA is out of lack and so forth.

So, my assumption given the cycle would be that the approval step is happening in your first part. And when you get to the provision step, the provision is carrying out the approval, the associate with that approval, is that right?

Jim: That's exactly right. I was thinking about it. The only other kind of sub point on the manual is that some organizations don't have ServiceNow or don't have as much of a drive to say, all right, we want all of our provisioning tickets end up there and a lot of identity management tools will have kind of the same ability to create a ticket, Email the provisioners somebody to come back and claim that, take it, work it and close it all within the Identity Management tool. You don't necessarily have to have an external system. But I'd say the majority of organizations I think are kind of in a mature and good place with manual provisioning had that.

Jeff: That makes sense. It's not gonna have ServiceNow for taking system emails, I think that's kind of relevant really at that point, You're acting on a piece of work that is to be approved. I think that's part of the key there, whether it's manual or even if it's something that's going programmatically, API platform, whatever it is, the approval stuff is already taking place. So it's OK to grant this access.

Jim: Exactly. Now I think we're still kind of within the bounds of how things should be. Now we're automated if we're doing the Administration Identity Management tool and the tool is then provisioning accounts into the platform. We should have a good picture, 100 percent of what should be should actually be as it is. At the same time, most systems have some kind of backdoor where you could go and create additional accounts, create service accounts, create administrative accounts, and essentially create any type of account. And this is where so I feel like 10 years ago or fifteen years ago where Identity Management Systems were, we're going to put administration in the center and we're going to get really good at provisioning out. Then along came Identity Governance and then Identity Governance focus was accounts have already been created out in all the applications and platforms. We're going to pull those in, correlate them and give you a picture of who has access to what. So that's kind of the second part, which is, I should say the third step in my cycle is that we're actually doing that. We're going out and collecting from systems, what actually is who actually has what are the accounts on entitlements that are actually within your system or pull those back. And we're going to correlate them back to a single person. And then that's final.

Jeff: Which is where they hit the security hits the road.

I mean, this is where you catch accounts that were create outer bands follow the process, which is an indicator of compromise. If you're looking at it from that from that angle, too, and you're totally right on, I think this was like a big selling point like 5, 10 years ago was the out-of-hand account creation. And this is a key part of pulling that information in, who has access to what? And if you've got an access out there that you can't associate with an identity, whether it's a person or a service or whatever it may be. You better shut that down or figure out who it belongs to pretty quickly because it could be something that's not of a good nature.

Jim: And the other thing is, if there's an audit, the access processes for an I.T. system, they're not going to go to your central database of what should be they're going to go to what actually is. If there are differences between what should be and what actually is, that's where you're going to start running into issues when things start happening out of band. The variable is doing the job and following the process. The way is to find great, but administrators sometimes have to work outside of the process, or at least that's what they tell themselves having been on that side of the fence. I know when you're in the middle of solving an issue or the CEO's, admin assistant calls you, says they need an account right away, you're motivated. You just get that account created. You're not too worried about making sure that the audit is going to be airtight six months down the road. So the idea, again, on the cycle is that you're going out and you're getting there as-is. And then the fewer steps that I had that in this loop were verify. So it's really just taking me as is bouncing it up against the wall, should be and finding the differences. So if you have accounts that were created out of band that somebody is taking those up and doing something with them. And then the other part to verify is that even the accounts that are matching up and everything looks great. Is that on a periodic basis? This is the Access Governance step on a periodic basis. Somebody like a manager of that person or somebody who's responsible for that application is reviewing access and making sure that the right people have the access that they should.

Jeff: I suspect that there's all there when you have a mixed environment, meaning automated provisioning and manual provisioning.

One of the things you could have to watch out for between the collect and the verify stages, there would be the drift between when something is and when something shouldn't be. So, let’s say I'm terminated and on my account seem to be removed and everything gets removed except this one account.

But that group or person that is phosphor is responsible for removing that one account is either behind or on vacation or whatever, maybe has an SLA there needs to be some way to kind of factor that in to the verifying the collect stage, say, OK, we know that Active Directory is automated and that the time for termination is milliseconds, for that to take place.

But for now, just pick something. Concur. Which is maybe manually provision the time. It's not going to be some sort of connection already. The finance team needs to manually remove that.

I think that kind of stuff needs to be documented and understood. And then also point in time, how do you catch the ones that exists? Just briefly where it's it was created and five minutes later it's gone.

I think that's where analytics would typically come in. And you need to have more of a real time feed to catch those. If you're looking for these ephemeral accounts, maybe that that only exist for a few minutes, maybe in between cycles. Most I think most people, they run their H.R. processes overnight, typically with IGA. And there may be a situation where an account with for six hours and was gone next day and no one would be the wiser for it unless that somehow comes up as part of a data collection. That's more real times.

Jim: another interesting use case is say you have a SAP system, for example, best integrated with active directory for single sign on. So the person logs in with an AP account and they have a profile in SAP. If your SLA is like, hey, this person is gone, we want them with their SAP access cut off immediately. There are really two areas. One is a view that SSO account. They're actually having your account shut off immediately. They for all intents and purposes, they can't get in at the same time. You need to go and clean up that account on the SAP side. But the SLA could be a little bit longer. It could be a little more forgiving.

Jeff: The security the security issue is mitigated because the single sign on what they need and in the case of I say, for example, and in other systems, there's still an account out there that you probably pay for a license for it. Right. I say things like this can be expensive depending on who the license is for.

And there's a whole cottage industry around even just the license management component.

But, I think if you have a well diagrammed kind of architected authentication structure where you're hinging things as much as you can off a single idea. Most auditors are going to be accepting of, OK. We know that the access is no longer there. There may be a secondary finding the say, OK, the accounts are removed, but the security risk has been addressed because that account is inaccessible, which will typically pass most audits except for maybe the most stringent where they're looking specifically at a system or if there's a back backdoor way into authenticate with that account. So that makes a lot of sense to me.

Jim: I mean. So the purpose of the blog is really just for somebody who is thinking about their architecture, thinking about their approach to Identity Management. And, because I don't think the circle gets completed by accident. This is something that you need to kind of plan out and think about in those terms. Again, that's like a toot my own horn. But as an expert in this space, that's kind of what I would be looking at as an outsider coming into an organization. Is this cycle completing. Are you managing access and then verifying, kind of that everything that should be actually is and nothing more. And hopefully somebody can look at this blog and say, now I'm going to look at my own architecture and make sure that I've got that kind of circle in place.

Jeff: So I've got to prove provision, collect and then verify.

And really, in my mind, it's really kind of the repeatable, scalable process, no matter really how you're doing. Each of those steps, as you're at least you're following those steps to be able to show that accurate lifecycle from an identity perspective.

JIM: Absolutely.

Jeff: So now we need it like a cool name for it Max Circle of IAM. Something like that.

Jim: I'm waiting for Ash to rename this blog and you know, his titles are very informative. But I come up with something squishy like the IDM circle. And yours is even more squishy. Jimmy Max DM Circle.

Jeff: It's this is an inside to us that conversation today. But, I think Ash said, I'm paraphrasing actually something along the lines of, Jim, you're content great but your title suck.

Jim: It pretty much so. I mean, I'd rather have good content and bad titles than the other way around.

Jeff: One could see how it comes together, I mean I think it's definitely  think people find it helpful even just from an education standpoint, because sometimes all take steps, maybe get lost in the chaff of just doing your day to day.

These are things that need to be in place the matter no matter where you are in your IAM journey. You're just starting out or you're where you've been doing it for a while. These are the fundamentals of the IGA lifecycle.

Jim: Jeff, one thing I know we've tried to encourage with this podcast and I'd like to just reiterate is that the folks are listening to this. And I would imagine as we're talking through this, people are yelling into their Bluetooth or whatever, talk about this or what about those? We’d love to hear that feedback, questions or comments and ideas for additional podcasts. It's good to know people are listening. So, I’d love to hear any kind of feedback that we get on this topic or any others.

Jeff: And I'll make sure that there's that information to how to get to us. You know,

Feel free to shoot an email to that, general, and I'll take a look at it and will incorporate it as part of a future episode or, address it directly. But I'll put that information into the showdown. So that way, you know, it's handy there for reference. And we also record this separately, book publisher and anchor, and they have a voice mail kind of system. So if you want if you're using anchor.FM., you can essentially click a button and leave a voicemail for us and maybe we'll play the voicemail and do like a Q&A mailbag or something like that at some point and know take it from there.

Jim: That would be cool.

Jeff: OK. I think we're in pretty good spot for today. We'll go ahead and close it out. And thank you, Jim, for that insight into what is coming through next on your blog cycle. And we'll talk a bit later. Thanks.



Jim McDonald & Jeff Steadman

Jim McDonald & Jeff Steadman

Jim McDonald is a professional with over 15 years leading teams through business-critical technology initiatives. Technical Strategist, Leader and Champion of Change with history of crossing organizational boundaries, cultivating strategic alliances and building consensus and alignment among diverse constituents to leverage IT as strategic asset and deliver solutions that rejuvenate and advance global business’ financial performance. Also as part of our advisory practice and with over fifteen years in the identity and access management space behind him, Jeff Steadman helps develop realistic IAM strategies and provide vendor agnostic recommendations to move the needle on IAM maturity for organizations large and small.