Customer Identity and Access Management: Build or Buy?

Okay, can you hear me Okay? Hello everyone. Today we're gonna talk about customer identity and access management. I'm pretty sure you heard that term during this conference once or twice. And what do you actually do about implementing one? What are your choices? For most people, it will be kind of really simple. You just select your vendor or product, you negotiate a fair price and then you install or buy a service and somebody else's manages that for you.

However, what we actually want to share with you today is that the choice is actually a little bit wider. There is actually a lot of considerations that you need to take into account before making that decision. So buying is not your only option. So before we start going into the details, I would like to introduce your presenters today. So my name is Igor Vic. I'm principal engineer with Digital Access Foundation and National Australia Bank. And as you can tell by my receding hairline and the color of my hair, I've been around for a while.

I've been working as a developer, business analyst system architect, and I moved to security and I've been doing SEC security consulting, work security architecture. And then for the last 20 odd years I've been basically working in identity and access management. And between two of us, we have a lot of years of experience and a lot of experience in security and identity management. And now I'll let my colleague Esh introduce himself. Thank you Igor. Good afternoon everyone. Not that much gray hair as Igor, I'm, I'm, I'm Rupesh. I'm the head of technology for digital light and access at nam.

And what that means is that I am responsible for running the authentication and authorization platform for the customers of the of the bank. I started my career as a lamp developer towards the end of the.com boom. Then I went down to work for a large multinational vendor on the consulting arm implementing the middleware and idam solutions and just like, you know, so I've done a f you know, number of roles in that, in that stint across multiple enter large enterprises globally. And just like Igor, I have actually worked on both implementing LA large, IM products integrating, customizing.

And I've also worked on a fair bit of custom development as well. So I've seen both the developer side and the identity side of things. And I think, I must say, since I'm in Germany now, I must say that my first solution that went live was a scripted single sign on solution between the vendor portal and SAP and Lotus Notes. And that was my first encounter with German as well when I was trying to decipher what those cryptic three letter acronyms for SAP table names meant.

With that, I'll just hand over back to Igor. Okay, so we wanted to start this presentation with a good quote that's sort of relevant to what we are gonna be talking about. And I picked this one from Bruce Schneider. And the moral of the story is that it's not about technology. Technology is important, but technology cannot solve your business problems alone. And if your business problem is security on identity and access management, that applies there as well. So let's start with the introduction in terms of the, what is really the identity and access management.

I mean I'm pretty sure you all understand or or know what that is, but I will offer you my favorite sort of definition where the, we consider that identity access management is a framework of processes and technologies. So not just the technology and the real task of any identity and access management system is to ensure that the right users have the right level of access to the right resources.

And when I talking about users, I'm talking about about humans, you know, end users or consumers and the machines or systems and customer identity and access management is about managing external users or consumers and their identities and their access to resources. There is also a workforce identity and access management kinda type of platforms that are dealing with internal workforce or employees. And they're actually similar in some aspects, but in in a lot of aspects they're very different. And so today we're gonna only talk about a customer identity and access management.

And for any organization that's dealing with consumers or customers, the getting the customer identity and access management right is actually critical for business success. I think we can all agree on that. And when it comes down to actually building or implementing a platform to do your customer identity and access management, there are many factors that influence that decision, but it really comes down to making the right technology choices for your particular business context. So what are the actual options? They're obviously a buy option.

You can just go and buy a service or you can buy a software, get a license and then install and manage it yourself. You can obviously build your own system. Typically you'll design and build the core components, but you'll not build a like a commodity components like databases and API gateways and stuff like that. But there is also a hybrid option where you build some components and then you buy the rest or the other way around. Typically you will buy core components and you build the UX and some core components yourself that, that are are needed maybe for integrations or things like that.

Now that we got that options defined, before you actually make a decision, you need to start your evaluation process. And this is another quote around one that I found on the internet that basically is summarizing in a pretty good manner that evaluating your options is not necessarily about making the best choice. It's basically about understanding the trade-offs, the risks and benefits. And if you can can achieve that, then you can actually make a pretty good choice, but you also need to be prepared to handle that. If you make a wrong one, you need to have a plan B.

So now I'll hand over to rupesh to take you through the, the details of all the options. Thanks. Thanks Igor.

Before, so for the three options that's been presented before, we have sort of tried to split that into reasons to consider, reasons to avoid and and risk factors. But before I get started, you know what, there is no such thing as pure buy unless for, you're talking about the simplest use cases where you sort of like a startup who's just implementing something like say AWS incognito and just, just running with it. For any real use cases, any large enterprises, there is a certain degree of integration and customization that's always at play.

You know, irrespective of, and again this is not like, you know, this is not a line with three distinct points where you know you're on buy, you are on build or you're on hybrid, it's, it's like a sliding scale where you sort of, you know, go from one end of the spectrum to the other. Now coming to the buy option, and I think you know, the, some of the reasons to consider is that obviously there's a really short time to market, especially if you go with, even with the buy there, you have the option of apply, you know, SaaS options as well as, you know, deploying it yourself.

There's a short time to market and a low initial cost. And you know, there is no, like I am, development skills are required if you go down the BI path that the reasons to avoid would be there is a high, you know, ongoing cost and limited flexibility. The integration can sometimes be complex and costly, especially if you have a lot, a lot of legacy to deal with that may require some non span, non-standard bespoke kind of integrations or extensions.

And again, like before I get, so the control over product features is, it is a function of your relationship with the, with the, with the vendor and how much influence you have with the vendor in being able to influence the roadmap. And you know, and consequently there may be a long time to change and a high cost of change because you may actually have to go through the vendor's, you know, process for enhancement requests and prioritization and backlog management. There is.

And then the other, the, the other reason one of the drivers for that could be if your market is like in the grand scheme of things not too big for the vendor and you overlay that with very specific regulatory requirements, it's specific to your industry or to your market, then these may be the reasons to avoid because they may not actually feature high on the priority list of a, of a vendor. And then there's this question of, you know, the vendor entanglement pieces as well.

And again, like I said, it's a sliding scale and there are things that you can do to reduce the amount of vendor entangle entanglement by doing things like not coding directly to proprietary interfaces being, you know, standards compliant to the extent possible in all integrations that you do. Risk factors are, you know, obviously the vendor going out of business, you could potentially do some contractual agreements like contractual arrangements, like escrow arrangements to protect yourself from that risk factor materializing.

You could have product discontinuation of product changes, licensing model changes, fees increase, or you know, support level changes or support fees increases.

And some of this typically, you know, could be driven by a significant change in the product roadmap for the cus for the vendor driven by mergers and acquisitions and other, other use cases and some of the subscription based licensing models where you, when you're going in, when you're starting small, they may be very cost effective, but as you go up the slides and if you become successful then quickly it becomes more, more and more expensive. So the initial cost is low, but longer term we may end up paying more.

So again, I think the, to summarize this could be the right option if you don't have special or complex requirements and you know, the, if you, and this is the only option you have available if your, you know, company doesn't have a lot of in-house development skills or expertise. Now the build option is, as you can see is sort of, you know, gives the flexibility to change and integrate as required. You have full control control over the platform features you have relatively low cost of ongoing changes because you know you have the capability.

You, you know, and again when we say build right again to make sure that you're doing this in an interoperable manner, your standards compliance is very important here as well. So you know, you should be making sure that you're sort of building to implementing standards instead of, you know, cooking up your own IAM system on the site. And some of the reasons to consider here would also be, you know, that if you are in a small market market size and where you have very specific regulatory requirements that's specific to that, that geography.

Now reasons to avoid, again, there is a longer initial time to market high initial cost. And the very, very important one is if you have limited or no I am development skills. And I would also say that, you know, it'll also depends a lot on how mature the organization is as a, as a technology. If they have mature DevSecOps practices, if you have mature SRE practices, if you have mature frameworks for front end and microservice developments, then you know that's, that's a key success, that's a key criteria for determining whether you do a build option.

And the risk factors is again, losing executive support and the inability to acquire or or maintain such skill developers because you know, this is actually a special skill. You know, it's not, you know, you, you would need people who are not just good at developing staff but also understands all the protocols and standards and also things like cryptography and all, all the, all the things that go with it. And once you could, even if you get a normal developer and upskill them, you also have a challenge of retaining them as well.

So going on to the final option of hybrid approach and again, hybrid is sort of a combination of the previous two that you have seen. And again, it all depends on which of these come into play, depends on which end of the spectrum you're going with the hybrid approach. So you could again still have a relatively short initial time to market. There's a manageable initial and ongoing cost and you have some flexibility and control over platform features.

And again, re if you have a like small market size or specific regulatory requirements, you may also look at hybrid as an option. Reasons to avoid again, because even hybrid would require some amount of, you know, in-house development skills and you know, maturity and engineering frameworks, you wouldn't go down that path if that's missing. And risk factors are again, a combination of both buy and build, you know, you could lose executive support, you inability to acquire, retain skill developers and all the, all the other, you know, concerns related to vendor.

I think and, and like I said, right, it all boils down to with with hybrid as well, you know, it all boils down to which end, you know, how much of a customization you're doing here are we actually looking at, so in, in all options we are not talking about, you know, building commodity software from scratch, right?

We are not building a directory, you're not building a database, but it's more around what do you do with the services tier or do you could also have an option where you just use a services tier from a vendor but you own the experience fully and you know, so it sits, you know, and there is no one size fits all. That's the key message with that I hand over back to Igor to summarize.

Okay, so it really comes down to, if you look at this table that summarize all the options, it really comes down about making the, the trade-offs. And in order to make the right trade-offs, you need to really understand them and you also need to understand your business requirements and your business context and depending what's important to you and to your business, you might choose those options and then you'll have those trade offs pretty much. Now one thing that I would like to kinda maybe focus on in this table is the risk factors.

They're typically not well understood when you're making those decisions and if you, let's say just for example, we look at the bio option for instance, nobody really talks about what happens with a vendor merger and acquisition activity.

And then you basically end up with a product that's no longer supported or what happens if the there is a product changes and the roadmap actually goes to a different direction that you really want for, for your kinda requirements when it comes to, to build the executive support is probably the most important risk factor or something that you need to make sure that you have because that actually keep your team alive and provide the funding ongoing for your maintenance and, and keeping your, your product features coming.

Obviously you need to also make sure that you retain your, your skill sets, your developers and that's also very important. And most people treat the skill developers as a commodity, which is actually, when it comes to niche kind of skillset like identity and access management is not really correct way of thinking. Training new people to actually be able to develop security related software is not an easy task. So the hybrid option obviously has got a combination of those two risks and really depends which sort of end of the scale you actually make a cut, so to speak.

So potentially you could end up with all of those risks in various kind of amounts. So really comes down to assessing your, your business context, your requirements, and then understanding your trade offs and then you can make a decision but be prepared to be wrong. Any questions?

I, I, I think, I think there are a couple of questions. I think the first one was from the back. Here's one, here's one. We need to be a bit quick with the questions, but Yeah, so this is a great presentation. What about open source software? Would that be billed by? What Is that?

No, open source is a key component of some of this stuff. So, you know, like you wouldn't be writing your own jot library for instance, right? So I think, and again, you know, it's all again the maturity of the systems of, of your, your security infrastructure as well that you have in terms of doing composition analysis of the open source software and deeming that it's safe for use.

So, you know, typical, you know, open source implementations that are deemed safe are part of the package. And so for instance, like like you wouldn't actually write your own, you know, LDAP access library from j and DI directly, you would use a suitable open source library. Okay. I would say we can take one more question. I think here are some questions in the front, one more and then surely you both will be a bit around so you can directly discuss with them, reach out to them via the app. But in the interest of time we pick one. So thank you for that.

I'm really wondering if you have to keep up a team for having or building the software. It is, it's in the end cheaper because in ongoing costs you said it's low, but with security products you need to have a team which can react fast because security related software needs to get, be always on the top, get patched and and forth.

So there's a bigger effort than probably something other, and I don't know how you say it's low ongoing costs because such a team, high skill team operating it, having on time seems difficult And I could argue look at the cost of co developers today for the homegrown stuff. Yeah, Well even if you buy a product, you'll probably end up doing integration yourself or paying somebody else to do the integration for yourself and then you'll need to maintain those integration components.

And so yes, the size of your development team will probably be smaller, but you cannot get away with, without having any kinda either or outsourcing that function or having it in in house. So there is a cost involved that basically is ongoing development for integrations.

So you, you can't avoid that. Now having your own development team, as you rightly pointed out, allows you to react very quickly and to changes that you need. So you only have to wait for third party organizations to come to the, to, to, to the rescue. Okay. So thank you very much for your presentation.