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

PODCAST37
 
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.
 

In this episode, Jeff and Jim talk with Andy Clark, Principal Consultant at Okta, about access management including the why's of OIDC and SAML, scopes, and flows. To register for the free virtual Oktane 2020 conference, visit https://www.oktane20.com

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 #37 Full Transcript:

Identity At The Center #37 - Access Management with Andy

Jeff: Welcome to the Identity at the Center podcast. I'm Jeff and that's Jim. Hey, Jim.

Jim: Hey, Jeff.

Jeff: You survive?

Jim: I survived. My identity is sheltering in place, so my personas are all over the place. I can't take responsibility for all of it.

Jeff: The crowded house.

Jim: Crowded headspace.

Jeff: So what do we dive right into it? Because we have a guest and his name is Andy Clarke. He's a principal consultant at Okta. And he's here to help us navigate some of the questions that we might have around some of those use cases that they get into. Open ID versus SAML and some other things. Welcome to the show, Andy.

Andy: Thanks, Jeff. Glad to be here.

Jeff: So we've met as part of a deployment that was being done at work on for mutual customer. But I know that you've been in the IT space for a long time and maybe more specifically IAM. Can you talk a little bit about when did you get into IAM and how long have you been in it?

Andy: Sure. So I've actually been in IT space for a long time, over 30 years of private, and IAM for about 10 years in the last five of which has been with Okta, thinking back on this, it used to be that almost everyone who was in a developer system architectural was actually into identity, because back in the olden days, most of the applications had a built in, might have been backed up by database or something. But pretty much every application had its own unique user name, password, its own experience.

And this whole concept of identity and access management wasn't really there. It was something that was kind of gradually evolving over time where we were able to start taking away that identity piece, which was too much being duplicated and not always very well from application applications, say, hey, let's just make this, a kind of a skill set and the discipline all on its own. And let's get very professional about it, best practices, the best protocols and stuff like that. And kind of, it created this IAM space that people like myself that had been into it from the developer side, doing individual client applications and stuff. Now, I kind of just kind of pivoted over. So now I said, OK, I'll be the person who chose Identity and everybody else can use it.

Jeff: So it seems like most people kind of left of them. This is my theory is that most people kind of fell into the IAM space around 10, 15 years ago because of that kind of a need to is more of a business need or security need or, some sort of requests to do that.

So I'm going to count that, that you weren't born and baptized IAM you just kind of fell into it like other people.

Andy: Right. Well, exactly. You said, I was working on a large product in the health field and, it had its own built-In identity and stuff. And, they had their own directory services, active directory for that place. And they like,  why do we have to do thing twice? why do we have this for our email and stuff like that? And then we have to do something else over here. We got to remember, know the password. Of course, everybody wrote him down a Post-it notes. So the whole thing came as a request saying, is there any way we could possibly kind of tie this into our system? So eventually as an organization, we kind of pivoted to that and we gave them the option that, hey, you could have this thing just tied to your thing. So that was where the original inbound federations had ever worked on. And that was almost 20 years ago.

Jeff: So what was it about federation back like back then? I mean, I don't think active director was around Novell.

Andy: It was. So if you think of the original active directory and they go Windows Server 2000 actually went back to NT. So there was this foundational directory service where it wasn't quite as Polish as, say, EDFS right now. But LDAP, this stuff has been around for a while. So, a lot of these bigger institutions say they had these big directory services and they had all their employees in there and they use them to do like desktop applications and stuff like that. But, we were an external thing that wasn't part of a desktop and we got a bridge somehow. And so we were able to do it. And, obviously was met with big round of applause or I was very happy. So that was my first introduction. OK, this is the way it really needs to go because, just from a consolidation standpoint, it's kind of what has to happen as we got more, more digital and there's more applications to have all these separate entities and separate passwords and personas, as Jim was mentioning earlier. They have all these separate personas. It's just too unwieldy after a while for the user and for the IT people trying to maintain it all.

Jeff: What have you seen that has changed from then till now?

What is the biggest kind of evolution of that space?

Andy: When you look at back in earlier days, you didn't really have the protocol. It was pretty much every application for itself, a lot of things were back ended by databases and stuff like that. And a lot of the implementations weren't all that good. I mean, I've come across systems that had back in databases where all the passwords were in clear text, that's not a good idea. So, one of the things that you see now is people are just much more cognizant of identity and security and securing your both your assets, your content and the potentially the personal information of the different users, whether it's credit card information or health information or something like that, with all the news that we've had over the last couple of years about all the different hacking attempts and all the stolen data and stuff like that. We're just so aware of it now that the need for professional implementation, where this stuff is done right, not just left to somebody, is your idea of the day. I think that's really kind of taken hold in our society. And people are really not just expecting it, but they're asking for it. They want the second factors. They want to know their data and their information is being secured properly.

Jeff: We want to talk about some of those Access Management Federation protocols, but just not to get too off on a tangent here.

You said something nice. Now, that kind of piqued my interest and it's people asking for second factors MFA etc. and I still find that a lot of organizations do not necessarily take that same point of view when it comes to their customer base about making sure that it's offered as part of their service, not necessarily mandating it, but making it part of their authentication service for their online credentials or online identities. Do you see the same thing or am I looking at it from a different perspective?

Andy: It's if you look at a couple of years ago, so Okta has always had second factors available. We keep adding more to it, but we've always had something available. And, in years past you when you were kind of showing, okay, here's the future that you have, we can do this and a lot of it. Well, I don't want to I don't want to hurt the user experience. That's too much friction. I don't really want to do that. But as time goes on, especially like, say, the last two years now, it's like the end user is expecting their stuff to be very well-protected. So I would say the vast majority, especially of new stuff that I'm doing, the vast majority, they're actually saying we have to have an offering now, because if we're not, we may lose these people like this as a potential customer for me. But if they think that we're not taking care of their data, they're going to maybe go to my competitor. They're going to go next door. They're going to do something else. So we find that maybe they're not it's not mandated. But they are definitely one offering it. And a lot of the surveys that we do and the different the feedback we get from the different IT people and the business managers is that they are not getting the pushback that they got, maybe even three and four years ago, just because people are so much in the news people are just really wanting to know that their data is well protected and they're willing to go through the hassle of having an app on your telephone, on your smartphone or to have a FOB or to have something else that they need to do. The barriers for, especially with younger people that they've gotten so used to it that it's the second nature now.

Jim: Yeah, I think you're hitting on it there. And it's amazing how quickly you tide this turn. But I think it's part partly that the technology has gotten easier, but I don't think that is it as much as it's ubiquitous since everybody has done it had to do it somewhere. You had to do it to make your G-mail work or you had to do it to make your banking site work. So now to do it for some other site, that's a maybe a lower level of affiliation. They're not protecting your financial assets, but it's still important information going ahead and using the second factor isn't as much of a hindrance on the user experience.

Andy: So Jimi, make a really good point there. Depending on the industry, we see the adoption taking place at a much different rate. So you mentioned, a banking industry or maybe healthcare where you have very valuable data, your money's in there. You don't want someone to get a hold of that. You don't own making withdrawals from your bank account in those places, the barriers to the extra security levels, they broke down very, very fast. Now, other things that were more just informational or trying to kind of protect some content, that's a little bit slower in coming. But yeah, you make good points there. Depending on the industry, the barriers to the friction that people are playing against have disappeared much, much faster.

Jeff: I think Apple deserves a lot of credit for the improvements to the MFA experience because they've really kind of forced that on users, but they made it relatively easy to use from a you know, even my grandma can use the MFA that Apple has introduced and it's gotten more into the psyche of the public of why it's important. I think that education helps. But also, the user experience is a big part of that because people will just find ways around things if it's not easy to use.

Jim: Andy mentioned another thing which was around Okta having this capability for many years. And I think most of the single site on our access management vendors have some way to solve the problem, but it's gotten easier and easier every year. And now for customers to deploy that technology in a kind of low or friction model becomes easier and kind of uses as a transition. The same thing with implementing federation protocols. So if you rewind the tape 10 years, SAML is the only federation protocol or the main one, I should say. And it was a little bit of a mystery, I think, for motion as well as you as you'd learn something and then first start getting accustomed to it. It seems complex. While all the tools that are available to have made integration with SAML a lot easier and OpenID Connect is kind of the next wave. And Andy, I think you're working with a lot of customers show up to integrate applications. And I'm wondering kind of what is your framework for thinking when you're determining whether or not SAML is the best protocol to integrate with or using OpenID Connect. What is your framework for thinking?

Andy: So, SAML is a good protocol and it's been around for a very long time. Like I said, it was one of the first ones that came out. But like, like many things, things improve over time. So OpenID Connect, which is built on top  OAuth. That's the improvement of SAML. They can do everything SAML can do, plus a lot more and you can do it a lot better. And it's much, much easier to work with. So the implementations of that is that the SAML has a level of friction for the developer who is trying to incorporate it, but they've kind of removed all that for for OpenID Connect. And because it's an actual add on to OAuth now, you kind of get both aspects of it. You've got the authentication aspects of openID Connect. But on the base, on top of the same protocol, you also have the authorization aspects of OAuth2. So now that you can kind of take care of both halves of a modern application, you can use Open ID Connect to authenticate to users so they can get into your client application and actually, start seeing content navigating. But then if you're trying to use something that's of the back end Web servers, micro services are very popular. So if you're trying to do something and pull information, say you're banking information or transactions or maybe some of your health tests, you're trying to pull that off a remote service. Now you have OAuth which is able to protect that leg of the journey, but yet it's all done from the same initial interaction with your identity provider.

So you can get your ID tokens, your next extension, and now you've got the full breadth of the protection that you need. We're SAML. Really didn't have all of that. It just had the beginnings of it, which was great, but it just didn't have all of the capabilities that OpenID Connect and OAuth have. Because if you look at something like OpenID Connect when you're making their request, you can actually specify via Scope's exactly how much information you want delivered back to that application. So if you think of it from an integration and IT standpoint, each application gets only what it needs for it to operate efficiently. And you don't get all the other information that maybe you don't need, but another app it does need. So you can use a single integration and kind of fine tune it for each application, but yet it's only one integration. Whereas in the NEIL and SAML world, each one of those would have to be a separate integration because everything was hardcoded and you didn't have that ability to kind of do things, nimbly. And it was a bigger IT burden. So now we've kind of come this full scope here was like you were saying before, we've made the technology much easier to use. It's much easier to implement. And you're actually more secure at the end of that.

Jim: It feels to me like there are still a lot of cloud applications that only support SAML. I would imagine that's part of the framework of looking at it is like if the application can only support SAML, there's not really a debate to be had in terms of, if you're not necessary as you say, it's a custom built application. You could choose SAML or OpenID.

I got the impression from what you're saying that you feel that OpenID is an easier integration for the developers. Is that what you say?

Andy: Much easier. Yeah, with modern libraries and things like .net core and the latest, it's literally about 10 lines of code. You could put OopenID Connect and OF into your application. So it really doesn't take any effort whatsoever. So there's really no barrier from a developer point of view to putting it in. It's Larry just there. If you just say type of few pieces of configuration information. So it's almost to give me, having SAMl in the field, which you most of the large applications, you know, all the salesforce and the concur box, they all SAML because they were designed at some point ago. They will probably eventually move off that going to OpenID Connect, but the use of OpenID Connect for greenfield new applications is pretty much 100 percent unless you have a large development stack where you want to just keep everything the same until you make your transition from the older stuff to the newer protocols. Unless you're just trying to keep parody. I would say, 99 percent of all greenfield applications will use OpenID Connect and OAuth instead of SAML.

Jim: So, in my experience in an employment of Cloud IdP in my terms is that you can have a mix of SAML and OpenID Connect. So for example, there is a use case where we want to federate with a partner and that partner has their own IdP, and from our Cloud IdP, we've got applications integrated be OpenID Connect those people could use SAML to authenticate into our IdP and then get into the Open ID Connect application. That's a valid configuration, right?

Andy: Correct. So using something like that, where you going from one Identity divider to another, eventually to a target application, that type of. We call it in-bound federation. Yeah, that's still very, very prevalent. And just like  you're going the last mile to the Target app in SAML, you can also go OpenID Connect and you can also go the first mile. So if you want to take a hop from the original IdP to intermediary one, that could also be OpenID Connect as well as SAML. So if you look at the evolution of things, the ecosystem is now basically supporting both because of all the legacy applications that we have, but yet they're offering the new stuff. So as the industry matures and applications mature, you'll see it goes from probably 90 percent SAML, now with all the that it's stuff that we have. And over time that will switch until eventually it'll be 10 percent SAML, same way that I, WS-Fed has kind of just gone down to just a few Microsoft products. Even the Microsoft products support SAML. Now, I think we'll see that shift over time as the newer protocol kind of takes over for the older one.

Jeff: I want to go back to. You mentioned the word scope's. Can you explain what that means in the concept of OpenID?

Andy: Oh, sure. So if you think of a client application as wanting to authenticate this user and get some type of information, maybe they need to know, what city they live in so they could drive some of the content or they just need some kind of information about the user, but they don't need everything. So the concept of scope is a way for the application that is requesting the user to be identified in the form of an ID token can say, I need to see this information about the user. And that way the IT people can set up their policies in such a way where this is OK if this application is asking for something. This is all that they're authorized to get. This is only the mission I want to give that particular because I don't need anything else. So the scope allows the calling app to request just the information we need that the least possible set of information and not just get the entire basket if they don't need it. And it gives the IT. people a way of kind of controlling that we have some things here that, may be more sensitive, These are less sensitive. You can only have what you actually need. So it's really a way of giving some more fine grained information about the user so they can kind of control the dissemination of, what could be potentially sensitive user stuff.

Jeff: You mentioned that's controlled by policy. The I guess the data source. How exactly does that work? Well, policy is it and where does that get managed?

Andy: So obviously, from Okta, I know how we've implemented it. And in our it's called an authorization server, which actually means the tokens that are sent back to the client application. So in our implementation of an authorization server, we look at the incoming request and everything is identified by a client ID in the OpenID Connect world. So we look at the incoming requests, the client ID, the user that's trying to get the access, they would look at the scopes and then we just have a system of policies, kind of a hierarchical framework that says, OK, for this particular client ID. For this particular user, we're going to allow these scopes to work. And if it meets those criteria, we maintain an ID token, we send it all. If it doesn't, if they ask for things that they're not allowed to get. Everything's blocked or we can require a user consent to allow more information to go forward. So you have a whole set of controls now that you can kind of protect what you're giving out about the user as opposed to SAML it as an earlier discussion where it was all or nothing. You basically made requests and you got the entire basket every time.

Jeff: So it sounds like there's then a way that the user can directly influence what information they want to share with that service, providing that option is set up on your authorization server.

Andy: Correct. So if you think of it, these three different parties involved here without going into a lot of the terminology. You have the user who owns the data. It's their stuff. You have the client application, the developers are creating that who says, okay, this is information I'd like to have to have a good user experience, and then you have the I.T. people who are acting as a broker to say, OK, here's what I'm going to allow through and here's what I'm not. And then the idea of user consent gives the IT people and the developer a chance to say, we'd like this information if we're willing to give it to us. So now we're putting some of the control back into the hands of the end user so that, they can decide for this application, I'm going to let my city and state go through. But for another application, I'm not. So really,  it gives the tools to each one of the interesting parties in order to kind of control what they need, how they're going to get it. And, for the user base, so they'll know that I allowed this to happen or I'm kind of. Hold it back.

 Jeff: And then what about the term flows that comes up often between OpenID Connect and SAML? What does that mean?

 Andy: So would flow is its way of getting to the end product you need, which for SAML it's an assertion for a OpenID Connect or OAuth it's a token. And in the old SAML world bases, this is one way that it worked. You sent a request and you got a response back when you go into the more modest stuff like OpenID Connect, there's a couple of different flows depending on exactly what type of application you have and what kind of device you're on. So if you're on a single page application where everything's in the client side and  you don't have any ways of holding secret information there, certain flows that allow that to work securely without giving away information that people could just see in a browser. If you're on server side, you have different controls, you have a little bit more secrecy so you can use your higher orders of protocol protection. Basically, both the front channel and back channel in order to give an even more secure flow. And then you also flows that are designed just for like machine to machine communication. This server wants to try to get information from another server. It's really not a user context at all involved. They just want to protect that communication channel, but they want to do it in a very organized ways where there's a certain amount of expiry. They don't want to just give the username and password. It's good all the time. They want to have something that hey, you can only user for X amount of time before we have to re-evaluate and you're only allowed to get certain information. But, not everything for this particular servers, but more for different service. So these idea of flows are just ways of taking that SAML approach, which is one size fits all. And now we have separate flows for each of your independent use cases.

Jeff: Interesting. All right. I hijack that, Jim, go for it.

Jim: No, that was great. That was really good. So I guess and a couple other things, future trends in IAM so kind of what are some of the trends that you're seeing? To me, the elephant in the room or the thing that's always been so key to the choosing the right CIAM platform has been around user management, the ability to get people on board, things like that. I feel like that's a trend that the identity provider, cloud identity providers are now kind of building out those capabilities. But one, to see that if you agree with that point and then other things that maybe you're seeing, things like analytics, machine learning, things like that.

Andy: I agree with your point there. So there's a lot of things that we know we see as far as, the trends and you know what customers are asking for. So,  if you have  an IAM platform of some kind. You want to build the best practices into it and have any platform like that. That's kind of dedicated to that, the platform itself is able to kind of keep up on, what's the latest protocol?  what types of things have happened in the industry that identified a flaw in that identity platform can fix so quickly and easily and then allow the end users, the end products not to have to worry about those details. So if you think of the old school where you had a server on Prem and then you did monthly yearly updates to it, well, it could take a long time for a security flaw to actually get patched up or anything. Think now with the cloud based IAM solution, that stuff can happen pretty much as soon as they figure it out. They can put a patch on and you're always very, very up to date. What are the other things that we do see a lot is that, as you were talking before, in a lot of applications had their own independent identity system, lots of organization, especially a larger, older organizations that might have had a lot of mergers and acquisitions along the way.

They might find themselves for, four or five, six dozen, a hundred different identity stores, they could have three or four ELD apps for external customers. They could have multiple active directories because they merged with other companies. And if you could think of the  difficulty for IT person to say, if I need to restrict selling because we have a possibility of the account was breached and I want to take away their access privileges, but maybe they're spread across six or seven different directory structures, how hard is it for them to do that and how many different places and how fast can they react to a potential breach when everything is so dis parents and their separate systems that have their own protocols involved and it's just hard for people to manage it. So one of the trends we're seeing is that a lot of customers, in order to have that unified management where they can be very nimble, they can protect their users better because it's all in a centralized place.

They're actually trying to consolidate all of these disparate directory structures and identity platforms into large one that can handle everything. I can handled delegated authentication back to something if it has to this nice transition. But it can also hit many different kinds of targets App, whether they're the older SAML, the newer OpenID Connect the machine to machine stuff so that the ability for the IT people and the secure the CISOs to actually take that large base they have of users and get themselves around it and put,  coherent policies in place, have whatever initiatives they have, maybe it's for things like, having a second factor or zero trust or having some type of,  velocity policy where, they can check if people are, in California to it in New York, the next minute, they can have all of these new things that we can detect now and to put those on all these other disparate systems that are older technology just wasn't even practical. They couldn't get their arms around it. So the trend is really to trying to get everything into one place so that they can have at least a half a chance of actually managing it in some kind of coherent and timely manner.

Jim: Do you have a rule of thumb for how much data putting in your IDP, your director the product you have is the universal director. How much data can you realistically put into that? Verses You want to keep you in some other store and make it available by API or some other method.

Andy: So you can actually put them in our system. We can put in five bag per person in there so you can put a lot of information about the person, we tried not to put too much, application centric, because then it kind of takes away from the idea that this is an identity platform, not a user repository or a. Repository for information that's very clear and specific, we don't want there, banking transactions and Okta. So we try to keep it identity centric. But one of the things you mentioned brings up good point. There is information that you don't want to store Okta because potential is too sensitive. Would things like GDPR and stuff like that, you want to kind of not spread your data out too far? So in Okta we have a thing called inline Hooke's, whereas like say before you enter your token, you can actually use an API call, go off to another system that maybe has like very sensitive information. Maybe it's some if your health data or some financial stuff. And it will get minted into the token and then sent to the client app for consumption. But Okta never actually has that data. It's not part of Okta. So we can have your Okta data stored to be really just things about your identity that you'd probably want to share among all of your applications. But then the very specific stuff or very sensitive stuff you can now put somewhere else. But Okta will actually wink out to it dynamically real time POY and minted with the signed security token before it delivers it. So really kind of gives you a lot of flexibility in just how you're managing your data, where it's stored, how it's used and how it's disseminated.

Jeff: So speaking of flexibility, I certainly appreciate the time to be able to give us today. I know that Oktane was going to be coming up here in a couple of weeks. And I know Jim is heartbroken that he's not going to be able to make the trip out to San Francisco. I guess I got a couple of questions. The first one is really more a comment. And I think that's, Okta is really early into the process of the current health situation to cancel their conference. And lots of other conferences have kind of followed after that, which I think is a good thing because it provided a lot of clarity for people who weren't quite sure, what to expect, especially a few weeks ago when was announced. And now it's being turned into a virtual conference, which I believe is free for anyone to attend, but as long as they register. Can you talk maybe a little about what your expectations are out of that?

Andy: Sure. Yeah, happy to. So he definitely was not canceled. So like you said, it's been turned into a virtual event. I guess the good part of the silver lining is, is that now we can make it available to many, many more people. It is free now. So, you got to pay a registration fee. It basically frees you up for the cost as well as the logistics of actually, San Francisco's a wonderful place to visit. But if you're busy and you live in New York, it's, a little bit of a time commitment. So basically, we were freeing you up of the costs and the logistics. But as far as the conference itself and the offerings, all of our keynote speakers are have signed up to do it virtually. So instead of seeing them on the main stage, they're going to be doing in a studio and then broadcasting it live. So like I'm very interested in seeing Colin Powell. He's gonna be one of the keynote speakers. And,  as a secretary of state, I'm sure he has some interesting viewpoints on what's happening in the world right now with the virus and everything. So all that's still gonna happen. All of our partners are still going to be there.

So instead of having a booth set up where you can go over to talk to somebody and see a little demo, it's now all going to be virtual. But there will be people there life that will be able to take your questions, talk to you on the phone, text with you. They can give you demos through the Internet interface. We have a short demo of it today. It looks really cool. So it's kind of kind of a fun thing. Not quite as easy as being there to shake hands, but since we can't shake hands anyway. It's not a bad experience. And just a lot of like really cool products that they'll be announcing. So, as far as,  missing out on the opportunity to go see the Golden Gate Bridge and Fisherman's Wharf, there's still a lot of really good content with good partner interactions and just all the breakout sessions. Everything is still there. It's just in a different format. So that plus it's all available, if you can't make the life, everything's gonna be recorded and provided to you, So, if you are busy, you can watch it later on that day or the next day.

Jeff: That's really cool. I'm really interested to see how this turns out because Oktane usually is one of the bigger driving conferences out there. And I have a feeling this may add to the numbers that you probably see as far as attendance goes, especially with people being asked to stay at home and looking for fun things to do. Right. No better thing than an IT conference online.

Andy: Exactly. And like I said, they're really working hard to Okta as a remote digital company anyway. So we already have people that know how to do this.

And there was a lot of stuff that like the just a lot of pre-conference training that we do, training classes for certifications. Well, that was always going to be remote. I mean, we have people coming out there and they were hands on seminars for that. But that's something we offer every day remotely. So we already had the technology. We already had the Know-How. So we're just expanding it now to do these other things. And like I said, I saw a demo. It's really kind of cool. I also miss the opportunity to go out to Fisherman's Wharf. But I think they did a wonderful job and that, they're very creative. It's visually stunning. It looks very good. Like I said, we have all our keynote speakers, all the different breakout sessions, all the partners. They're also there. They're all going to be available. And, definitely make the most of it in this kind of changing environment. We have.

Jeff: Yes. Very cool and looking forward to it. I certainly appreciate your time. Jim, do you have any last questions for Andy before we let him get back to the real world?

Jim: No. I mean, is there any canned lobster bisque that we should get to eat while we're watching? It's not going to get fisherman's worth.

Andy: Most definitely. If I find anything good, I'll definitely put it up on your Web site, but I'm gonna make the most of it. And being here in Ohio, I'm pretty far away, but I'll be there in spirit.

Jeff: Well, well, Andy, we appreciate it.

Andy: Thank you very much for having me.

Jeff: Yeah, we'll go ahead and leave it there for this time and we'll talk with you folks the next one. Thanks for listening.

 

 

 

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.