Webinar Recording

Solving New Authentication Challenges While Finding Parity Between User Experience and Security

Name: Solving New Authentication Challenges While Finding Parity Between User Experience and Security
Uploaded: 2019-01-16T12:00:00+01:00
Duration: 57 min 28 s
Description: In an increasingly hostile world, where you don't know who to trust, companies still need to be able to deliver trusted, personalized experiences for users, without making them jump through hoops to prove who they are.

Andy Hall

ForgeRock

Director of Product Management

Martin Kuppinger

Principal Analyst

KuppingerCole

Posted on Jan 16, 2019

Webinar presentation, KuppingerCole

Webinar presentation, ForgeRock

Lead Sponsor

Video Description

In an increasingly hostile world, where you don't know who to trust, companies still need to be able to deliver trusted, personalized experiences for users, without making them jump through hoops to prove who they are.

Show Transcript

Good afternoon, ladies and gentlemen, welcome to our KuppingerCole webinar, solving new authentication challenges while finding parity between user experience and security. This webinar is supported by for truck speakers. Today are in the hall. Who's direct of product management at, for truck and me Martin equipping or I'm co-founder and principle Analyst at co a call. Before we start some quick information about keeping a call and some housekeeping information, co a call is an independent Analyst company with offices around globe.

We are focusing on topics such as information, security, identity and access management, identity governance, and other areas concerning the digital transformation we do. So by delivering services in three areas to our customers, which are research like our leadership compass documents, which compare vendors in certain market segments, and a lot of other types of research, our events, which I'll touch in a minute and our advice services, where we support and use organizations in their strategic decisions, around information, security, transformation, and identity management.

We do so in advisory by providing benchmarking and optimization. So scoring where you are providing advice, strategies, support architecture, and technology support and project guidance. In event space, we have a couple of upcoming events with our flagship event. The European identity conference being held in Munich May 14th to 17th.

Next year, it's already number 13 of the European identity conference and definitely a miss event. We will have a blockchain enterprise days event, the digital finance world, consumer identity world, and our cybersecurity event, which will be held next year in booth, Washington, DC and not, or not yet, or announced, but later next year, or this year already in Berlin for the webinar itself, some guidelines you are muted centers. So you don't have to mute around with yourself. You're controlling these features. We are recording the webinar and we'll make the podcast available by tomorrow.

We also will provide access to the slide X used in the webinar, and that will be a Q and a session at the end. So you can enter your questions at any time using the questions feature to go to webinar control panel, go to webinar control panel liquid have not control panel usually is at the right side of your screen. The more questions we have the better it is. So let's have a quick look at the agenda for today. It's split to three parts.

In the first part, I will talk about the changing requirements for authentication in the context of digital transformation, zero trust, second part, and, and the whole for truck. We'll talk about making IM more agile and fine train when managing access decisions for customers, consumers, employees, things, devices, et cetera. And then we will have our Q and a session. So let's directly start with our topic. This is light I'm using for quite a while. And I think it shows very well.

The situation we are in today as a business with everyone, everything becoming connective is more complex relations between all these things and people and organizations. So we have organizations, we have people working with them, have different types of relations with these organizations. We have these devices, the devices communicate with things. The people own the things, the things provide information back to businesses, et cetera. It's a RA a complex scenario. And this also means that we have to change the way we look at and we do identity in access management.

And several years ago, I published what I call seven fundamentals for future identity in access management and identity is, is the glue in access control is really what we need. And so I wanna highlight trust a few of these fundamentals. So obviously we are talking not only about humans anymore. We're talking about identity of things, devices or service. We have multiple providers for identities and attributes. People will continue having multiple identities or personas and switch between them.

We also, and that's, I think very important. We'll have multi loss indicators. So there's not a single loss indicator that works for, for all, because we use many devices we build on in for instance, biometric indication. And that depends on the device. Then we have the relationships and we have context. We need to understand the context of people. The more the people are outside of our anyway, not that existing parameter anymore. The more we need to understand which device are they using, where are they? Which networks are they using is secure. Isn't it secure?

And we also need to change our thinking. So traditionally we think very much inside, out, inside, out in the sense of we as an enterprise, look at the user that might be a consumer that might be a customer, might be a business partner, might be the employee. So I put consumer here, but it could be even more than consumer. We look at it and think about what works best for us as an enterprise. So which information do we want to collect, which authentication to use, which processes to have a blaze for registration, et cetera.

So we tell the external one, if it's template that might work to some extent, if it's a consumer, it might trust, end the relationship. We tell him, do what we want you to do. But basically it, it is, we should better think about what does the customer, the consumer, the partner want to do? What works best for them. They're using a multitude of devices, the different types of authentications. They don't want to register again and again, with every company they're working with every business they're working with. So we do what you want to do.

I think this is a very essential thing, and that means the way we work with users needs to change. And a lot of this change obviously is around access. So how do we handle the, and how do we, it starts with registration, with authentication. And when we look at authentication, then we need to under really, you really always keep in mind, consumer identities are different, or customer identities are different from enterprise identities. For enterprise identities. We have to primary focus of security, but even there, the workforce is expecting more convenience.

They expect to be able to use a variety of devices and also to be able to use new types of devices that become popular very quickly. Consumers. On the other hand, the obviously focus is convenience. If someone wants to do business with us, we build a herbal for that. Then we are about to fail doing business. They want to use the authentication or syndicated they want to use. It might be to build authentication smartphones. It might be whatever else. And they also might be. They want to be able to change their preferred.

I DEC cater at any time because they, for instance, change a new smartphone. They, whatever change from iPhone to Android or back, whatever else. So these are different requirements. We need more flexibility, but obviously our secondary focus anyway, security. And then the other big change that comes into place is this zero trust thing, pretty much a password. And a lot of what I read and and see around zero trust is really more marketing than, than, than reality.

But it's, it's, there's some interesting thing behind it. It is this shift from a, from a parameter thinking to a thinking where, where we say our world is far more heterogeneous in everything we do in it. So traditionally our thinking was, oh, we have this parameter. There's the firewall. Then if someone accesses it goes through through, or he's, the internal user has PC a against the active directory. Okay. So we verified the access somewhere once, usually, and then there was trust. And with far more scenarios of access.

So mobile users accessing our cloud services, business partners, accessing internal applications with all the mobility to cloud and all the other, but also with the ever increasing cyber risks it's that these approaches don't work anymore. So we need to verify more that we have things like man in the middle of attacks, etcetera. And basically the idea is to, to not trust anymore, but always verify to also repeated verification, because that helps us to get to achieve better level of protection, higher level of security and more flexibility for different types of use cases.

So I still occasionally have these discussions about concepts where then whatever the mobile users shall be rooted through whichever actually wise into the internal network to do some verification and to be rooted back to some cloud services, not the ideal way to do it. We need better supported use cases and that needs new approaches and going away from we trust. Okay. Once you to the active director, once he passed the firewall, then it's good.

No, it's not good. There's still so many things which can go wrong. So let's have a more frequent, repeated, continuous look at things that are happening. And so basically very quickly look at what, what at zero trust.

So what, what zero trust is and what, what it isn't. So it is concepts and architectural model and, and it's really processs and technology. It's not that you can go out and sell and buy a zero trust tool. If you might buy a component, which helps you to implement a zero trust concept, but there's not the one single piece of software, hardware, whatever else, cloud service that delivers zero trusting, because that would be exactly the one thing you should trust, which is an obvious dichotomy you have here. So zero trust really focuses on, on avoiding letter movement.

So it's not that once you pass the parameter, you can do everything within the network. It's not that once you've also dedicated to active directory, you can everything to everything it's really about which anyway, haven't been the case, but it's really about ensuring that, that you have repeated of indications and not trust to single entity reduced complexity. So you can have a lot of elements which implement security, which work together, making all the things easier also because you don't always have to go through certain types of edge devices, but it's not about trusting no one it's.

In fact, I would say, say in fact, zero trust, some sort of distributed trust. So you have a lot of pieces and you trust everyone, or every element, every software and hardware, etcetera, a little for a certain thing it does. And you verify it again.

And again, it's, it's, it's more that type of thing. And it's definitely not a next generation parameter, not a VPN modernization, and it's not enough the shelf product and not an it only job. So zero addressed in a very interesting thing important also for the authentication piece.

Why, because it's about the continuous verification of authentication. So the risks score in fact, really is, is constantly evaluated with multifactor indication, adaptive indication, and a lot of other things.

So, and context, relationships, all these things play together. And that's the way where it really influences what we do. So we need to do access differently. Access is one of these elements where we have centralized policy, real time tracks of what people are doing, continuous tracks, adaptive authentications. So we only allow, allow what fits to the risk based on the context, not really a new idea. So my colleague Mike Small, who created a slide brought up this quote.

So every program, every British use of the system should operate using the least amount of privilege necessary to complete the drop. Yes, exactly. Also about minimizing it to be adaptive, to only give what people really need. And behind that, from my perspective, there's a RA fundamental shift in, in, in, in where we set our priorities and focus in the broader identity management. So it's really going beyond it beyond identity governance administration. So the provisioning and, and, and, and governance piece.

So it's really about managing the access of users in context, to look at beyond sort of the deploy time identity management. So we have had a very strong focus on this in, in identity management for many years. So we have someone requesting entitlements, they get approved, technically a science. So someone is part of a group in active directory or becomes certain roles, business roles in SAP environment. We have some access governance and that, but we have the other part of identity management, which you could call runtime identity management.

So the deploy times, things, other things you request access once the runtime thing is what happens with every excess. And again and again. So looking at the authentication, so really should that happen? What is the context? What is the risk? Do we allow that policy base, etcetera? Can we authorize stuff, monitoring that stuff, analyzing things, etcetera, and, and a little bit text around that. So when we have an employee focus and traditional employee focus, so really thinking about this employee using an internal device to access internal resources, yes.

Then we have complex entitlements and there's logically seen a strong focus on deployed time identity management, and that will remain for certain use cases, but we have the mobile employees, we have to cloud and runtime identity management management that really becomes significantly more relevant. Who, so how do we deal with this? Mobile use are excess of our employee using a mobile device really secure enough. And then we have the partners, consumers, customers, syncs devices, apps.

And this is really usually for, for a customer that are relatively simple entitlements, what customers are allowed to do. Yes. And there's a little bit of, of, of a context in the sense of Martin cooking or only is allowed to see the invoices that orders from him. But when we take this, when we take zero trust and the more complex access decision at runtime then runtime identity management really is moving to the center of that means that authentication and all behind authentication around authentication is really what we need to put our emphasis on.

And the future for indication really is the adaptive. It is standard space. So we have this traditional sensing you have, so you have whatever device, something, you know, your password, your pin, something, you are biometrics there, you have that. That is what we have. And this is where, where really things like for instance, pH standards and in general, adaptiveness comes into, so what do we need to combine? So mobile biometric mobile plus pin, which combinations are good enough for what we really want to do.

And so, so for our perspective, for instance, the phyto Alliance standards really gaining more and more momentum, which is very positive. You have been following and pushing the standards from the very beginning, because this is really saying, how can you use this built in strong authentication on your device? How can you integrate as a standardized way into your environment? How can you really deal with different types of a indicators to be adaptive, adaptive, to, and, and, and strong and, and secure adaptive to which device are the people using?

What is the risk of the particular information access to transaction? This is what, what really comes in here. So fighter standards basically focus on, on a flexible authentication support of different types of devices with two elements in that the one is the fiber registration. So if that is enabled, then there's a registration interface. At first time access, you use the biometric authentication. The key is great. So we have the standard crypto stuff behind it. And the key is register then for the subsequent user, the keys are registered. And then when you access it, there's the login page.

You, the use of trust, whatever uses the fingerprint or, or voice face recognition or whatever, or might even be voice recognition, the right key is selected. And then based on that, the authentication happens. And that also means that information about the authentication strengths for instance, is transferred as part of the standard. So you have a defined level of authentication. The good thing with fi, particularly with fi two strong, broad acceptance with a lot of big players, Google, Microsoft people, and many, many others.

And it's increasingly supported natively, major browsers on main platforms, such as Android, such Microsoft process, et cetera. And so we, we should focus on standards and we should think about how do we really handle this entire thing of access.

And that means we need to look at, from at least from a luxury perspective, it might be more than one technical solution, but from a luxury perspective on how can we get a grip on all this access with users, from the employee to the consumer, with different types of identity providers, such as social logins, our internal ideas, cetera, and access to all these external and internal applications. Some of them with Federation support some of them without Federation support.

And that means we need a platform for adaptive authentication federating in out secure token services, web access management, and many more stuff. And we should really start thinking about how can we create such architecture? What is it, how we handle that? Because this is where, where we have the elements, which can repeatedly check things, which can provide us the assurance we need in our dynamic environments, and which can enable access of everyone on the left side to every service on the right side, including access wire APIs.

So access, which happen for instance, from, from a, from an app. And so this is where API security, maybe also API management comes into play. I think main focus here, obviously API security. So when we look at the middle of the, the picture, and so in the access pass area, we have on one hand, this web access based on HDP. So where we have Federation web access, Sam owes to standard web access management or proprietary integrations.

And we have the mobile apps, which are accessing via APIs or other services accessing via APIs, where we in some way need to use also standards such as OS two, which manage this. This is more and more converging into one world with, with every thing of this access to slide before. And that slide becoming one sort of big, at least from logical perspective, consistent area, and more and more also integrated tools.

And with that, we are the point where I'd like to hand over to Andy hall of, for truck who really right now we look at the, sort of the, the concrete reality of how this can look like how to do that, how to make it, and also show some demo about how this can work in practice. And it's your turn. Okay. Thanks very much, Martin. Yeah. Just picking up on what Martin said there, we wholeheartedly agree with all the things that we've talked about there. And one of the things I'd like to do right now is continue to talk about what people really want.

So in terms of market trends, but also then give you some concrete demonstrations of how this all ties together. So in my position, as the product manager for the 4k access management components of the platform, I get to travel around the world in speak Tor customers. And I hear over and over again, that there is this kind of like seeming split between wanting to deliver super high security, but also making life really easy for the end users.

And so, you know, one of the things that people want to do is it's very complicated to do this sometimes because organizations have grown maybe through mergers and acquisitions, they may have multiple kind of authoritative stores for their users from different divisions. And they want to deliver an authentication system and identity platform that can consider all of these different backend authorities.

Similarly, they, the business owners are asking for more and more information on how they can deliver the best type of service to their customers. You know, they need data to be able to decide whether to pivot and persevere and the time at which people authenticate is a real pinch point where you can gather some real information. And then finally there are changing regularity, regulative demands happening all over the world. We all know about PSD two in Europe, open banking in the UK and Australia and some of the Europe, the American kind of authorities as well.

And these are specifying specific requirements in the areas of authentication, such Asch customer authentication with PSD two. So we went back to the driven board and we said, how do we build an intelligent authentication engine that can accommodate all of these different use cases where people want to use many factors, not just one or two factors here, but maybe 15, maybe 20 factors of which many of them are transparent or invisible.

So, you know, you want to consider factors like context, you know, have we seen this device before behavior? Is Andy logging in, in the way that he normally logs in what time of day is it right now? Does Andy normally access this application at 3:00 AM in the morning from an Android device in Beijing?

You know, we wanna look and consider things like risk elements as well. Almost every business that we speak to, whether they're in a financial services organization, whether they are broadcast media outlets, they really have an idea of themselves, of the service that they're offering and the level of risk associated with the transaction that the end user is trying to, to accomplish here. So can we somehow have an authentication engine that can also augment those risk elements as well? And of course we want analytics because we want data as well.

Now, why are we doing all this? We're doing all this because we want to pick up on all these different signals to both strengthen the security landscape, make it as strong as possible, because even in the two cases that Martin mentioned earlier of consumer versus enterprise use cases, both of those need super strong security and both of them need to make it really easy to use as well to improve the, the engagements of the end user.

So the, I typically speak and hear from four different personas that are concerned about different elements of these authentication journeys here. You know, there's the end user. He wants life to be as easy as possible. Clearly there's the chief information security officer. Who's concerned about making sure that the platform that he's nailed his colors to the mast over is gonna be future proof is gonna be agile, is gonna be able to integrate with his existing information sources as well.

The business owner, the application owner, the guy that owns the service that is being delivered, he needs more and more data. He wants to know things like, you know, Hey, how many of my customers are coming in from an Android device in Amir? And then finally the security architect wants to be able to have an authentication process, which is smart enough to join mid authentication journey, determine the level of risk associated with this transaction and do something about it.

So let's see how we can do this right now on my laptop, I have a version of fraud, rock access management installed, and this is the administration console. The administration console allows me to create different constituencies of users, such as customers, employees. So from the same identity platform, I can deal with these different audiences.

If so, but what I'm gonna do here is I'm gonna go into our authentication mechanism and talk about authentication trees. Now, authentication trees is the way that you model a journey. So let's create a brand new tree for this webinar called KC, I guess. And we're put into this kind of like canvas where I can start to model that customer journey now, just so that we get all our burnings here. What I'll do is I'll create the traditional username and password kind of flow that we, we all know and hate. So the way that that typically works is that you would collect a username.

You would collect a password. You would maybe compare that against a authoritative store, which could be something like active directory or an LDAP directory. And if that was correct, if you provided the correct credentials, then you would succeed. Otherwise you would fail. So if I just very quickly save this right now, and then V up a, another window here to exercise this. So what I'm gonna do is I'm gonna go and exercise this new service that we just created that was called KC. And you'll see that I'm asked initially for my username.

So this is equivalent to this username collector node here, little bit of terminology. This whole thing on the left hand side is called a tree, a decision tree, and the individual components in this tree, these things are called nodes. Okay. So if I provide my username and my password, then providing iPad back correctly, I get logged in this page. Here is a simple user profile page. This indicates that I have successfully authenticated. So whenever we see this, we know that we've succeeded in logging in. Okay.

So that's kind of like just how you build a tree, but I really wanted to talk about some of the new use cases that we had. For instance, one of the use cases we've heard is that end users want to choose what their stronger second factor may be. So in this fee, what I'm gonna do is I'm gonna ask for the end users username, and I'm gonna let them choose what we shouldn't use next. Should we use voice? Should we use push authentication? Should we use something to do with this eyes? Maybe.

So, let's do that right now. So I'm gonna go to this particular tea here. This is the w user choice tea, which you can see on the left hand side as well. So it asks me for my, my username. And once I've provided that, it then gives me the choice, push voice and Iris. So in order for me to continue this demo, what I'm gonna do is I am going to show you my phone as well. So if I bring up my phone onto the screen like this, hopefully I won't get too many. Does you text messages while we're doing this demonstration?

But if I choose push here and say, log in using push, you can see that on my phone. I got notification. So I choose that notification. I use my ugly face to log in and on the left hand side, I get logged in. So that was using, given the end user choice of how to log in using this tree.

Now, if we were so smart though, surely we would be able to do something like this. We could be more device aware. So what this is gonna do is something very similar. It's gonna say us for the end users username as before, but if they're on a mobile device, let's use a, a authentication mechanism, which is sympathetic to that device, like push authentication. But if they're on a desktop device, let's use something like a one time password, which we're gonna send to them via email.

So again, if I log out over here and as the end user, I go to this device, a were, when I provide my credentials this time, you'll see that we're being asked for a one time password, because am has determined that we, we are on a desktop device. And so I've been emailed a number, which is this one that you can see on the screen, 8, 8, 5, 1 7. And I get logged in, in that way.

However, if on my mobile device, I do something very similar. I bring up a, a new tab and I go to exactly the same tree as before. And I provide my username. Then you'll see that it doesn't send a one time password. It sends a push notification where I can use my face. And then back on here, I get logged in like this. Now that's those two use cases that we just talked about, the user choice device, where they address the needs of the end user. But what about the business owner that we talked about?

Well, you can start to build trees that do things like this. So this tree is trying to provide more information to the end user, to lemme just turn off my phone here to the business owner, to determine kind of like data about how his service is performing. So what we're gonna do here is ask for the end username, we're gonna find out the IP address and then use some kind of mechanism to determine which geolocation he's in. And then we can kind of like simply use these metric counters here to count and hold in the memory of, of am where the end users are coming from.

Similarly, we can gather some data about, are you on a mobile device? Let's increment a mobile counter.

If so, we can even go down to the fact of, you know, are you on a browser that is a trusted browser or an untrusted browser? So we can gather huge amounts of data during the authentication journey and take the end user down different paths.

You know, we've heard our customers use this mechanism for doing AB testing. So when you are offering a service and you want to offer maybe a slightly modified one, let's allow 25% of our user base to use the new experience rather than the old experience and gather data as we go so that we can pivot or persevere with these new approaches.

So the, the authentication stream mechanism with it's built in user login analytics technology allows us to do this. So these nodes are not just to pick up on information to make life easier for the user, but they can give real data to your business owner.

Now, the next area I wanted to talk about was satisfying the CIOO. So the chief information security officer is really concerned about all of, of these potentially all these attacks that are potentially gonna hit his service. And so what we're gonna do with this fee is we can use something as follows. First of all, we are concerned about bots. So maybe we want to use a recapture node. So this is gonna leverage Google capture to stop bots, attacking our service. The next thing we want do is we want to call out to a rest based internet service that maintains a database of malicious endpoints.

So there are a lot of these kind of services on the internet. There's one here called Simon IO. And these guys basically maintain the Northy list for the internet. So the sources of spam malware viruses, they know where they came from.

They, and you can search this via a vest endpoint, which is exactly what this node is trying to do. So it's calling out this service to say, Hey, this guy that's trying to log into me, is he from a known bad end point?

Now, if he is, we can make a decision about what to do there. We, in this instance, I'm instantly failing him. I want nothing to do with him. The next thing we're gonna do is we're gonna ask for the end username. So even before we've asked for the end user username, we have, we've kind of like repelled, a couple of attack vectors, the bot and the known malicious endpoint attack vectors. So now we collect the end users username, and now we're gonna call another third party service.

So this is a node that has been written to call a service, which is operated by one of the guys in the security industry called Troy hunt. And the way that this one works is Troy collects databases, collects information about all the breaches in the world. So for instance, if I use, if I use my, one of my personal emails here like this, this is gonna say, has this email address been involved in any breach? And it hasn't.

However, however, if I use another one of my personas, I know that this actually was involved in a breach. I used this identity when I was just subscribing to our festival website and in May, 2017, my details were stolen. So what does it mean to you operating your service when you are the end user is coming into your service and they've been using credentials, which you've been compromised.

Well, again, you can fill them out and say, I don't trust you. I'm gonna fail you. Or in this instance, what I'm doing here is I'm gonna use a stronger authentication mechanism than I would've done otherwise, but I could do other things like send me to a password reset page so that I reset that password. Or just take more care about what's going on here. So that's another kind of use case.

Now, Martin talked earlier about zero trust, and I'd like to touch on that a little bit by talking about how we can build a tree that will help deal with ZeroX trust. So one of the things that you can do when you first authenticate is you can, you can store the context in which the initial authentication takes place. So authentication trees allow you to have sub trees, trees within trees. And this is a subtree where you would drop this as part of your, your initial kind of outer fee.

So for instance, the KCT that we have right now, one of the things I could do is I could drop in an energy evaluator somewhere along here. Maybe it would, I would do it here just before I go to two, drop it in here like this. If I can just get that to join like that, and this energy evaluator is gonna execute something called the, the zero. Actually what we'll do is we will execute the store context. So let me just rename this. So it looks smarter store context like this. So what this is saying is, as you log in, what we're gonna do is pick up on various contextual information.

And this tree is going to, if we look at the context tree, this is going to collect the context and then store it on the users' profile. Then what we can do is we can have another tree that can be executed at any point.

Now, authentication doesn't just happen when you log in authentication happens at many, many points. You can, for instance, with the am system, you can have a policy authorization policy that says, as you hit a particular URL, API vest endpoint, you can execute an authentication fee. So we could check the context here. So we can collect the current context, which is happening at a time, way later than authentication. We can get the previous context from the user's authority, from the user's profile that we saved earlier, and we can compare them.

And if the user has changed, then we can say, Hey, you know, the user has changed context here. Otherwise he hasn't. And so what that means is that in a bigger fee, you can check the context changed and force re authentication. And that's how you can get continual authentication during the lifetime of the session. As people hit the trusted resources.

Now, one more area that I'd like to talk about before we open it up for questions is to do with Fido and web authentication. And I'm really pleased to announce the vision 6.5 of for our access management supports web authentication and Fido. And the way it works is something like this. So what we're gonna do here is we're going to register a Fido device, and we're also going to use a Fido device for authentication. So this is the registration fee. We're going to establish, we're gonna ask the end user for his username and password. And this can be as strong as you like.

This could use maybe X five or nine certificates. It can use whatever you want to get convinced that this guy is who they say they are. And then we're gonna register a device with this end user kind of profile. The second thing we're gonna do is we're gonna use another tree for authentication itself, where we're simply gonna say, who are you? And now let's use your photo device. Now in order for me to show you this properly, and again, gonna ring up my phone onto the screen. So let me do that. And I'm doing this because I am going to use the camera on here to illustrate.

What's really gonna go going on. Okay. So here is my camera and I'm gonna move this over to one side over here. And I've got on my desk here, various kind of authenticators. This is a UBI key authenticator. I've also got this guy here, which is Google's Titan security bundle. And they come in either USB formats or NFC or Bluetooth type form factors. So what I'm gonna do is I'm going to on my computer and I'll try and do this.

I need, I need more arms here. I'm going to initially log out over here. And then I'm going to go to the registration fee and register a new device. So the registration fee, you may remember ask for my username and password. So I'm gonna type in my username and password like this. This is where we said it could be as strong as you wanted. And now we're being asked to use the security key, and you'll see that the security key here is flashing. So I'm gonna use my finger and I'm gonna touch this thing. And that has generated a key pair. The private key is gonna stay on this device down here.

And the public key is being attached to my user's profile. Now what happens now is that when I want to log in using this, if I go to the authentication tree, I simply say who I am and am pulls out the public key. It challenges the, the device to answer a challenge whereby we send a random set of bits.

We say, sign this, I then go and use my finger again, to tap on this flashing green U B key or Titan key. And I get logged in because what just happened there is I pulled off the private key for my device. I signed the challenge and then am, was able to check the only guy that could have put successfully signed it so that am can check it with the public key is the guy who claimed to have possession of that private key. So that's Fido like that. So Fido consists of two part.

It consists of web authentication between the service and the browser and something called C a client who authenticated protocol that operates between the device and the, the authenticated device itself. Now, not only have we been able to use authenticated devices, such as these UBI keys, but Google have actually managed to integrate with the, on my instance, I've got an apple Mac Macintosh here, and Google has actually managed to authenticate using touch ID as well. So now you'll see on the screen use touch ID and over here on my Mac, on the touch bar, it says touch ID to verify your identity.

I use my fingerprint on there. I get logged in immediately. Okay. So that's Fido. That's another way that am is pushing the boundaries by supporting the latest and greatest stuff.

Now, before we jump onto questions, I wanted to point out that we, we know that we don't know everything about the different types of signals that are available. And so fork has a mechanism where by people in the community can invite their own authentication nodes in the marketplace and publish them in the marketplace. So the marketplace is a website operated by forge VA. We've got a whole slew of authentication nodes here written by either commercial partners. And we have 10 pages of them here, or community partners as well, where people have written these nodes and have published them.

Now, the neat thing about these things is that the source code to these things is made available as well. So on this back marketplace, you can go to here, you can be redirected to GitHub, where there are many, many authentication nodes available. It shows how they work. It gives you the source code. You can clone find one that looks similar to what you need to do, clone it very easily, and the way you go. So that is the marketplace. And we have lots of commercial node suppliers from other people in our ecosystem as well. Okay. So in some way, then what did we just see?

We saw that we've built a new authentication subsystem that now delivers future proof mechanisms for allowing you to address any kind of future authentication mechanism. It's super rich. It uses contextual, it uses risk. It uses behavioral as well as a slew of strong authentication capabilities. That's good for the end user because they receive a less intrusive mechanism. So we can design a tree. For instance, that says, if it's on the same device as before, do we really need to ask them for a second factor?

The security teams are happy because the different nodes can consider different authentication servers. Service providers are happy because we've got nodes to measure and gauge the success of the service. And so the business leaders get insight into what's going on here. Now I wanna open this up to questions now.

So Martin, I'm gonna hand back to you. Yeah, Andy, thank you. Thank you for this very interesting, insightful presentation you gave. And also the demo part, which I highly appreciate. We already have a very long list of questions here.

And so I, I wanna pick some of these questions, so we probably will not be able to go through all of them, but at least some of these questions we should cover. So, so one of the questions pretty technical, but maybe you can answer it otherwise. It's probably good to follow up with.

So is the, also the case resistant to verify impersonation. So can you maybe explain what you mean by verify authentication? I probably can't because it's a question which came in from one of the attendees.

Maybe he, he, he pushes back a little and maybe he had some, some more details to his question. We, we, we pick it up later again.

Well, Maybe Martin and I can explain how this works. If you can make me sense again, I can maybe explain how this works.

Give A, give me a second. Right? Great. Thank you. So final authentication works like this. So initially the end user comes along and hits the am server and says, Hey, I want to register a device. And so am sends down at stage two here. It sends a, a message that says, okay, min some new credentials for me min and those credentials are a per keys, a public key, and a private key. Now the public key is returned back to the end user and the private key stuck on these devices here, whether it's a platform device or whether it is a external device, such as a USB or a Bluetooth kind of fob.

Now, the neat thing about this is that those credentials can only be used with that service. So even if you stole the private keys that can only be ever used with that service. And the second thing is that the credentials never leave these devices. So when you think about when we traditional credentials like using password, we're transmitting them on the wire, but with Fido, we're not, Fido is a mashup of a challenge and PKI and these credentials can be they're more ephemeral, so they can be phone away when they're no longer needed.

So this, this OB basically obstructs many of the attack vectors that are coming along. Now, that's a authentication time, sorry, that's a registration time. This is authentication time. So sends a challenge, which basically says, if you are who you claim to be, then you should be able to sign this random piece of data with your private key. And I will be able to understand it with my public key, which I pull from the user profile.

So again, the credentials never leave the authenticator and the data that's sent in transit is useless. It's a random bid set of bites.

So fi is, is being really widely accepted by the skill community. And it seems to kind of hit the sweet spots between ease of use and strength of security. Okay. Another question, which is also technical. So I'll leave you, leave you the percenter role for now. Can you elaborate a bit how it is possible to force rechecking use risk context after initial authentication and what can be the triggers for such rejects?

Okay, great. So yeah, so authentication people typically think that that happens at login time, but it's not just about authentication at login time. It can be authentication, can be used for a whole host of things. Number one, it can be used to deliver an access token or Sam assertion, by the way, for rock access management access an or two authorization server and a Sam IDP or Samuel SP it can also be used to determine authorization decisions as well. So that's what we mean by being able to do the continuous checking gain.

Now, in order to do this, you need either the cooperation of the application itself, or you can use a tool such as like for Rock's identity gateway that sits in front of your API or app. And what happens is once you have authenticated and then let's say 10 minutes later, you try and access a protected resource. The identity gateway, or an agent can basically say, Ooh, just a minute. I need to check to see if the policy for you to access. This allows you to access it.

Now at that policy evaluation point, we can invoke some code to determine whether or not that end user is who they say they are. So we can run through a tree as part of that policy evaluation. So that's how we can downstream invoke a authentication tree, mid session. It's using something called the identity gateway, or the application itself can call a vest point called policy evaluate. I hope to answer the question. Okay. Thank you, Andy. And the next question, you mentioned the availability of code for the custom authentication modules in the marketplace.

So you get this marketplace perspective that there's a lot of stuff that just shared is the marketplace available for the public or only for the partners or for whom is it available? It's available to anyone. All you need is, I think you may need to log into a, for rock, but you can register for your charge. And then both our, our customers, our partners can download these nodes or publish new nodes, which can be used in authentication trees.

So, you know, to give you some examples, there's a couple of commercial nodes, which do things like one of my personal favorites is one called tick stream. So tick stream measures how I type my password because everyone types in a particular gate.

And so, you know, the tick stream guys have written a node which can be dropped into an authentication tree. It calls the tick stream service that's on the internet to basically provide the recorded kind of short recording of how I typed. And it comes back with like, yep, that's how Andy normally types or not. And so that's just another factor, another signal that can be used as part of the authentication mechanism. Okay. So Let's look at other questions we have here. So we have sync three or four minutes left. That's an interesting question.

Password less authentication has been the holy grail for several years. Are we getting close? Maybe that's something where, where both Andy and I could come command on. I think we, what we really have seen as an uptake of the acceptance of biometric authentication, which means that the, the role, the passwords play is, is decreasing.

Getting, getting fully password less, probably never will happen. So also for a fallback for recovery for other reasons. But what we clearly see is that we, we do more, more things, password less. On the other hand, if we are realistic, unless we use our smartphone or maybe our, our tablet still, we still have to maintain masses of username, password combinations for, for many of the, the websites, eCommerce sites, etcetera. So it's still from an adoption. Rate's still still a way to go, but I'm also convinced that over the next one or two years, we will see another, another very strong uptake.

So that at least the, the amount of passwords we are using will significantly decrease. And what's your opinion on that? Yeah.

I, I do agree with you that, you know, we are getting, there are some new technologies such as Fido, which are starting to get to the point where passwords are less important. They may not go a hundred percent because you know, you may need them for, I dunno, credential resets mechanisms, but certainly if you look at what's happening on the desktop with things like windows, hello, for Microsoft, where you can use your finger or your face to log into your desktop device.

One of the things that I possibly could have shown you today is an integration between using your finger and face on windows desktops to the edge browser and your web-based resources as well. So you can use with, with am in the mix, you can use your face to log into your web resources. Okay. I think for the end we pick maybe two questions, which are, I think RA closely related one is how can customers future proof themselves to ever changing threats and implement new authentication methods.

And the other is how can organizations manage the opposites of great user experience by simultaneously increasing security. And I think both of them have to do with, with what you demonstrated in your part of the presentation, which was very much about being flexible in and supporting different authentication muscle. I personally believe it helps for both. It helps for convenience and for security and for being flexible regarding cyber risk.

So I remember many years ago we had this attack against the RSA secure ID and a lot of the competitors of RSA then directly following came up and said, oh, just switch to our technology. And you're safe back in these days, it was literally impossible because a lot of the integration was really hard coded. So it's not just switch. And I think it was the adaptive authentication and implementation such as the photo access manager is the flexibility of adding other factors back of combining factors.

Etcetera, we can really balance this and, and react far, far more rapidly on, on new threats and new risks, but also keep convenience side by always supporting the new stuff. So that's my, my perspective on these two questions, Annie, what do you think?

Yeah, well, this was actually a design goal of the intelligent authentication using authentication to use because, you know, if you think about two years ago, probably the authentication mechanism duo was was, was your finger this year. It's probably your face, what's it gonna be in two years from now? And what you really don't wanna have to do is rip out your identity, digital identity platform, simply because you now need to provide, I dunno, DNA based authentication.

You know, you want to be able to just simply write a new node, drop it into your tree and you can voila use the new authentication factor. And in fact, that's how we were able to deliver a Fido node or web authentication node so quickly because we simply leveraged the existing capabilities of the authentication tree platform.

Okay, perfect. Thank you. So we are anyway at the end of the time, close to the top of the hour, Andy, thank you very much for insights for your presentation, for the demo. A pleasure. Yeah. Been a pleasure on, thank you. Thank you to all of the attendees for listening to call webinar. I hope to see you back soon in one of our outer upcoming webinars or on one of our events. So thank you very much to all and have a nice day.

Like this?

Don't like this?

Why don't you like this?

Solving New Authentication Challenges While Finding Parity Between User Experience and Security