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

PODCAST31
 
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 Jim and Jeff talk about some of the terminologies that can be misleading in the IAM space if people are not on the same page.

Brought to you by identropy.com

Want to join the conversation? Leave us a message here: anchor.fm/identity-at-the-center/message or email us at questions@identityatthecenter.com .

We hope you enjoy this episode and please subscribe to our 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 #31 Full Transcript:

Identity At The Center #31 - Confusing and Misleading IAM Terms

Jeff: Welcome to the Identity at the Center podcast. This is episode #31. I'm here with Jim. My name is Jeff. This is the podcast where we talk about all things in Identity and Access Management. And then maybe some other things as well. How are you doing, Jim?

Jim: I'm doing OK. How are you, Jeff?

Jeff: Pretty good. It's a Friday afternoon. It's kind of the last thing I need to do other than edit these out for the week. So we're recording this one a little bit early because I know you and I are both traveling next week and we're trying to get ahead of the game, so to speak. But through the wonderful world of the magic of Internet, hopefully we'll have this out according to our normal schedule.

Jim: We just have to be thankful that Al Gore invented the Internet when he did, and he said all the time to reassure and that's where he is today.

Jeff: Well, I am pants. I'm very happy about that. So. Internet. Pants. Good job, Al Gore. So what do you want to talk to this week? I think kind of where we're thinking maybe like confusing or misleading terms that we come across in the Identity Access Management space.

Jim: I think it sounds great. So we're on a call earlier today. This is what got me really thinking that this might be an interesting topic to discuss and it might not be in this podcast or really stink.

But the term my throughout there was to talk about internal versus external applications. And someone asked the question, well, what do you mean by internal versus external?

And so what I was talking about was the user population to the primary user of an application. So I was thinking like, the HR system would be an internal application, all using the HR system where either employees or contractor or people who kind of are part of the workforce and external application. I met, as on their web applications that their customers or their members would go and use this application. And that was an external application, even though employees would also log in, do administrative as the primary user were external people. To me, that was an external application in my mind. Well, someone another person from the company chimed in and said, well, we've been talking about internal applications are applications that we manage internally. So it's something that, like internal SharePoint server or maybe something that we built for managing. Even those Web applications I talked about where the primary users are. External view that would be considered internal application man. It was built and is managed internally worse is something like Salesforce or Workday someday that he was saying that that would be an external application because a managed by an external company. And I thought, wow, that is two totally different ways of looking at it. And, the one definition doesn't fit with the other definition of all.

Jeff: I'm going to throw a wrench in to internal external. What about an application that is both?

I'm thinking of Microsoft teams, so teams, you can use it internally and has its own file structure, which is based on SharePoint, but you can also invite external people into it.

How would you classify that?

Jim: Well, yes, another question.

Can you host internally like you can with SharePoint?

Jeff: No, I believe Team is a cloud product.

Jim: You could use SharePoint as that example. I mean, not with a totally mind blowing. My definition would have primarily come from the standpoint of I guess the way I would address that question would be OK. Well, what are people logging into teams with? This is like a corporate active directory account. Or are they using external accounts? I think teams is not even a straightforward answer. Because if you create a team application or team site for people to collaborate with from another company.

Can they use their own corporate identity to log in?

Jeff: if they got Federated, yeah, they're going through Microsoft. That's how it works. I mean, we use teams quite a bit for some of the work that we do. And, I think we're starting to get into the process of hosting teams, whereas I think traditionally we've kind of joined other organizations, teams as part of projects. But we log in with our Microsoft credential.

Jim: Yeah, so I'm having a hard time coming up with the answer. I think the answer would be it would be internal because you're using it to kind of run the operations of your own company verses kind of the strict purpose of the application being to interface with your external parties. I don't know. Let's try the best I can come up with. What do you think?

Jeff: So here's what I think. I don't care. It doesn't matter. I think as long as the definition is agreed to by whoever's in charge of it, because I could see different organizations calling it internal or external or maybe even just a separate category called SaaS. Software as a service. I don't think it necessarily matters as long as everyone is operating on the same definition. So whoever the IAM program or core project team, etc. as long as they all understand kind of where it fits, I don't necessarily think it needs to have a hard and fast definition.

Jim: I think that's probably going to be a good rule of thumb for a lot of these terms that we came up with because we ultimately have to decide what is your definition? Get everybody on the same page in terms of definition and then move on and not just fight their semantics forever.

Jeff: I'm a fan of keep it simple and I think you could spend way too much time solving problems that don't matter. And I think that's one just a grand definition up front or make it known and move on. There's a lot of things to work on.

Jim: Right.

Jeff: What about roles?

Jim: I think they're great sandwiches.

Jeff: Yeah, I like them, too. Nice, nice pretzel roll.

Jim: Yeah. Or Kaiser Roll.

Jeff: Kaiser Roll, yeah.

Really? You know, maybe some Italian, Italian roll that. Be great.

Jim: This is I'm sure everybody who's listening to this podcast has run on.

Jeff: The comedy as much as IAM, I’m sure.

Jim: Oh yeah. I'm sure probably a bunch of people could stop after we just did that. But, I mean, the term roles. Seems like it becomes a debate.

Almost constantly in terms of what does it actually mean.

In my early days in IAM consulting and kind of like to think of roles in terms of they were containers of several different entitlements or permissions or groups and there are more or less they had to wrap up some kind of lower level of entitlement. And, what I thought of those entitlements is like being fed from applications, Here are the entitlements that we have is available to our users and then a role would kind of be able to bundle that up, say, all right, you're coming into my organization as a clerk and a clerk should get the clerk role and that would mean you can do X, Y and Z on this application. ABC on that application, DEF on that application. I know what I realized was that most of the applications actually use the term rolls to talk about what I was calling entitlement. So, you'd wind up collecting from each of those applications a series of roles. What I find that is, you have to have a very open mind and a very be willing when you're working with a new organization to understand how they use the term roles. And if you kind of go in to one of these consulting engagements with a very fixed idea of like a role Bede's exactly this. It's usually because you're talking about a specific vendor product or on how they define roles. So an IT role is as a business role as that. And that's fine. I mean if you're a specialist in a product, you definitely want to understand what that vendor, how they use that nomenclature. At the same time, if you do kind of what we do or you're going into a new organization as IAM program manager or, you switch jobs or whatever. You better be flexible because that term is used differently in many different places.

Jeff: Yes. Remember early on in my career describing a role as a bundle of entitlements.

And I think this is one of those things where sometimes it's easy enough, easier to just whiteboard it out. OK. Here is here's what we're trying to build, right. And then let's try to map where the different components are. Because applications will have different things, right. Then I call it permissions or entitlements or groups or roles, or whatever it may be. And those are application constructs. And then you have the kind of the IAM construct of a role. Right. Or a group which could be either thing.

And then you have the business construct of a role, which could be an HR role,  or an IT role or, maybe even the role of an employee. Even we might consider that a type of identity. The other might be a role of employee or contractor or something along those lines, too. So again, another one where decide on what your domain is going to be and then make sure that everyone's operating on the same wavelength.

Jim: We're working with a client that is a SharePoint IAQ. They have a very extensive role catalog. And one of the things we were talking about was, essentially when one of the role, our role would be X, Y and Z entitlement. So for person had those X, Y and Z entitlements, either because they were assigned the role or they got those entitlements by hook or right hook, individually or in narrative, because there were other roles, they were put in that role. And it may or may not make sense. So what they were actually the solution they'd come up with was, we want to have. A role mean X, Y and Z and strictly that you've got that role because you were assigned that role. We give them X, Y and Z and then they come up with kind of a fake entitlement to add to that role. They wouldn't actually give you permission or anything, but it would ensure that you wouldn't have gotten that fake entitlement any other way than by being assigned that role. I thought that was ingenious. really help them in terms of their access, review processes and things. But really, the reason I brought that up is that there is another definition of a role. It's like you have these entitlements that equate to their role. So you're in that role. And I'm like, I don't know. That doesn't make that doesn't compute for me. I like to think of a role as I guess I'm kind of a top down person. And that is one of the big things to know about roles is beginning to be developed from top down or from bottom up. You kind of say, well, people who work in HR, 90 percent of them have these seven entitlements or groups serve roles, but if you want to call them.

So there should be a new role created that basically all HR people get this role. And so that's kind of the role mining. That's a bottom up role exercise. Top down role would be that we say we want to just simplify the onboarding process for people as they come in to work here. And we start saying our HR is the department. What are what do all HR people need when they start work here, when it's going to be these six or seven things up these applications in these roles for them, these applications and will be either his birthright, and that's kind of our what do we have somebody say to us that was a term of birthright. That's pretty much as much of an IAM industry term as I've heard.

I mean, I've been hearing Birthright since I got involved with IAM prepared for it. Access means that based on an attribute usually coming from an authoritative source about you, that if you have that attribute, you should be automatically assigned a role. If you lose that attribute, that role should be taken away from you. So in other words, if my department is HR, I should get the HR role. If I move and my department is now accounting, the HR role should be taken away from me.

And if our accounting roles that depend on just, if their criteria is criteria for assignment is I'm a member of or that's my department, then I should get those roles. That's birth or the other is questionable.

This would be something like, there's not really anything on that profile that we want to automatically assign the role we wanted to go through. Somebody physically aside, they may be wanted to go through an approval process. And this might be a role specific to using a certain application. It might be a series or application, but it might be something like IAM a benefits administrator, so I have the benefits administrator role and maybe that's not my title, but maybe in the backup benefits administrator. So I need to get that role anyway. That's something where we might say that would be request symbol would go through an approval process and then get provision.

Jeff: I see like just a mass effect, people trying to figure out which way we're going with us for that one. So I think we'd beat Roles to death there a little bit. So let's move maybe to privilege access management. What do you consider privileged access?

Jim: I mean, that's a question we get a lot is we start talking about privileged access. Somebody in the audience or in a group from our client was, well, what is privileged access?

And I can say I want to say. It depends on what you want it to be.

There's certain things I think are clearly in privilege would be things like Domain Admins, a group with an active directory. Those are the most powerful accounts. So then. They can be beyond that. It could be power users, it could be group. So you define within your organization and then outside of Active Directory, it can be individual accounts within applications, databases at the operating system level, Unix accounts, things like that, your organization has defined as privilege. If you're in a large organization or heavy regulated, heavily regulated organization, I would want to involve my risk partners to help define what are the groups or roles that we consider to be privilege. And then the accounts I have, those roles would be privileged accounts.

Jeff: What about social media accounts?

Jim: That's a tough one because I think traditional methods for managing privileged access can potentially fall short.

So we're working with a specific client where, they have social media accounts where they want to be able to take a picture from an event and get that out to Twitter, out to Instagram. Within minutes of it happening. Right. And so, traditional check in, check out the password to log into that platform isn't something that is going to be feasible. Now, I do believe there are technology solutions. I know you're pretty up to date on some of these. But I do think, that the risk posed by social media accounts, especially for certain organizations, is, potentially a big hit to the brand equity if somebody were to take that social media account and use it for bad. What do you think?

Jeff: Yeah, that's pretty much what I'm thinking of, is it's not a traditional privileged access management thing. But in my mind, it's just as important as someone who has Domain Admin, as the person who can go on to your Facebook account and put stuff that you don't want there. And you hear it from time to time. Someone post something that they shouldn't have on the company social media, whether it's Twitter or Facebook or LinkedIn, Instagram, etc.. So there are products specifically, I think, that do a better job at managing that. I don't have any kind of preference and they're the one that I can think of right off top my head to be Hoot Suite. They're more of like a social media management kind of suite of software. I think that works better than something more traditional, like CyberArk, for example, which is more focused on infrastructure within the enterprise. You talk about pictures and I kind of see this a little bit because of some of the work that my wife does where, they typically will share an Instagram account, the password and multiple people may be posting things for events and things that they're being run or they may have one person kind of collect all the pictures, get them text into them in real time. And then one person is responsible for posting those, you know, to the official brand accounts. Those sorts of things. So it could work out a few different ways. They think ultimately what you're trying to do is mitigate risk and that is the risk of brand. Reputation, those sorts of things that can happen if the wrong information is put out onto the social media. So something to consider from privileged access measures. I don't think I'm not going to recommend you throw them in your traditional privileged access management technology. But consider it as part of your program and how those are governed and managed. And then if you're really heavy into it, some organizations have a really heavy social media presence. Consider investing in dedicated tools in that space just to mitigate the risk more effectively. That may be just a policy or a procedure.

Jim: Yeah, I think that's a good framework.

Jeff: So how about SSO, Single Sign On versus Simplified Sign On?

Jim: Yeah, I think the reason I want to talk about this one is.

We'll talk about SSO somebody had a client would say, well, we had this, SSO and what they're really talking about is simplified sign on reminders, rates of single sign on. So quick definition, single sign on is when if you have multiple applications, you authenticate once your session carries with you so that you don't have to real authenticate for each application that you go to.

Simplified Sign on just means that your credentials usually and password is same for each application, so as you go from application A to application B, he's off to re authenticate and authenticate A that the real authenticate B  give receive real authenticate the same username password but no single sign on, single sign on means your session and all of the policies for example, carry from point A to point B.

What is it really important to me, is that where we're going with things is that we keep talking about this or this is something they said at Gartner this year and I agree with a hundred percent that the new standard is MFA everywhere. Now, does that mean that you have to use a second factor everywhere you go?

No.

It means that if you have a single sign on system and you have application A, B and C, again using single sign on, you might get prompted for MFA when you establish a session. There you go to format the app, you're still in that session that already used MFA. Now you may have policies that when you get the application C was such a risky application that you have to do something to step up. Your authentication made me do everything. Again, that's a separate story. Now you're in a simplified sign or an environment to achieve MFA everywhere. It would be laborious because you'd have to implement MFA and each individual application, which is usually just not going to happen.

So this is more of an impetus around why organizations need to get a Single Sign On, not Simplified Sign On.

Jeff: And the Simplified Sign On to is you tip. You probably have to synchronize passwords to different applications, which means potentially passwords going out in the clear, even just out on your own network, which I don't know of any. So that would be thrilled about that. So, yeah. I used to call it Cwas's single sign on probably 10, 15 years ago when I was kind of just kind of tackling this and trying to figure out how to make things easier before a single sign on  came around and that was basically make the password the same across, make the user ID and the password ID the same across different systems. And then the trick would be how do you keep those passwords in sync? So I think a lot of early on and kind of the IGA space, there were a lot of password synchronization tricks and plugins and tools and things like that. And I think those have kind of died out in favor of shifting password management more to a single sign on type approach, leveraging, that which is more secure and more user friendly, too, and less of a pain for IAM administrators to try and manage.

Jim: I think when you have just a username the same across apps, the password can get out saying you have nothing.

You have a policy that everybody who's a certain user ID format, in terms of kind of simplified sign on, I think, where I see a lot of organization pushing back, as I said. All right. We've got all of these applications pointing to the same Active Directory. So the person has to log in with Active Directory. We apply all the active directory policies. So, we authenticate people that way. But if we go back to password suck, they're not good enough.

Right. They're not a good enough security mechanism because people reuse passwords. They rather than really using complex passwords or something they can remember. And we want to get to MFA everywhere, this isn't just simple, isn't it? Gartner is now saying it.

You know, really, I don't think they're breaking new ground by saying it either. We want to get the MFA everywhere.

Really, the only scalable solution is to have a single sign on the implementation. They think some people will criticize single sign on and say, well, OK. So a big deal. Our users have to authenticate multiple times each application.

They don't really do that much. It's not just that. It's the entire security layer that you layer on top of all of these applications.

That's really where you get the benefit of single Sign On verses simplified Sign On.

Jeff: Yeah. So you've mentioned MFA a couple times as for having a conversation. And sometimes that can be confusing as well. What are your thoughts on that?

Jim: Well, I think that, people are looking for the sometimes the lowest common and you're app MFA shows you when you're talking about internal workforce use cases, though. So while can we just ask people an additional question, like in other words, I log in. Then asked me my mother's maiden name. That is not multi-factor authentication. So just kind of go back to the textbook definition. There are three forms of authentication.

It's something, simply you have or something you are something you are Barometric or something you have is usually your phone or something you know, as you're using password to move it to something that everybody can  understand.

Having to the same factor, like something you know and something you know is not multi-factor authentication and it's not quite as secure is the idea is that if you were to say, all right, my username password or X and Y and then I'm going to put it in my mother's maiden name.

All that is just data that could be dumped down to the dark web where your work could be p.c others by looking at my Facebook profile, things like that.

So it doesn't achieve the minimal bar for what is multi-factor authentication.

Jeff: Yeah, and I'm not a fan of KBA Knowledge-based authentication anymore. I mean, I understand the relevance of it, a decade ago when there weren't these other technologies available or is ubiquitous. But the other thing I see still today, companies making with that sort of authentication or is a step up authentication. And I'm going to pick on United Airlines because I can't because I have to answer these questions all the time. They use knowledge based authentication for a second factor when you log into your account. So I constantly see these because I'm all using different devices as I test things out and they use a bank of questions where they are favorites, favorites change over time.

So my favorite color, for example, which is an actual real question, might be blue today. Red tomorrow. Purple the next day. That's a terrible, user experience when you don't know. And I see that all the time where, what is your favorite so-and-so? And that's used as one of the KBA questions. And it drives me crazy when I see that because of that simple fact. And then you've got these other ones where they're kind of loosely based, like, what did you want to be when you grow up? And there's a  list of things to pick from. And the list might not be long enough to really make it worthwhile. So if you know, even know even the slightest thing about, an individual, you might be able to guess it.

So I'm going to call it United because I think that there step up the Kinnick authentication is not great and they should make that better.

Jim: Just supplying somebody else.

Jeff: Well, I live in Chicago area, so, nice thing about a united in their defense is I can pretty much get anywhere without having to take a connection, which is super convenient.

But the security that they're using for their customer accounts, mileage plus, I think it could be better with regards to the second factor side things.

Jim: Absolutely. And I think one step happening was that somewhere along the way. So one bright idea that led to institute these questions to do step up. So we're not going to let somebody who had their password compromised has their address or something like that without getting a little bit more information. And then they will collect all this information about people for a decade. And now it's like everybody realized that was a terrible idea, but it's so hard to change it now, we have to reach out to everybody. But I mean, I think it's our responsibility at this point is 2020. You've got a load cell phones. You've got a lot of email addresses like start moving to something better.

Jeff: Well, so here's the thing and I'm going to just pick on United again. This is a relatively new development for them. This is only a system that's like two years old, I think. So even within the last two years, KBA has not been recommended by any kind of serious IAM individual, and yet they still roll it out only just a couple of years ago. So I don't anticipate that they're going to make any change relatively soon to replace that. They might add some other options. But, United, what are you doing?

 All right. How about for a last one for the week? MDM.

What does MDM mean to you?

Jim: So I think you mean Mobile Device Management. I think it means Master Data Management.

Jeff: So I'm the opposite. I think of mobile device management first and then I think a Master Data Management.

Jim: Would you think most people think?

Jeff: I don't know because I would have thought on mobile device nation, but I think it depends who you're talking to. If you're talking maybe on the security side of things. Maybe mobile device.

But if you're not in security and you're more of like architect or marketing or maybe even HR, you're probably thinking master data management instead. And there are two obviously completely different things. But both are rooted somewhere in IAM as conversations come up.

Jim: I think mobile device management definitely is very important in terms of corporate data security and being able to create a DeGaulle, an enclave on a per person device. So if somebody wants to do corporate activities on their personal phone, having this, I included, that can be wiped remotely without wiping a person's personal phone and kind of keeping business, at least having a virtual air gap between the two, I think it's a necessary technology kind of feels like it's become more infrastructure than strategic. When you have massive data management, I think that you start getting into you. Well, I think let's kind of start with what master data management and what it does or what that market is really focus on.

And I think the market's focus on primarily being able to take data from multiple sources and feed it to a CRM system. So the kind of classic example in my mind anyway, for what MDM would do, let's say you're a company, you have situations where people to fill out a paper card or then going to a Web site and they can register for a contest.

Another thing is they could sign up for a loyalty program or, potentially like apply for a mortgage or whatever kind of products you have. And then now you have Jim McDonald, he went to the conference and filled out to win a car and went online to get access to a white paper. And I also applied for a financial product online.

How do you know that Jim McDonald in those three different scenarios is the same person? and the MDM solution allows you to define the correlation rules so you can say, all right, well, if he addresses the same kind of fuzzy logic, just the same and the email address the same it's a match with the address is different. The name is spelled differently.

And usually what it does is it uses some kind of numeric if you achieve a certain numeric match, then merge them into the same person. And so that's great for CRM because usually in a CRM kind of like we're starting to see a pattern, he went to this conference and he went online, did this, he signed up for the loyalty program.

And we think he would be somebody that we should call and tell him that, we're running a special that's great for CRM. But when it comes to access management, identity and access management it's all fuzzy, logic is wrong, and we merged the wrong Jim McDonald from these various names and then said, hey, you have access to HR data or something like that or even less than HR data. That's just too much of a mistake. So really, I think that massive data management are feeding data for purposes of customer retention is one thing, but using it for identity access management is another.

At the same time, because MDM has these correlation and you can get very specific in terms of the correlations of email just the same and you have ten different systems and they all have the email address. It's going to be a hundred percent match or is that going to be.

That fuzzy logic is very tight here, very competent badman data you brought from multiple systems with the same person you can merging create like a master profile. That's a lot of what IGA does as well. IGA can pull accounts and tie moments from various applications as well as attributes about that person that are saw on their profile and merge it all into one and use business rules to determine phone number from this system over this system over that system and.

Where I think and MDM really come into play is if you have a very large number of attributes or, you know, you have multiple purposes for the state and not just IAM, but also to feed other systems. Otherwise, I think you have IGA and MDM you'd want to use IGA to be able to correlate this data.

I think the other thing is, is not really an IGA type of scenario. So to me, IGA sinners are best for employee type of situation. So it's, you're going to use IGA to manage your workforce applications when you're talking about your externally facing applications. That's generally not a good IGA scenario. And so meeting MDM is part of an infrastructure to be able to pull kind of all the authorization, information and profile actually information from they have a large number of web applications to build kind of a common user profile.

That is a scenario that could make a lot of sense. Can you then be exposed with APIs. It could be sync back. So you be getting a phone number from application A and sync back to application B. That's a potential scenario.

You could be using some of that profile data as data that gets pass applications at the time of authentication. So I can see how MDM could fit into an architecture, especially a customer IAM scenario. It would make sense.

Jeff: I would be concerned about using MDM for authentication or authorization decisions because I feel like you're building a house on top of another house potentially, which might be built on another house. So how do you keep those things in sync and have them synchronized in a timely manner? That makes sense where you're not getting access to something that someone may not have access to anymore. You know, maybe milliseconds or it could be seconds or even a day. Right. If you sync identity attributes or I'm sorry, authorization attributes into your IGA platform daily. And, that data then syncs somewhere above it into some sort of MDM. You're theoretically already at least a day behind from a authorization standpoint.

So I think you have to be careful about how you would use MDM in that space, but I definitely agree at the identity level attributes around who the individual is. Name, phone number, address, things like that makes a lot of sense. Or even in cases where you're managing things that are not human. Right? Internet of Things, bots, those sorts of things. And MDM might be helpful. Master data management and I should say should be would be helpful. Managing those types of identities as well.

Jim: Right. I think that you bring up a really good point, which is, synchronizing data has definitely drawbacks.

And when I am working on that, architecture is one of the things that I try to avoid as synchronizing data. Sometimes it's a usually trade off and there between synchronizing data and exposing the data. The APIs and potentially making that and operationally required system. So, for example, let's just say that you use MDM to pull data from 50 different data sources and now you have a profile of 500 attributes and you say, well, we don't want to keep those 500 attributes in sync with our access management data repository, so you have a crowded IDP and you'll want to keep, you know, a million people and five hundred attributes, attributions across the cloud. So you say, well, let's open up an API. The problem with opening up an API is now that MDM system would be operationally required. So if you have authentication, then point API and pulling attributes out from that master profile.

In fact, APIs are available. What's going to happen? Well, you have to design your authentication process to be resilient. If it's not there, the process is going to work.

You're going to be able authenticate anyway. They usually will. People are looking for is there access management system to be highly available, say five nines, you know, basically on all the time.

And if you're MDM system or whatever APIs, you create as part of the authentication process are available the same level, then you're going to have some lower service level availability.

My suggestion would be to, if you have to do that, try to build some resiliency so that the APIs are not available, the responding too slow. You can use cache data from the last authentication. Right. There are a lot of the I've seen with a lot of access from products or they have that capability go back into kind of the last successful authentication term and use the data from that authentication. If the API is not available, so that can help mitigate the risk of using a not operational system in an operational way. But even if you have that mitigation in place, you've got to think about volume, if you're having a million Logins a day, do you want each one of those log into to have to go back to your MDM and pull profile data? The alternative might be the up to sync the data, which is the lesser of both evils, I guess.

Jeff: I think it comes down to using the right tool for the job. Right. You can use a screwdriver as a hammer. Not the best tool might work.

And I think just have to be careful about planning between where you're going to store your information no matter what is. Whether it's identity or entitlement or account information between master data between HR Source of truth and an IGA platform. And even directories associated with an access management platform. Try not to get into a situation where you're using the wrong tool for some of the work that it might need to go into making it work the way that you're trying to work.

All right. I think we'd be MDM to death. I think we can probably call it for this week. Anything else that you want to bring up, Jim?

Jim: Just the confusion, it's work day, and people get that confused with Miller time and it's late on Friday Jeff, obviously confused Miller Time with work day because we're still working on this Miller time.

Jeff: Well, I'm trying to wrap it up and you just keep talking and talking and talking. All right. Well, let's end the work day. On that note and the work week and call it for this week. Appreciate everyone listening. If you want to get a hold of us, you can find us at identityatthecenter.com, or you can email us at questions@identityatthecenter.com .. And we'll be talking to you all on the next one.

 

 

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.