Transcript
at Okta. Today we're going to be diving into how to best elevate your Okta user journeys within the Okta Customer Identity Platform. Now there are quite a few ways for us to take into consideration implementation details when it comes to elevating user journeys. The first I'd like to dive into would be self-service registration extensibility. And what you're seeing is the ability for us to create these custom policies within the Okta Customer Identity Platform in order to implement maybe something like progressive enrollment or even just enable self-service registration in general. Some of these benefits include being able to create multiple enrollment policies, being able to determine the account origin, as well as providing the progressive enrollment functionality for your end users, and also having that ability to enrich profiles upon user journeys as they're navigating directly on your website. It's also very easy to configure and a very clean end user experience. Now let's go ahead and dive into a very quick demo of what this will look like. We'll go ahead and navigate to the Security tab and click User Profile Policies. Now clicking on User Profile Policies shows us all of the current policies that are currently within my Okta tenant. And right now I don't have self-service registration enabled. So let's go ahead and hit Edit and toggle it on. It'll be allowed. And then we're also going to enable progressive profiling. And these are some of the options that you can customize as well. The form header, submit button, and then we're just going to go ahead and save our configuration changes. Down here is where we can take a look at the progressive enrollment form, where we can actually add additional form input fields. So any additional attributes or metadata that you want collected for that end user, you can go ahead and customarily accept that as part of the registration form. And you can see here, we're also targeting some identification as well. We'll talk more on that later, but it is part of the enrollment policy. And then clicking on Applications, this is the enrollment policy for this particular app. Now once that's configured, let's go ahead and navigate to our sample application. And it'll be SecureBank, just a sample React application. When I hit Login, you'll see we're redirected to the Okta hosted sign-in widget. And then if I click Sign Up, we can see we're collecting the email as well as the last name. And let's go ahead and type in testuserplusone at echo.email. We're not going to provide a last name. We can go ahead and sign up. Let's enter in a password. Perfect. These are some of the other options available for us to register with as well. But let's go ahead and continue. And upon success within the navigation, you'll see we're brought back to the application. Clicking on Login will understand that there is an active session within the browser, and we can actually take a look that the user was successfully registered. And now we can log in. Great. Now let's go ahead and navigate to our next topic, Multiple User Identifiers. This one allows us to choose up to two additional attributes to essentially identify who the user is. So traditionally within the Okta platform, users are denoted by a unique username. But now we can actually align an additional two attributes, more inclusive of the original one, such that, for example, a single user can have a unique email as well as a username. And both can be used as the identifier to authenticate the user directly into our platform. And as you can see here, some major benefits include, you know, the ability for users to alternate identifiers when they go ahead and sign in. They might maybe forget their username. Well, they can sign in with their email, as well as allowing our administrators the ability to configure identifiers on a per-application basis. So you can do that via the policies. And then this also supports very unique custom user profile attributes as well. Now if we go ahead and dive right into the demo, you'll see we're still at the Profile Enrollment screen. But now we're back to the second tab where it says Identification. And this is where we can add, in addition to the username, another identifier. So let's go ahead and add personal email and go ahead and save that. It is a string. Now one additional thing we'll have to do is upon collection or registration of the user, we want for them to be able to type it in. So if I go ahead and sign out here in my sample application, hit Login. And if I sign up, you'll see it's just the email last name as it was before. But now if I go ahead and do a quick check, go back to the Enrollment tab, scroll down and Profile Enrollment Form. Now if I add an attribute, the username, this time, you'll see that I can go ahead and save it. And then we'll see it's now required an additional to the email. If I go back to the application sign up page, we'll see email is now added to, or I'm sorry, username is now added to the registration form. So in addition to test user plus two at echo dot email, I'm also using the username without the domain. So perfect. I can go ahead and register and providing a password allows me to go ahead and bypass this as these are optional and perfect. I was able to register with both the unique username as well as email address for this individual user. Now going back to our slides, the next topic item would be create users without a password. Essentially a passwordless user. So true passwordless or users or a true password free user allows us to essentially create these users that don't necessarily require a password to authenticate into our platform. They do have to have some form of authentication. So this essentially leads to some benefits that you can see listed here where they no longer need to have a low assurance level credentials. So something like a password traditionally is a little bit more of a lower security assurance. We can also reduce maybe costs associated with having to manage and recover passwords. All of that overhead typically is associated with having to manage multiple passwords at a time. And then we can also avoid the possibility of password spray attacks if there are no passwords. So at least the signup process could be necessary, you know, essentially sped up and this in turn would improve security as well. Now if we go ahead and dive right into the demonstration here very quickly, let's go ahead and navigate back to our sample application, but also the admin console. And if I scrolled up, we'll see what's still on the user profile enrollment form, but we're going to go ahead and navigate out there and into the authenticators tab right here. With authenticators, this is where we can take a look at enrollment policies. And this essentially dictates how users are going to be registering onto your application platform with, you know, how they're essentially going to be authenticating. You can see here the default policy is currently set where passwords are required. And the other four, email, Google Authenticator, Octaverify, FIDO2, are optional factors. But let's go ahead and create a no password users policy. And we're going to make email required, or maybe let's go ahead and make Octaverify required. Instead, email should be optional. And if I make password optional now, we'll see we can create the policy and we'll have to assign it to a group. So let's go ahead and... Okay, so initially we're doing administrators here and create the policy. If we're checking the other rule, we'll see we have to add this additional rule to allow how the enrollment will look for these applications, a couple options for us to define specifically for this particular rule, as well as policy. We're going to go ahead and just give it enrollment no password rule, create the rule. And now let's go ahead and actually adjust the group very quickly. So I'm going to click on actions, edit the policy that we just created. Instead of the administrators group, let's go ahead and do everyone so that it'll be applicable for anyone that registers on our platform. So let's go ahead and do everyone and save. Now, if we navigate back to our sample application, we'll see, okay, let's go ahead and log out. Now if we sign up as test user plus three at echo dot email, and then the username without the domain, sign up, we'll see, instead of prompting me for a password, I'm now prompted for OctaVerify as my primary authentication method. So let's go ahead and register. And we're going to go ahead and copy the QR code on our OctaVerify mobile application. Once that is successful, you'll see we are now prompted for optional factors as well. In addition to OctaVerify, I'm going to go ahead and skip all of this, hit continue. And now successfully, I'm able to register and this user is no longer, you know, required to have a password. So I can essentially use OctaVerify as my primary authentication method. And the user itself doesn't have a password. So, you know, very much immune to those password spray attacks and authenticating may be a little bit easier. I don't have to remember my password and the event that I lose it, I can just pull up my device and authenticate that way. Okay, great. Now let's go ahead and go back to our slide deck. And the last feature I want to talk about is Keep Me Signed In. Essentially Keep Me Signed In is a feature available on the Octa customer identity platform that allows us to provide more granular control over the feature itself and also containing it within the authentication policy. So this essentially allows us to customize how frequently it pops up so that we can, you know, keep track of the user session, making sure that they don't necessarily have to, you know, reauthenticate if there is an active session currently within the browser. Or we can also prevent any unnecessary MFA prompting or challenges if they do, you know, necessarily want to enable Keep Me Signed In at the granular level. One thing to note is this particular feature that I will be talking about and showing is going to be post authentication. And specifically, I will go into the visuals to show that there is also the pre authentication option as well where we're passing it as part of the login process. So let's go ahead and dive into the demonstration here. And if we go ahead and navigate to our Octa admin console, we see that under, well, before we navigate to authentication policies, we have to go ahead and navigate to general. And this is where we have the remember user on sign in. This is the pre authentication option here where you can toggle it on and it'll be passed as part of the login process where the user can be kept or remembered, if you will. The post authentication method, which the feature is alluding to that I was previously showing in the slide deck, is currently within the authentication policy tab. So if I go ahead and navigate to my Iron Bank spa react application, you'll see toggling on actions, hitting edit, and scrolling down, we see this option here where we have an additional option where it says option to stay signed in. So show after user sign in. And this allows us to configure this so that if the user does want to essentially stay signed in, they can go ahead and toggle that. And we can even adjust the time limit just to make sure that we're remembering the current device for a certain period of time. And if we scroll over to down here, we'll go ahead and save it. And to show you the behavior, let's go ahead and log in. Navigating to our custom application, clicking login. We see that when I type in my user, it's verifying. And if I hit next, okay, let's go ahead and enroll in OctaVerify. Upon successful authentication enrollment, we'll see that. And let's skip those optional authenticators. We'll see this prompt here where it says keep me signed in. So sign in and enter security methods less frequently. So if we're prompted for MFA, this will reduce the frequency of it. Let's go ahead and stay signed in. And perfect. We're able to establish the session and go ahead and authenticate into our sample application. Let's go ahead and sign out. And I thank you so much for your time.
