Tech Talk: One Identity and OneLogin – A new choice | a better choice

[MUSIC PLAYING] Well, good morning, everybody. Thank you very much for spending this next hour with us. We appreciate you're very busy at the run up to the end of the year. I have the pleasure of introducing two colleagues for you today. We have Mark and Phil from OneLogin. Now, you're all on this call, so you're all familiar with the fact that OneLogin has been acquired by One Identity. As with all acquisitions, it takes some time to do the integration of the companies, and we will give you full information of that in the fullness of time. But expect more information from us, it's being run by, from a channel perspective, by, our one and only, Andrew Clark. And so over the next couple of months we'll be completing that integration, and we'll be having the OneLogin solutions fully part of the One Identity portfolio. But until then, we wanted to keep you updated with the solutions, give you an introduction. And I'm going to pass you straight over to Phil, who's going to start that education process. This is going to be the first of, perhaps, many tech talks that we're going to be providing you on this OneLogin topic. Phil, over to you. Thank you Thanks a million. Very, very happy to be here this morning. What I'd like to say is, just to echo John's comments, we are really excited by the merger of, the acquisition should I say, of One Identity to OneLogin. I said the word merger because it really feels like a merger, it's two teams coming together. It's a best of breed, two security leaders coming together to offer you, what is effectively, not just a new choice, but it is a better choice. Up until now you might have been faced with a choice of either best of breed, or making an easier purchase decision, but not anymore. And our key goal is to be the platform of choice connecting into our rich ecosystem of channel partners who's on the call today. If you're a One Identity partner who has not yet interacted with OneLogin, welcome. We're delighted to have this opportunity to give you a top line overview of the solution stack, and in the next hour, heavily supported by my colleague Marc, we'll give you a glimpse into the world of OneLogin from a technical perspective. But also, hopefully, we'll start to build some awarenesses around the conversations that we are having with our customers, and those conversations which you could be having with your customers. Because we truly believe that OneLogin's value proposition around security, productivity, and compliance, is extremely relevant nowadays, and it's in the front of the mind of the IT leaders that you are talking to on a daily basis. It's not so easy to get out there prospecting, especially in these COVID times, and therefore, what we would impress upon you is the relevance of the conversation you can have around OneLogin. And very much in those prospecting engagements, lead with OneLogin. When we're talking to our customers, one of the major challenges that the IT department is facing, is how do they provide their users with access to approved cloud applications? And secondly, how do they manage those cloud applications with, I suppose, the same certainty and control they've traditionally had over on premise applications? And that's where single sign-on becomes a topic of interest. How do your customers users currently access those cloud or web apps? And how can your customers users ensure that-- how can you ensure that they're not using the same credentials, or the same passwords for private and for corporate apps? Secondly, there's the issue of security. And that's where we talk about the advantages of multi factor authentication. How can your users IT department be sure that the users say who they say they are when they're accessing those cloud applications, or over the Wi-Fi, or the VPN. OneLogin's MFA can be layered in front of all web applications, not just the ones that natively support Microsoft or natively support Google. And therefore, this means that your customers have no blind spot vulnerabilities, they're completely covered. And now comes the next, I suppose, challenge for your customers IT department. They've managed the access, and it's secure, but the real challenge is, how can they deliver those services to their users at the speed that the business requires? How can you ensure that the users get access to the applications that they need to make their jobs effective and efficient? And here we talk about user lifecycle management, and how that can be automated. Maybe ask your customers, how is their onboarding and off boarding process today? How quickly are new users in the organization given access to all the applications that they need to ramp up quickly and to perform their job effectively? Is the joiner, mover, lever process seamless and smooth, or is it clunky and awkward, frustrating, with many manual IT interventions, and security loopholes? And another area that we focus on is the IT department working closely, and outsourcing to the HR department the onboarding and provisioning of new users, and building that gap between HR and IT, what we like to call, creating HR happiness with IT efficiency. So I'd like to, briefly, just cover our market leading position, because we're very proud of the position that we've achieved over the last number of years, and the dedication, and hard work that's gone into receiving this analyst recognition. And this is what's driving us on every day to bigger and better things. And this, I believe, is also one of the key attraction points with One Identity's acquisition of OneLogin. Really an analyst choice for best of breed identity solutions out of one hand. You can see here on the screen is a snapshot of the many customers around the globe who work with OneLogin on a daily basis, and who know us. But so many more customers around the world need to get to know OneLogin, and that's where you come in, our partner community. Because it's through you that we will scale our business, and that we will engage with many, many more new customers. And finally, before I hand over to Mark, I'd just like to discuss briefly from the channel perspective. At the moment we still are two separate channel organizations, two separate partner portals. But as One Identity partner, don't fret, we are moving a lot of the content already over into partner circles, so that you can start to access that content around enablement, marketing, sales, and technical collateral. And within Q1, probably within the March time frame, our partner portal will disappear, and all of the content from the OneLogin partner portal will be available to you on Quest Partner Circle. So that's a very, very fast introduction. I hope to meet each and every one of you many, many times over the coming years. And now what I'd like to do is to hand over to Mark to give you that first glimpse of the solution stack. Mark? Thanks, Philip. So let's have a look at the infrastructure side of things, first of all, and give you a flavor of what we're able to provide you with. In terms of OneLogin's infrastructure, we're a fully cloud based solution. We're a SaaS solution offering [INAUDIBLE] features to support hybrids as well as cloud only deployments. The entire workforce, partners and customers. Foundation of all of this is pinned on our service reliability, and we're offering that to logging clusters and high performance architecture as well. If you've got any questions as you go through, as we go through this, please feel free to put them in the chat. We will answer them at the end. If we can't answer those we will put them in the FAQ after this call. So let's look at our enterprise grade platform then. So three years ago we agreed on a strategy to develop a new generation of architecture that would enable us to offer a carrier grade reliability, we're calling that our Hydra Cloud Infrastructure. We now have telemetry to track and alert on every single transaction that hits our infrastructure. In 2021 to date, we're already over 99.995% reliability and 100% availability. So you can see here we've got our hydrocarbon clusters we've got our industry's leading scalability by a HydraBoost and we've also got additional extensibility, such as, our Smart Hooks, which are load code serverless technology. Just a quick one, I noticed that somebody is not on mute, just wondered if you're able to mute, please. So in terms of redundancy and scalability, our platform is based out of AWS. So we re-architected our platform to run on EKS micro services. That every tenant in load balance across a minimum of six availability zones, in two AWS regions. Each service is also then able to scale horizontally within an availability zone. When it comes to data residency we've got two options, we've got the US or the EU. And data does not move between the shafts. So the US stays in the US, and the EU stays in the EU, and that ensures that we remain compliant with local regulatory requirements. As an example, in EMEA, we're split between Frankfurt and Dublin availability zones, so that's how that is built up within region. Looking at that side of things then and how we can scale we can use an example of a previous outage in AWS. But we had another outage, or AWS had another outage this week. But in the last 18 months, we've seen significant outages for major service providers, especially Microsoft, and we're now seeing more in the AWS space as well. On the 31st of August between 10:58 and 3:35 Pacific time customers in the west availability zone two, noticed that there was an issue with the network load balancers gateway state basis, and the elastic services. There was a failure rate of 15% and that lasted 282 minutes. Now let's look at how our nearest competitor performed in that time. Traditional IDOS architectures have a direct dependence on the availability and reliability of the underlying infrastructure. Okta, as an example, experience exactly the same 50% error rate over that entire 4 and 1/2 hours. But let's have a look at OneLogin. Our Hydro Cloud architecture, in contrast, break that dependency. The failure rate for us was only around 3%, and that's because every OneLogin tenant is fully load balanced, and runs in a minimum of six AWS data centers. Onelogin telemetry actually detected the increasing failure rate before AWS had announced any issues at all. And the failed availability zone was automatically removed, allowing customers to operate as normal from other availability zones. Therefore limiting the impact window to under 10 minute-- 20 minutes, sorry. OneLogin's low failure rate, and the small impact window, therefore, meant that customers hosting their own services in AWS, or using additional IDOS platforms, experienced seven times more errors than the OneLogin platform. See that they're framed within this chart. In terms of the security ecosystem, we won't have time, today, to show you the deep integrations that we have across the security ecosystem, so I'll just highlight a few. [INAUDIBLE] like Cloud Lock, can monitor OneLogin events, and also take corrective action, like terminating a session, suspending a user, forcing a password reset. And our customers leverage endpoint platforms like VMware or Jamf to install third party certificates, which OneLogin uses to enforce device trust policies. A high percentage of our customers also integrate onelogin with their SIEM and incident management platforms, and integrate via web hooks, to enhance security orchestration. Looking at the platform ecosystem, similarly, we have deep integrations with other platforms, particularly AWS. Our customers use AWS event bridge to build workflows, and CloudWatch the trigger alerts and responses. Some of our biggest customers have integrated OneLogin into their help desk system, to provide user verification via MFA. And others leverage ServiceNow workflow and catalog components to provide access requests and approval workflows to trigger provisioning events in OneLogin. But of course, that's not the end of the story. We're now part of the One Identity team, and we can now combine all of this together to provide one overarching platform. And, in fact, just looking at this brief diagram here, you can see how OneLogin will be able to integrate, eventually, across that entire infrastructure. That, of course, will be achieved by API calls and other means as well, via integrations in the back end. Of course, that will be coming later and we will provide more information as soon as we know it. So let's have a look at OneLogin as a platform, then. We'll dive into a few of our key components, And, as I said, if you do have any questions, please pop them in the chat, and we'll cover them off at the end or we'll release a FAQ post call. So, as I mentioned, OneLogin is a Saas solution, we're based out of AWS, and every customer receives their own unique tenant which they can control the content and users within. Just trying to unlock this device, it's decided to misbehave today, apologies. There we go. So the front end of this, we can brand up and make it look like something familiar to our end users. We don't just have to have the generic OneLogin logo background, colors, et cetera, here. You can make this your own as a customer, as a partner, et cetera, all of that is customizable. But we also support local languages from the front end as well. So if we were to open a different browser, and navigate to exactly the same front end, we will see that we can automatically translate that front end for you, into that specific language. We can see, in this case, this browser is set to the browser locale of Dutch, therefore we are translating this immediately into the Dutch language. And once the user is in the portal, they can also amend their local language to be something that's relevant to them. Of course, one of the main things we can do within OneLogin, is start to leverage MFA. And the forgotten password reset flow from the front end, allows us to start to use that immediately. Many of our customers come to us for this particular functionality, they want a way of being able to centralize the identity, and allow users to reset their password from anywhere. Users working from home over the pandemic, they weren't always able to go into the office and reset a password within the office, or maybe they were having VPN issues, so centralizing the password via cloud service made sense. So clicking on Forgot Password allows us to do that. We're backing off to AD or we could back off to another service, or just utilize OneLogin to store the credentials. In this case, the user I am going to use-- their Identity is stored and managed from AD and we delegate authentication back to Active Directory. So password change in OneLogin will write back to AD, and an authentication request within OneLogin will authenticate back again safely also. So let's have a look at this user, then. In a sign in, or sign into the password reset page here. Just going to enter her username, and then we're presented with all the options that she's enrolled in, and that her admin has made available for her to be able to do a password reset. Rebecca has chosen to enroll in a number of different factors, this gives her flexibility, and also if one of these factors decides to break, maybe her phone breaks, maybe she's lost it, maybe her YubiKey is at home. Therefore she has another option to go to. You can see, I've already mentioned YubiKeys, we're using Webauthn in this case, as a means of doing that, but we do support the more legacy, YubiKey method as well. We can use third party tools such as Google and Microsoft Authenticator, even [INAUDIBLE] as well as supported. SMS and email based [INAUDIBLE] are possible too. There's also a number of partner applications that we can integrate with as well, which if we have time, I'll dive into later. Let's use our own tool for this first demonstration, OneLogin Protect sits on an Android or iOS device, and it supports TOTP within the application itself, you can see that on the right hand side of my screen, here. But it also supports push notifications, so I don't actually have to have the application open at all. Clicking on my tile within OneLogin sends an alert to the phone. I can then pull down and accept that, or if we wanted further security restrictions in place, the admin could customize this to have to force bio metrics on the user before they can accept that. In this case, since this is a virtual device I'm not doing that, so I'm just going to click on Accept, and that's going to send the response back to OneLogin. At the password change screen we can expose the password policy to the user, or as an admin we could choose to hide that. You see, in this case, I've got a password policy of eight characters, a letter, and a number, but we've got more complexity options as well we can bring in. And we can also start to enforce things, such as password blacklists, starting to, maybe, enforce the blacklisting of attribute values like, their first name, last name, job title, et cetera. We can also perform a compromised credential check on this same page. So at the point of password change we can prevent previously breached [INAUDIBLE] from being used within the system, or just use that as a bad password list at any previously breached password, and be prevented from being used within the system. Now as I type my new password we can see we now comply with the policy down the bottom. On this first attempt I have entered a word within this particular password that has been blacklisted by my administrator. You can see that the word, coffee, has been blacklisted. Therefore, as it was in this password, we can't use the password we've entered. A new password, one more time, a new password, in this case, this is, again, compliant and doesn't contain any breach credentials, blacklisted words, or blacklisted attributes. Therefore, we're able to write that back all the way to AD, and then we can now come to sign in as this particular user. So we'll do that now. Signing into the portal, here, takes us through into the OneLogin dashboard. It might be that the end users start out of their application, and uses the service provider initiative blow. That, of course, will take them to OneLogin, and then direct them all the way back to their application. But, in turn, also establishes a OneLogin session and allows you then to sign the portal from any other application as well. So we're just going to sign in as Rebecca now. This particular flow is our standard log in flow, and we have three log in flows. We have our standard flow, our brute force defense flow, which moves the password element all the way to the end of the flow, and we also have a password list flow, which we generally see used, quite a lot, within SIEM use cases. We just touched the YubiKey now, and then we are signed into portal. Once we land in a portal we're then presented with all of our applications in the form of tiles. And the first page that we land on is our frequents tab. This allows us to access, very quickly and easily, those applications we are using on a regular basis. So this dynamically changes based upon our usage. Now in the main here we're using modern authentication. So methods such as SAML, OIDC, and other means as well, such as WS-Fed. This allows us to, very quickly and easily, access the applications in a secure way, and be the only means of access into all of those. So those of you who have dealt with identity management solutions in the past will know this very, very well. Clicking on, for example, Google Workspace, signs us straight through. If we were to terminate Rebecca's account, we could immediately lock the access to that, and we can also choose to use our deprovisioning option to, then, suspend the account within those systems as well. Office 365, Salesforce, et cetera, are all examples of that on top. One thing I haven't shown, is that we don't just have to use our credentials to sign in. We could use the integrated Windows authentication as a means of signing in to OneLogin. So where we've got the domain joined machine, we can use the local window session to establish the OneLogin session. When we have the Active Directory Connector that we utilize for user syncing installed, the Premise So really enabling you to centralize the identity and make the sign on process for all the applications extremely smooth. In addition to all of this we also have a tool called OneLogin desktop. And this allows you to start managing the passwords on non domain joined machines for users. This is an agent based solution that's installed on the devices and supports both Mac and Windows. When a user's password is changed within OneLogin that's immediately synchronized down to device. Therefore, allowing you to manage the password on every device that is installed on. Now we quickly had a look at the modern authentication type applications. Not all applications support Modern Auth. It might be them or legacy, and sit on Premise Maybe they only support header based authentication, and that's where OneLogin access comes in. This is our legacy WAM tool. It sits on Prem and we utilize that for header based authentication, but also, as a reverse proxy, to expose those applications to the internet where you do have SOML or OIDC apps on Prem that aren't exposed. In addition, we have both RADIUS and LDAP endpoints in the cloud. So where you've got solutions, again, that sit on Premise or in the cloud, maybe a VPN solution, or maybe Wi-Fi. You can utilize those Cloud endpoints to be able to authenticate your users in, and layer the MFA on top, as well. In addition to all of that, we can also start vault credentials within OneLogin. And they could be used for the purposes of, maybe, individual credentials, for example, an individual username and password. Or it may be that users are sharing credentials for marketing tools, maybe IT are accessing a telephony portal that there's only one log in for. In order to do that, we use a browser extension, in this case, we're using Chrome. We can see all of our applications, including our forms based apps at defined within here. Clicking on the relevant file signs us straight into that application. We don't need to know what the credentials are, we're just injecting those straight into browser. In looking through the rest of the tabs we have, we also have a personal tab in here. And this allows us to start adding in our own applications as an end user. As an admin, of course, we could choose to toggle this off. But it's a great way of starting to give users an additional application to start adopting, be able to centralize all of their passwords in one place, rather than having to utilize other solutions, or maybe storing them within the browser. This, of course, also gives you other ways to be able to uncover application usage within your environment. Maybe customers have a lot of shadow IT. This is a great way of starting to uncover those applications that they may have it out in their state, but they're not yet aware of. Again we're vaulting the credentials in here so it works exactly the same as that LinkedIn target just showed. Corporate apps list out all the applications that we have access to, and users will only see those applications that they've been granted access to. So we're using role based access control as a means of assigning applications, and also assigning access within an application. Rebecca does have a few means of being able to manage her profile, we can manage her password, and also look at recent activity, as well, but we can always cover that off in another session. Let's move across to the administrator side of things to show you what that would look like. Now administrators get the administration link in the top right hand corner, and of course, administrators come in many different flavors. You don't just have super administrators, you could have-- use our coarse grained controls-- our legacy coarse grained controls to be able to start assigning users access, maybe a help desk role, or maybe an application manager role. And that is all controlled within the user's profile. On top of this, we now have a new privileged model, and this allows us to start creating access statements for users and administrators to be able to do specific things, only within the console. It may be we just want those users to be able to view all of the users within the environment, or a specific set of users. Maybe you just want those users to be able to manage the MFA, maybe it's a local admin within a large environment that you want to give the ability to manage MFA for users, and that's it. Or maybe you've got some application owners where you just want them to be able to assign users to their application, and that-- there's many different options here, and those options can be based around applications, events, sports, roles, users. And this is something that's being expanded upon, all the time, in terms of the functionality. Many different ways to add access statements, and many different layers of access statements too. What's the main thing that we are managing, other than applications and access within OneLogin, is our users. And these can be sourced from many different places. We could provision them, directly, from OneLogin by clicking on New User in the top right hand corner and filling in the blanks. Of course, we have our standard, out of the box fields, at the top, and we can start to add as many custom fields as we want to, as well, or every usage we may have them. Many of our customers come with pre-existing directories, though, and they want to be able to connect those up. You can connect to as many different directories as you want to online, so you could have hundreds of Active Directories synchronizing data to OneLogin and create the users, and then create the users within their applications as well. But not all customers have something like an AD. Many cloud native customers now, are utilizing HR tools, or maybe things like Azure AD, or Google Workspace as their Identity repository, and we can use those as source of truth too, removing the need for IT to manage their users day to day, and handing off to, for example, HR tools. In addition to all of that, we also have the ability to connect in to other tools via APIs, using our universal connector. Let's drill into one of the particular configurations then, we'll have a look at our Active Directory Connector. This connector sits on Premise, on a member server, and is synchronizing data in real time. We don't have to wait for a batch based sync to occur, as soon as we know the change within AD we immediately synchronize that into OneLogin. As I also said, we delegate authentication back to AD for those users as well. So when they come to sign in, they sign in with their AD credentials, rather than a separate set of credentials. We don't have to synchronize everything either, so we can choose which particular OU to sink into OneLogin. We can also choose how directory attributes are mapped across, so putting the right fields into the right places at the right time. Now, once a user is provisioned in OneLogin we then want to start capturing that information. So if we search for Rebecca, as an example here, we can see all the information that's held against Rebecca. Some of this is synchronized from Active Directory and some of it is synchronized from bamboo so we start to consolidate that in one place, and create one overarching user profile. Now on the bottom, we can see all the information around our directories, as well, so things like our group membership. So lots of information is exposed to our administrators, and, of course, we can start to do things with that data once it's into the system as well, we'll come back to that later on. Looking at authentication then, we can see how this particular user authenticates. In this case, Rebecca authenticates against that Directory, and she has a security policy assigned to her, as well. This has been automatically applied to her based around the data within her profile. MFA is manageable by an admin, so we could come in here and we can uplift one of these to primary, we could revoke one, or if a user was having big issues we could generate a temporary token, that allows them, then, to access the system still, even though their general MFA access is unavailable at the time. When it comes to applications, we see all the apps that a user has been assigned, and we generally do this using Roles. This allows us to start clustering applications together, rather than having to manually assign them one by one. So it might be, we have a default role that contains the majority of our applications. And then dependent on our department we start to layer up new apps. For example, the sales team get the sales related applications, the IT team would get the IT related apps, maybe a Manager needs a different application, and then, maybe, within each app you want to start assigning role based access control in the application itself. That's where sending things across within a SAML assertion, or an OIDC token, or using SCIM to provision the user starts to come in. And you can see a number of my applications I have enabled for SCIM provisioning. Just like the AD sync, this is real time. So as soon as that user is provisioned, or changed in OneLogin, our mappings engine will fire, which allows us to use conditions to perform actions, and then these users will be immediately changed within those endpoints. Looking at Office 365 as an example, this could be everything from our groups, to licenses, to just, simply, attribute values. So many different options there. Looking into our mapping engine, then. As I briefly mentioned, this allows us to start setting conditions to perform actions. This is a means of automating your environment to reduce the amount of time that it takes for the IT team to manage their OneLogin environment day to day. Looking at our sales team mapping, as an example, we can see I've got some conditions at the top. On the main here, I'm looking for a department to sales, but I'm also doing some exclusions, as well, around specific directories, and based on these conditions being true, and then performing these actions down the bottom. Now our groups set security policies, so a user can just be part of one of those, and our roles set our applications, so users can be part of multiple roles. Think of the groups like an OU with an Active Directory, and a role more like a distribution list for a security group, where a user can be part of many effects. I've already mentioned our unified Cloud Directory allowing us to bring users in from many places. Of course, it's not just about the workforce identities, we can also use trusted IdP as a means of allowing external users into OneLogin using their external identity. This could also be used for Workforce too, but we see this more used for external identities, maybe contractors, or customers wanting to sign into the platform using that external identity. Talking about external identities, we also have a means of self registration. This allows us to create self registration forms where we're capturing specific information on a user through a web page, and then that user can go through a moderated, or an unmoderated registration process where they confirm their email address, and then, optionally, an admin approves that registration. So I've spoken about the users, the directories, and our mappings roles and groups. But let's have a look at this in action. I've spoken about how this could work, but let's have a look at what it could look like in real life. So we've got John here in our staging OU, and this OU's not synchronized at all into OneLogin. We do a quick search for John, we'll find that he doesn't yet exist within our environment. Now as I said, we perform a real time synchronization to OneLogin. So as soon as I drag and drop my user into my sales OU, which is synchronized, within a few seconds this user will then appear within OneLogin. So we'll just do a couple of refreshes now, and we can see now John has been provisioned. So within a few seconds that's now done, but not only have we provisioned John, John now has got all the information against him in OneLogin, down the bottom we've also got things like our group membership. And due to the information held against John, we then started to automatically apply things using our mappings engine. So our security policy has been applied using a group. Under applications we've got a set of applications aside, and we've also started to immediately provision out into these applications, as well. So from that one action we perform another number of other actions. So when John comes to sign in for the first time, he's got the applications that he needs, and he's got the access within those applications that he needs too. But not only that, we're also going to enforce MFA during that first sign in process. When we come to sign in now, instead of John just being allowed straight into the system, we are going to enforce MFA enrollment straight from the front end. And that could be through whichever means that our admin has enabled, in this case a number as this is a demonstration system. We're now just going to use OneLogin Protect. We click on Activate. With the mobile device in my hand I then scan a QR code. And then we're allowed into the system. So John started on day one, he's been given a password, he's been signed in, he's enrolled in MFA, and now we've got all of our access to our applications. So if we were going to go and click on, for example, Salesforce, sign straight into that environment, and we've got the access we need. Now, of course, if something changes, then that is also going to reflect down into all of our applications too, so if John moved from sales into IT, as an example, then we're going to follow that through and revoke accounts, plus then enroll him in new access, as well. So if John moves teams, it's a bit of an uplift in terms of role, we're going to move him now into IT team OU, and then back in OneLogin. That real time synchronization will have taken place. And if you refresh John's user profile page, we'll see that new data has come in. So we're now part of the IT team. We've got a new job title. Under Authentication we've got a brand new security policy. And under applications, we've now, also been made part of the IT team role, rather than the sales team role. That, of course, has then resulted in Salesforce being locked out, and if we refresh that new portal we can see that John's now got access to our new applications. Of course, when we come to suspend John, John will be immediately locked out the system. So, therefore, we are protecting all of our systems with OneLogin as the front end. So rather than having a user lying around for many months with access to hundreds of applications, as we're protecting the front end with OneLogin that suspension within AD results in the user being suspended in OneLogin. we're now deactivated, and then, of course, John will be unable to access any of these applications. We'll find that we are signed out. John tries to sign back in, and we're prevented from doing so. So we're protecting all of our applications, all of our estate, with OneLogin in the front end. In terms of the applications, then, we've got around 7,000 applications within our application catalog, and these range from everything forms based applications, all the way through to more modern authentication. Plus we also have generic connectors in there, as well, for SAML, OIDC, WS-Fed, and also forms based authentication. So as long as an application supports one of our supported endpoints, we will have a means to sign users into that secure application. Connecting acts is extremely simple, some of these applications actually have one click set up, so something like Office 365, you just bind the APIs, click go, and it will go into all the work for you. There's no need to manually run any PowerShell, it's there, and done automatically in the background, the same is true for Google Workspace. Within each of these applications we've got means to map parameters, so which parameters in OneLogin map across to the parameters in Office 365. Our rules allow us to create role based access control within the actual application itself, as I mentioned. So lots of options when it comes to the provisioning and management of users, and of course also, we can do additional things when we come to deprovision the user as well. With OneLogin workflows we can start to enhance that provisioning and deprovisioning flow, by starting to create custom recipes around what we want to do with that data transition, or maybe around the user profile when that user is deleted, for example, moving the data to a manager or changing that mailbox to a shared mailbox. I've already mentioned our RADIUS and LDAP endpoints. We can layer multi factor authentication on top of those, but let's move across into our security. We have our authentication factors which allow us to manage strong authentication, of which we have many different flavors. When it comes to policies we have two types of policy, we have an application policy, and a user policy. Our application policies allow us to perform step authentication into an application. So rather than the user being allowed immediate access into an app, we're enforcing additional controls on top of that application. For example, only allowing that app to be accessed from a certain IP address. Maybe forcing the user to perform entire authentication again, or looking for a specific MFA option. In addition to all of this, we can also start to look for a trusted device through a third party certificate, or utilize OneLogin vision AI. This is our risk learning tool, this is our ability to use machine learning to look at that risk of the login, using around 60 different measures. Everything from the time of day, type of user it is, the browser, the machine they're utilizing, is it a risky IP address. And then with smart access in our app policy, we can deny the access based around how high that risk score is. Within our user policies, of which we can have many and be extremely flexible when we assign, we have many different options in here too. Everything from our smart flows, that I mentioned at the start, through to our passport controls, our session length, and then our MFA options, and we can target MFA based upon the user policy that the user is assigned to. Smart access appears in here, also, so we can deny the user access to the entire portal, but we can also suppress MFA utilizing exactly the same means, as well. Just a quick demonstration of smart access and smart MFA, just to give you a flavor of what that can look like. I'm going to go and open up a few different browser windows for the same user. This user has got an IP policy applied to them, and that policy defines it they have to use MFA during the sign in process. However, at a high risk score they'll be denied access, and at a low risk score, they'll have their MFA suppressed. This is Bob's normal browser, normal time of day, and a reasonably normal login for him. We're also utilizing the brute force defense flow with this particular policy, as well. So on the second login attempt, we will find that we're switching around where MFA sits. So on his first attempt we've just had to use our username, a password, and we're allowed into Bob's profile. Would be, if I typed Bob's password correctly. So Bob is now allowed into the system, very simply and easily, very frictionless. But what happens if something changes? Well, we want to make sure that we're protecting our systems. So if Bob goes and signs in from a new location, maybe a new machine, we're gonna simulate this with a brand new browser window within an incognito session. So Bob is going to go and sign in with this particular browser on this occasion. We're going to use exactly the same credentials as we did before, but this time, as it's a low trust session, we'll find that Bob is prompted for his second factor. The risk score has exceeded the minimal risk score that I have set to suppress MFA, therefore we are prompted. We've also got to end our password, but we're still allowed into the system. The risk score is low enough to allow us through into our particular system on this occasion. Of course, with the high risk log in we want to deny access, and for high risk log in I'm going to simulate that with a Tor browser. So I've got my Tor here, on this particular machine. This machine is actually running one OneLogin Desktop, so I'm signing in with Rebecca's credentials, but we're just going to use a Tor browser at the sign in, as Bob. So we'll try and sign in as Bob, with this particular browser. We're using the same tenant for this. We click continue, we'll find that we are once more prompted for our second factor, this particular browser doesn't support Webauthn, so I'm going to have to switch to a different factor. So I'm going to use my second factor down here, and I'm actually going to use a manual code. So if the push notification doesn't work you've always got a backup to be able to go and enter a manual code, which is, has the TOTP within the application. Plus we're being prompted, as well, for Bob's password. We're taking him through the entire sign in flow, we're not revealing exactly which steps failed, but we've denied Bob access. We can also adapt OneLogins vigilance AI to start denying access based around other factors as well. Maybe we're not expecting sign ins from specific regions of the world, or certain browsers. So we can do that with our vigilance AI API. And, of course, we're API first, so everything appears within the API before it appears within the UI. This particular browser is Epic browser, and allows me to set a proxy breakout, so I've set that to Singapore. And I've actually changed my vigilance AI to block any access from Singapore. So if I try and sign in as Bob one more time, and we'll see that we're denied access. And the reason why I've done this four times will become clear very shortly. We're going to pivot across to our events log, and have a look at the kind of information that we store, and are able to stream to other solutions, for example, a SIEM or a CSV. So again, we're using the brute force defense play, we're using Bob's passwords, we're denied access because we entered the password, bear with me. I will enter the right password, and then we'll see our access is denied. So back to our admin console then, here we are back in the same admin console, and we're going to go to our events log. We store everything in here, around the user authentication flow, but also the admin actions and the system actions for the environment. We can see Bob's first log in right down the bottom here, and that was five out of 100. So this is the risk score that's being generated by our vigilance AI. The second login attempt was 19 out of 100, and this is flagging the risk reasons that were triggered to generate this particular risk score. We don't show the weighting for these, we just show the actual risk reasons that were triggered. We see a new browser session, and a low trust session. The third login attempt was 99 out of 100. We can see in this case, we were accessing from a Tor network. We had a browser that was simulating Firefox on Windows, and this, then, all built that risk score of 99 out of 100. We've also got our last one here at 100 out of 100, and we can see the main reason for that is Singapore's being blacklisted, but we're also logging other things, such as the log in velocity. So this is a high velocity of travel, a Superman travel [INAUDIBLE]. And therefore, this is also going to add high weighting to our risk score, even if this wasn't blacklisted this would create quite a high score for the user. Now as I mentioned, we could stream this to a SIEM or CSV or use our events API to pull that out into any relevant logger, so lots of options there. But it might be we don't have that solution as a customer, and that's where our in-built reporting comes in. Many different report types in here, whether that be our standard reporting, or whether that be our custom report that we can create within here. And we can also set up notifications as well for things that occur within our system, not just about, coming into the system, and seeing what's happened, we have many options there too. Now when it comes to enhancing the platform it's not just about what we've got in the here and now, and what's available by the UI. Of course, we have many options for developers to start utilizing, so if we go to developers.onelogin.com that will give you access to all of our APIs, and the ability to start building those as well. We start-- we've with documented a huge amount around this side of things. Administrative APIs are fully documented with Postman collections, and links to our SDKs, as well as it being documented, in full, for customers and partners be able to have a play with the APIs. We also have a number of development blocks, as well as a Terraform provider, and of course, also, we provide support for particular developers to be able to utilize as well, currently via our Slack channel. Thanks, so that covers off the demonstration of the product. Hopefully that gave you a little bit of insight into the platform, I'm going to hand back to Philip now, and we can continue with any question we may have. Hey, thanks, Mark. Thank you very, very much. I was amused by your example of John the user removed from sales into IT, that could be a career move I'm going to be making any time soon. We rely very heavily on you Mark, and thank you for the education and enablement of our partner community. We couldn't cover everything today, as you said, and that's why, hopefully, it's given everybody a flavor of the conversations they could be having with their customers, their install based customers, already today. And we would start to schedule with Susana another Tech Talk session, probably mid January, with a follow up around any of the questions that came during today's session. There was one question I caught, which was around accreditations. Yes, we have accreditations around sales, pre-sales, and also for a full certified implementation partner. But please be a little bit patient, all of those accreditations are being moved over into partner circle, and we made an announcement yesterday on a global partner call, so those accreditations are being moved over, and you will have access to all of those accreditations, and sales enablement, and technical enablement tools to get you a fast start. Because, and the last thing I'll say and I'll hand over to John is, this acquisition is moving really fast from the channel side, our sole goal is to make you successful, so we're taking down any barriers that would, in any way, inhibit your fast ramp up on the OneLogin portal side. And with that, I'd like to hand back to John. Thank you Phil, and thank you, Mark, for that demonstration. I hope you agree with me that you listen to this demonstration, you see how easy, how flexible, and how powerful the solution from OneLogin is, so really exciting addition to the One Identity portfolio. We don't have too many other questions coming through, but there is one, and I'm going to pass this to Mark to answer. In terms of the intelligence AI you spoke of, does this require a baseline to be captured? And if so, how long does it take? Yeah, absolutely. So we would start to capture that immediately, as soon as the user started to sign in. So within a few logins we'd start to understand what that looks like. It's machine learning, so it's constantly learning about that user profile. So if that user were to maybe relocate to a new location, it would start to learn what that new location looked like. And if the user then moved to a different location, again, it would start to learn. It's not just around the location though, it's about the machine type, the other things that are going on in the background. So even a change of location might not spike the risk score totally. So there's many different things going on in the background. But yes, we do start to capture a base, I think it's very high to begin with, of course, but we have means with our Smart Hooks to be able to change log in flows to adapt to what users do during the first few log ins. OK, thank you very much. Now we're coming to the top of the hour, and so we won't keep you longer. What I would say is, watch out for further information from us about the integration, about more ways of learning, and getting up to speed with the solutions. If you have any further questions, feel free to reach out to any of us, or your channel manager, we will do our best to answer your questions. So with that, again, thank you for your time today. Thank you Phil and Mark for your presenters. Susanna, have I missed anything before we wrap up? No, I think everything has been set. This session has been recorded and will be on the partner portal for a rewatch, or if you weren't able to watch entirely all the time, so that's that. And we are going to announce the next Tech Talk which will be technical, again, of course. Yeah, probably for someone in January, and we will keep you updated on the integration of [INAUDIBLE]. Thank you very much for joining today. OK thank you Susanna, thank you very much everybody, we'll leave you to the rest of your days. [MUSIC PLAYING]