And as I've said, my theme is the future of access management. The title of my talk is beyond passwords and beyond static entitlements. There are a ton of things to talk about when we look at where access management is deciding. So I'll concentrate on very few themes and I will walk through them rather quickly. What I wanna start with is with some deconstruction of the term access management. So what does it mean? Or what could it mean? The challenge we have is that this term of, of access management is in some way, totally overloading.
There are so many different meanings and different usages of access. So if you look at that, we have identity access management, access management, access controls, and so privileged access management. And one of the challenges to face in, in, in also broad is what does it really mean? How do you use the terminology?
And I think it's very essential to have a well defined terminology today. We will focus on one aspect or touches a minute, which is really the, the web access identity Federation, adaptive dedication, parts to runtime access management.
But when we look at it a little bit from a broader scale, so within identity and access management, we have this area of IHA. So the identity governance and administration, this is sorry, tend to say the deploy time identity management, it's about creating an account set. So creating a digital identity first, maybe assigning entitlement. So it is about aspects such as where access comes in.
There's, there's the lifecycle part, but there's also access governance. And that which is about entitlement, which includes access review. So a couple of these access terms are here. On the other hand, we have this runtime access management, and that is where we look at web access and identity Federation at the core, but also at access policies and for runtime access management.
We also look at authentication where access doesn't appear into term. So we have to access policies.
We have access controls on the other side, as what we create, what we manage with these technologies and some of related to the access governance, which looks at static entitlements and systems and applications. We have also data access governance, which looks at who can do what with which data we have to privilege access management as another theme. And somewhere between this runtime access management and privilege access management, we have to trust in time access. So we have a really complex picture.
What do you look at, as I've said today is at least where I will look at in my talk is at the sort of access management runtime part and Federation web access management, looking at the policies trust in time access and growth education team, which is not in this picture because it doesn't include the term access in its name.
When, when we think about access management about this part of the broader identity access management, then one of the things we we should ensure is that we have a modern access management.
So many organizations started many years ago with the charity towards access management. And over time, there has been a lot of change. So the platforms which support access management have evolved, there are new layer in the market. You entered just the entire cloud, seeing for both deployment of access management and use of access management. So all of the fundamental questions clearly is how does a modern access management look like? And I don't want to go into every detail here.
When you scroll back through all the recordings we have from Casey life events, you will find, I think at the very first Casey life event or the second one, you will find something around identity fabrics, where you go more into detail on this concept, we have defined for modern identity access management, which is the identity fabric.
And in this concept, the access management part is a very essential element, very central component, because at the end of the day, what is the Shopify identity and access management, it's about providing access to everyone and everything.
So every everyone, everything on the left hand side of the traffic to every system. So every single the right hand side in the middle sits what identity and access management is. And in that identity and access management, you have things like the identity wedding, like the identity Federation, like adaptive authentication. So have a couple of elements which really fall into this sort of part of access management in the sense of this runtime access management. And this is about really providing seamless yet secure and controlled access from the left to the right.
But beyond that, and there, there are a couple of other things we need to look at.
And I think the left hand side of the graphics already shows it there's a need to think broader and types of identity. So it's not just about workforce identity or customer consumer identity management anymore. We have things, we have devices, we have software robots, etcetera. So at least from as a starting point for the bigger picture we should think about, which are all these types of identities. We have to deal where we have to manage the access.
This is more than traditionally human access via website to a certain system. So it's about all types of identities, a comprehensive set of services across all IM, but the access management as a very central part, it's about exposing APIs for digital services so that they can consume the IM capabilities. And specifically with access management is essential. How do you onboard users across all the digital apps?
You have the digital services in a consistent manner.
How do you do authentication in a consistent manner only that only will work well if you build your digital services against an identity API layer that delivers a machine use consistent services. On the other hand, you also need to support the legacy of, of it. So work with all the old applications you have just delivering access to the cloud services is not enough if you have. I've seen a lot of organizations which have not only hundreds, but thousands of legacy applications of web applications, don't support Federation standards. Then this backwards compatibility is essential.
Even for a modern access management, the architecture must be modern microservices, container based deployment, any, it must be built on standards. We have some very well established standards these days. So standards such as OS ID connect and so on.
We must utilize the standards within this bigger theme of identity and access management and access management therein. One of the, I would say sometimes a little overlooked and underestimated challenges is the onboarding and the identity wedding. So how do you know that Martin Kuppinger release Martin Kuppinger?
How do you simplify the onboarding so that you don't have drop off rates during onboarding? How do you simplify authentication later on so that you don't have chair rate because people don't come back, but it's not only for the customers, it's for everyone, it's for your business partners, for your employees, you can greatly improve processes and save cost by getting better in this space. And the interesting thing is that there are a lot of misconceptions in this space and it's very verse, and this is really a very fast exercise here, but it's, I think we're spending more time on that.
It's verse deconstructing the user journey. I, again, and again, have discussions about saying, but if we use this whatever decentralized identity thing, which is right now popping up, if we rely on other identity providers, we lose control about the customer, but this entire journey, it's not just authentication or registration or onboarding, or one instance in the back, it's about many authenticators, multiple IDPs, but having done one system of records you can use, and what does it mean? You have the customer consumer system, device thing, whatever, and that authenticates.
So it's using an authenticator. I might use my fingerprint and that authentication is then used against an IDP that might be even a little bit more complex here. So if I have more first and authentication to my device, and then this is used together with, so for instance, the device ID, plus some other information to access the IDP, but there's the identity provider and that identity provider then in fact, is doing the authentication for me.
And there's an account at the identity provider and there's account data for this account. And then there's access to the applications and services.
That is what the organization then owns and behind that, then there's a system of records. So what really happens is that there's sort of another mapping, which means we have customers account data that are a set of, of the IDP account data, but also might include other data. And then I have the system of records, which extend that data.
And that is the system of records at the end is really where, where I have this centralized view on that identity, but that identity might so it's even the same person might come in with different authenticators, with different IDPs, through different of, of my applications and services. But at the end, I want to know, okay, this is Martin. So from there, we have to also other use cases, other scenarios we can use, we have additional data to look at.
So we might have additional data that comes from applications because there, there are for both the applications and for beyond the system of records, there's additional data we have. And so this entire thing is a relatively complex picture. What is essential is to understand which elements are part of the picture, which play together because this, what you do that exercise. And as I said, it's something which is reversed spending a little bit more time. When you do that exercise, it becomes apparent. You can be super flexible in authenticators, super flexible in ITPs.
You can easily integrated decentralized identity, but you will not lose control about your system of records, about your additional data, about what you do in your applications. That is something which is on your side and not on the IDP side. And this enables you then to create solutions that are flexible to the user yet secure and to, to really define how do, how you deal with that interaction with the customer, the employee, the partner, etcetera.
So it's very worse when we talk about access management, not to talk about just about authentication or onboarding, but look at this way more in detail because there's way more behind. And if you understand that it helps you constructing your identity management environment, your access management environment, well next topic, but a little bit related to that, it's about passwords.
So a lot of, so since I'm involved in the identity management space, more or less, there is this notion that passwords are that when I look at how many passwords I use day by day by day, how many websites I have, where I need to register and create new passwords, then this is apparently not true. On the other hand, we see a lot of things happening around passwordless authentication. And we see that in certain areas, maybe of what we are doing, we are really password less. So the question is, is this the future for authentication going password less?
We all know passwords are risk, and there's at least once a year, they are the most widely used passwords published. So 1, 2, 3, 4, 5, or 1, 2, 3, 4, 5, 6, and things like that.
We also understand that relying on trust one factor is a risk. It's simple to, to fish a password. If you have two factors, it's way more complex. And the other thing is also, we need to understand the context. So if I access from the same device at the same location, regular certain system, this is different than when the device, the locations other things are changing.
So what we need to understand is this traditional scheme has its challenges. So when we have a username and the password, even an OTP, maybe the password still is traveling to the authentication system. And then we have a service in the back, which is somewhere integrated, which trusts the system, even birth is if you trust, use username password, which is at least when you look at the eCommerce space, it's still the standard, still the common scenario. Then we have a username and the password and the password, including the username travels to service, it's that really secure a modern scheme.
In fact, looks like that the user uses a device uses device on the sanitation, like face for cognition, like fingerprint or something else, which creates a key and there's to wise key as well. And in fact, a key.
So, so cryptographic element travels to an authentication system. There's no path for traveling anymore. Even if I authenticate with a pin or a password to the device, the password doesn't travel anymore or travels. Aren't really just some cryptographic items. Let's keep it very open here. And an authentication system collects other data such as where am I? So my tier location, other things, which device am I using, which is part of device identity anyway, and that is than used for Federation trust to service. So this is way more secure.
It's takes into account at risk the context, but it's also very convenient. So when I trust, use my fingerprint and a device sort of device based off indication where I once just the device, then it means for me, it's really very simple to use it way simpler than using a username and password.
So that's the interesting point is with password less than right, we, that sort of need to balance security and convenience. We combine balance, combine convenience and security. So we do both and get better on that, in that picture already osteo authentication system at risks.
There's some, some notion of policies and policies are one of the things which get more and more relevant to the entire access. Management seems, seem policies are, are quitters, but, but sometimes we, we, we only use them implicitly a while ago. I think it was in March. I talked to one of our Casey life events about road management, the relationship to policies. So when we create roles and the entitlements for the roles, we do nothing else than translating policies. Unfortunately, we usually don't write down the policy, but try to figure out, oh, what could a role be?
And which entitlements should this role have instead of just writing down the policy.
And my perspective is that we must use policies for, we also see when we look at the market, we see a number of startups which are pushing policy based access, which bring in new concepts for using policies. So policies are in a structure, very, very simple subject action object constraint. Martin can access the photo XT during work hours. We could create roles or groups of out of the, if you just cluster subjects for similar entitlements.
So all people who can access the folder and to other similar things quite fit well into a role or a group or whatever we already have the entitlements described. And oops, we have really ubiquitous policies which we then can use in a wide range of places. So we can use these policies for instance, to, to not only describe the, the, the access rights, the entitlements, but for our authentication policies, for firewall policies, for data governance, access, entitlements, and many more things.
So what we can do is we can describe generic policies and we can derive low level policies as well as static on access controls out of that. So we, we do, we need to do more that we need to utilize policies better. My final theme for today than would be this password when talk about access management is password of trust and time, trust and time access, trust, and time provisioning is just trust the bus word or stem more behind that.
Again, it goes in some way back to policies because it's about deciding trust and time. Who's allowed to work based on the policy. And we can use such controls. We have something which is out there for long. So we have a user, we have an authorization system of policy engine. We have also impact access management, the same policy engine and authentication system trust to the service.
And certain things are allowed for trust in time provisioning. It would mean that the user requests, the access, the system, based on the policies, provisions, entitlements, there's the access of the user.
There's the deprovisioning that is not frequently found, but it's something which is important for just in time access credentials. Like we, like we see them in the privileged access management. It is that a user reserves the certificate and with an informal. So a very short of certificate. He has access until the certificate expires again, based on policies. We see a lot of brokers. It's very verse exploring this space. So what should you do now? Tactics three things very quickly define your terminology, go past, but less and go multifactor education adaptive.
That's the very first thing to do. You can't, you can't do it maybe a little bit the wrong way, but doing it doing MFA always is good decision and revisit your user journeys, understand how you can improve user journeys, how you can make them better, more reusable, more flexible for every type of user, from a strategy perspective against reasons to put top on the list, define the big picture, your own identity fabric, your blueprint.
Think about a role of policies and try to get rid of standing privileges.
So standing privileges or static entitlements are way bigger risk than a trusted time decision about access a of thoughts about access management. That's it from my end. Thank you.
