Demystifying Device Trust
Speaker 1: With that, I get the pleasure to introduce Teju Shyamsundar, how'd I do?
Speaker 1: Almost. She's a technical marketing manager here at Okta in the product group. Prior to Okta she worked at Microsoft and implemented enterprise mobility technologies across the largest of enterprise customers in various industries. Teju now works on integrating the Okta solution with our customer partners. Our customers are partners in applications and enabling our team to be successful with securely connecting Microsoft technologies. She holds a BS degree in computer and information technology from Purdue. Without further ado, Teju.
Teju: Awesome. All right guys, thank you for joining, good afternoon. For those of you who haven't met me yet my name is Teju Shyamsundar, I'm a technical marketing manager on Office Product Team and I focus on integrations across our core set of technologies. Over the past couple of months our mobility team has been working on some really cool features that focus on application and device level security, so today, I'm here to talk about something you've probably heard a lot about, but maybe needed some additional clarification on and that Okta's Device Trust Solution.
Before we get into the technical details, I just wanted to share with you, what is Device Trust; why is it important; why is Okta investing in it; and why is it important for you, as a customer, to learn about what Device Trust is? Starting off, we've seen a change in the way that people are accessing applications. As Todd had mentioned in his keynote, every company is now a technology company to some extent and because of that, we're moving away from a perimeter based approach to more of a cloud and user-centric based approach.
What that means is that we have end users that are accessing application across a very broad set of clients, platforms and browsers. We've set up Okta's Device Trust Solution to really encompass that zero trust security world that we see today. Device Trust is Okta's contextual access management solution to make sure that your end users are accessing applications from a device that you know is trusted.
In all the discussions that we've had with customers, we've really seen three target use cases come up. The first one that we see is that we know customers want to prevent unmanaged devices from accessing Okta integrated applications. What that means is that only devices with the right security posture can access these apps. As an example, let's say you're looking to add a couple of security policies to Office 365. You may want to even get as granular as saying that you have a breakout between web browsers and big client access versus different platforms that can access Office 365.
The second use case that we see is that, again, we want to protect that enterprise data, even when there's no defined network boundary. Again, we're seeing our end users access applications from a variety of different platforms and browsers, not just in the office, but anywhere really. Maybe it's a coffee shop, maybe it's an airport. We want to make sure that regardless of where they're accessing from, we can ensure device level and application level security.
The last one is that we want to deliver a better end user experience by providing less MFA prompts for IT managed devices on network. This is a common request that we get from customers, but one thing to keep in mind here with our Device Trust Solution is that it's not really meant to be a replacement for multifactor authentication. We want you to use Device Trust alongside with multifactor, so that gives you the security of knowing that not only do you have a trusted user accessing an application, but the access is also coming from a device that you trust.
We've seen a shift in the way that people work. We no longer see the standard nine to five, working from an office, working from just an active directory domain joined Windows machine, right? If a user works outside the office perimeter, they could be funneled in via a VPN, for example. But we see a very interesting technical challenge in how end users access applications from other sources, like the browsers that you see up here, the platforms that you've seen. Not only do we have our employees accessing these applications, we also see partners and customers accessing these applications as well.
We've really built our Device Trust Solution to target the broad range of platforms that you see users accessing applications from and while that may seem easy, there's really no one solution fits all because of the different technical challenges that arise from the different platforms that our end users are accessing applications from. We know the target use cases and we understand how end users are accessing applications, but what are the concerns that IT has around those use cases?
The first one is that our IT admins aren't able to enforce security policy before granting access to cloud applications. After they've accessed an application there're maybe some policies in place that you've put in, but we don't actually access the devices security before the application's accessed so that's something that Device Trust targets.
The second is that IT admins don't have much visibility on the number of devices that are accessing applications. So, not only do we want to protect these applications, we also want to know how many devices are accessing a specific app and who's actually accessing that application. Lastly, we of course want to prevent, data loss due to malware ridden or hacked devices.
Okta's policy framework has really been ... sorry ... Okta's policy framework has really been the first sign of defense in keeping your organization secure. You've probably already seen that we have sign on policies available for our cloud applications, which allow you to control various elements of security, through authentication challenges, password complexity et cetera.
You've also probably seen that policy can be based on a variety of factors such as maybe location or a group that a user is a part of. So, we allow you to create conditions like, IP restrictions or the user is ... what group they might be in, before providing access to an application, and even past that we can even add additional actions based off of these conditions. That either allow you or deny an access to an application or even restrict application scope.
What Devise Trust is, is a solution again to limit cloud application access to just managed device. First a device is going to connect directly to a cloud service that's all already also managed by Okta, such as box or maybe Google Apps for work or Office 365.
Next the cloud service is going to delegate to Okta for that access decision, so again this could be things like IP reputation, authentication against Casby providers. What EMM you're using, any mobile security policies et cetera, and then Okta assesses the risk by incorporating all that data from multiple sources and finally the end user has access to the cloud service.
With the Device Trust we've built on a technical approach to ensure a couple of different things. Both for admins and for end users. The first is that we're allowing for broad application coverage, so we're not just targeting major applications that your end users might use. We'll support all Okta better rated applications.
Second we're offering best of breed interoperability with other EMM solutions. On the mobile side, we'll be able to integrate with other mobile device management providers, and then on the desktop side you can use your existing management tool to assess a devices security posture and I'll talk to you about that a little more. We also offer great end user experience and lastly low complexity.
What these four pillars, I'll go through the technical approaches that we've taken per platform, and what you can actually start testing today as far as Device Trust goes. So starting with our workflows for Device Trust, now that we've gone through what Device Trust is, let's actually take a look at the technical approaches that we've taken to make sure that each platform is secure and protected.
How do we actually assess Device Trust based off of the platform or where user's accessing from? First on the left here we have windows. For Windows what we do is check if the device is Active Directory domain joined, and if it is Active Directory domain joined, we're going to issue an Okta CA certificate to that device, and only devices with that certificate are going to be able to access your Okta managed applications.
For access to Exchange Active Sync what we do on the Okta side is help you to deny access to Exchange Active Sync from unmanaged devices. What that would look like for an admin, is that you would just configure a deny policy for Exchange Active Sync after you set up certificate based authentication in Office 365. The third one for IOS, what we do is check if the device is managed by an MDM solution. If the device is managed by an MDM solution, the end user then has access to that application that we've protected.
Again as I mentioned earlier, it might seem easy but really there's no one solution fits all for these platforms. Taking a look at the technical challenges of a contextual access management solution. The first is that for IOS, applications can either use Safari View Controller or Safari as well as Embedded Web View.
Applications that do use Safari or Safari View Controller have access to the certificate store on a device, which means that we could use certificates for an IOS solution. However, most applications actually don't use Safari or Safari View Controller, so that's where that limitation comes in, because applications that use the Embedded Web View, actually don't allow for access to the search store.
If it was a challenge for a certificate, authentication would fail. First, we had to address how we're going to interact with applications that support this certificate challenge versus ones that don't, and how we can provide a solution that will encompass both of these apps.
Then on Windows what we see on the browser side or the challenge that we see on the browser side, is that there is certificate picker's within these browsers. So, each time you go to access an application, the end user is going to see a certificate, which we don't want as an end user because it adds some friction to our overall experience. What we've done here is actually use an Okta device trust installer that configures the policies in your browser so that end users don't see the certificate picker when they go to access applications.
As an end user even after a policy has been added to your device for Windows Device Trust, you really see no difference in the way that you're accessing the application because that certificate picker is concealed to the end user. Here's an example of how you would configure Device Trust as an admin.
On the left side here you can see that configuring Device Trust within the org itself is pretty quick and simple. You just check the boxes for either Desktop Device Trust or Mobile Device Trust or both, and then you're good to go from there. Then on the right side is an example of sign on policies that you can configure for an application.
The one that you see here, is actually specific to Office 365. So in this example what we've done is show that authentication from a web browser or at the client that supports modern authentication is going to be allowed on IOS and Windows devices that are trusted. I'll show you what that looks like as far as end user experience in a little bit.
Before we go into the demo portion for Windows, I just wanted to go through the technical workflow that an end user or a machine goes through before it has access to an application. As a very first step what you're going to do is download our Okta Device Trust installer. This is an MSI or an executable that you deploy to all of your windows and points, that's going to start that Okta CA certificate enrollment process.
Once you have access to that tool, what you're going to do is distribute it again to your windows end points. This can be done with any management tool that supports deploying MSI or an executable. It could be something like Systems and Center Configuration Manager or whatever you use as your end point solution today.
Once that Device Trust installer has been distributed to all your machines, what's going to happen is that, the client is going to communicate with your existing IWA setup, to confirm that the device is domain joined. This is where IWA comes into the picture during this enrollment flow. Just read the initial certificate enrollment piece of it. Once that's done the IWA agent is going to provide an access token to the device, so that the device can start the process of enrolling into the certificate from our Okta CA.
Next the client is going to use that access token to authenticate with Okta CA and once that's done the certificate is now granted to your windows end points meaning they're considered trusted devices in Okta. Once a certificate is on the device, the end user is going to have access to all their cloud applications that are managed by Okta determining that it's a secure device based off of the presence of that certificate.
Going into the demo for what it looks like, on the admin experience, and then what it looks like as an end user on Windows. Starting with our admin experience here, what we're going to do is start with actually enabling the functionality for Device Trust. I'm going to come into my security section and choose Device Trust, you'll see a new option here. When you're in this section you'll see Mobile and Desktop Device Trust.
I've already enabled Device Trust for both mobile and desktop here. What you want to do in the desktop section here is, add an external link for your users to reference in case they are not able to access an application. The idea is that they would then be redirected to this link automatically where they can learn a little bit more about why they're not able to access a specific application, and that's most likely because that certificate from the Okta CA is not on their device yet.
I've done this already. Now, I'm going to go into my application sign on policies, and it's going to look a little bit different once the Device Trust functionality has been enabled. I'll look at a few of them here let's start with G Suite first. I'm going to come into my sign on policies, and we can see here that we have a few different policies defined.
What really defines Device Trust is ... in this section here, where I'm specifically saying that I only want trusted devices to be able to access G suite. In this scenario I'm allowing IOS and Windows devices which are trusted to allow to access G suite, and if you need to add multi-factor authentication settings, you can do that here as well. Similar to what you see today with our existing sign on policies. I've already done that.
The other thing that I've done is deny Android devices. We can see here that if I come into my android section, I'm choosing that basically any android device that tries to connect is denied since we're not able to assess the security posture of android devices yet today. So that's done for G suite now let's say I want to do the same thing for Office 365.
I'm going to go back into my list of applications here. Alright, so going back into my applications, I'm going to go to Office 365 this time, go to the sign on policies, and you'll see here that I've defined a similar set of policies that either allow or deny trusted or untrusted devices.
This one that says, "Allow trusted IOS and Windows devices," I'm going to go ahead and edit this one and we can see here that I've chosen that web browsers or modern auth clients and you can see here that now we're actually able to differentiate between web browsers versus modern auth clients for Microsoft Office. This is a feature that's in beta right now,, and accessing from IOS or Windows that are trusted are now allowed to access Office 365.
Then the other thing I've done is just explicitly deny untrusted Windows devices. So any Windows device that's accessing from again web browser or modern auth client that's not trusted is now denied from accessing Office 365.
Now as an end user, if I go to my Windows machines. Let's start with the device that is trusted, meaning the Okta CA certificate is already on the device. What I'm going to do here, I've tried to access outlook, I'm just going to complete my sign in here. Once that's done connecting we should have access to our email.
To take a look at what that certificate actually looks like on this machine, I'm going to go into my personal search store, in the user store, and that's where the certificate is actually stored. I'm in the certificate store here, I'm going to add my user store specifically, and if I come into the current user ... okay, so while that's loading I'll show you some other items on this device.
I have access to my thick client once that's done processing, we can see that it's authenticated now. I'm just finishing uploading my profile, but I also have access on browsers. Here I'm on Chrome, I'm going to go ahead and log in to Okta. Once I'm in, I can see that I have access to my Office 365 applications. This user is assigned to Office 365 in Okta.
I'm going to go ahead and click on one of the Chiclets here, which is Outlook. You can see here that the user is presented with some information that says that it requires a certificate to access the service, but we're not actually prompted to choose a certificate because the Okta Device Trust installer has already done that for us. Now I can access my email with no issues.
Going back to that certificate store here, when I come into the personal folder, choose certificates and you can see that we have that Okta CA certificate issued here already. It's issued to this specific user and the certificate authority is just called MTLS certificate authority, so because the presence of that certificate, it's why I am able to access these applications. Then there's just additional details about the cert here. There's also some information in Event Viewer about the issuing process for the certificate. You can see that I'm also in Outlook now, no issues I'm able to access my email.
Now let's see what the end user would experience if they try to access an application from a Windows device that's not trusted, meaning the certificate is not present on this device. I've already started the process to log in to Office 365 here, so I'm going to go ahead and complete that. What we're expecting to see here, is that the user is not able to access their email because this device doesn't have a certificate on it.
You can see here that they're redirected to this page that basically shows them the URL that you would have presented in the Okta org for Windows Device Trust. This can be customized to really any URL. The end user is going to get redirected to this because their device is not trusted and they're going to see the same experience on a browser. So, if I try to log in using my browser here, if I click on any of these applications, the expectation is that I'm not able to access it and I should get redirected to that same URL because it's not a trusted device.
We can see here ... let me maximize that sorry ... we can see here that I'm not able to access the G suite application because this is an untrusted device. This is the end user experience for a trusted Windows device versus untrusted. So let's head back to our citation here. That's the end user and admin experience for configuring Device Trust as well as what the end user would see if they are trusted or untrusted.
Just a quick summary of Windows Device Trust as a whole. First thing is that we're restricting application access to Active Directory domain joined devices that have that Okta CA issued certificate. The second thing is that this solution that you see here, as far as browsers go, it works with Internet Explorer, Microsoft Edge and Chrome across any Windows platform that's supported by Microsoft, so, today that would be Windows 7, 8.1 and 10. It also applies to any cloud application and native applications. Today we support Microsoft Office clients that support modern auth, so that's going to be Office 2013 and Office 2016.
Moving on from windows, let's talk about Exchange Active Sync and IOS. If you look at the top half of the screen here, steps one through two and three, this is kind of our ideal workflow for an end user that's trying to access Exchange Active Sync, if they have a certificate. The assumption here is that you've already enabled search based authentication in Office 365. The end user has that Okta CA certificate on that device that's being pushed through maybe Okta Mobility Management. The certificate is going to authenticate that user, without the need for credentials, meaning they don't have to put in their password and from there the end user has access to their email.
Now where Okta comes in specifically in this Exchange Active Sync workflow, is actually denying access from an unmanaged device. Meaning a device that doesn't have that Okta CA certificate on it. What the workflow looks like there is that, the user actually types in their username and password into the native mail application in IOS. They're going to be redirected to Okta but because you've defined that sign on policy in Okta that's denying end user access, they're not going to be able to access their email.
The second part here is really where Okta comes in to play in regards to Exchange Active Sync. All you would have to do as an admin is create a sign on policy that denies access. Now moving on to our other applications. As we mentioned our Device Trust Solution works across any SAML, or WS-Fed application. Let's see what that looks like as an end user. You're going to go to access an application and you're going to be redirected to Okta. This is where Device Trust kicks in. Device Trust is going to require users to sign in through the Okta Mobile App. That's how we assess the security posture of a device for IOS.
Okta Mobile is going to verify Device Trust. What that means is that Okta Mobile will check for the presence of an existing MDM profile on the device. If that profile is there, Okta Mobile will complete the sign in and the end user is going to have access to all of their applications. This is the workflow for any SAML or WS supported IOS application. You can see that it's separate from the Exchange Active Sync because we're actually enforcing Device Trust through Okta Mobile in this scenario.
The other thing that we wanted to highlight is that our Device Trust Solution is not dependent on Okta Mobility Management at all. We're actually able to integrate with the MDM providers. This is functionality that you'll see us bring to the product over the next couple of months, and as an end user, it's really going to be the same exact experience. The only difference in this scenario if you're using a third party MDM provider is, this point that you see here, where you're going to use that third party MDM to distribute Okta Mobile and use managed App config to let the device know that Okta Mobile is a managed application.
After that, the end user experience is the exact same. They're going to go to access an application, Device Trust will kick in to make sure that the device is managed through the MDM of your choice. If it's not managed, they're going to be prompted to enroll and then from there they have access to the application.
Let's take a look at a couple of different scenarios with IOS. The first scenario that I wanted to show you is that, in this case we've created a sign on policy for G suite to make sure that only trusted devices can access this app. I'm going to go ahead and sign in to G suite here. All right now, one second guys. Let me try that one more time. If I go to sign in to Gmail, put in my username. I'm not sure why that workflow isn't working but let me go through a video of what that should look like as an end user.
Here we see an end user that's trying to access Gmail, this device is not yet enrolled to an MDM. So, what they're going to do is put in their credentials, try to access to Gmail. What's expected at this point is that they're going to be redirected to Okta since the G suite application is managed by Okta and after that, they'll be prompted to check that their device is secure, meaning check that it's enrolled into an MDM.
You can also see here that we've introduced Touch ID for Okta Mobile. That's another feature that we'll release over the next couple of months. Once the end user has verified that they are enrolled into an MDM, in this case they weren't yet, they're going to be prompted to go ahead and do that, and then at this point they're able to access the application.
What they're going to do is be redirected to Okta Mobile, go back into Gmail and then you can see that once they're back in Gmail they have access to the application with no issues. You can see here that even if an end user is accessing Gmail from an untrusted device, within minutes, all they have to do, or really within seconds they just have to enroll their device into Okta Mobility Management or another MDM and then from there they're able to access email with no issues.
The end user experience on Outlook is a little bit different. What we've introduced here is something called Native Mobile App SSO. Which means that the end user actually doesn't have to enter their password at all, in order to access Outlook. This is specific to Office 365. What it's going to look like as an end user here is that, they're going to go to outlook, put in their email. We still want to make sure the device is secure, so they're going to be prompted to do so. So, they're going to go ahead and sign in with Okta.
We can see here again that we have Touch ID enabled on this device, we're going to go ahead and secure the device now and that's going to complete the enrollment process into OMM and from there the end user has access to their email.
One thing that you probably noticed in G suite that didn't show up in Office 365 is a requirement to enter your username and password to log into Okta. With Outlook we're actually able to use a Native Mobile App SSO, so that an end user can seamlessly log into their email without having to enter their password. That's where the Touch ID comes in, or if you still are using a pin for Okta Mobile, you would just do that instead of having to enter your password. We're able to access email with no issues from there.
Now the other thing that I had set up in this org is denying access on Android and MAC devices. Let's take a look at what the end user experience is like there. I'm going to go ahead and access my org again, put in my credentials. As an end user you can see that I don't have access to applications that have been protected by these sign on policies because I see Mac-OS as an untrusted platform, because I'm not able to assess a devices security posture on MAC today.
The last thing that I wanted to show you is how we actually integrate with third party MDM's. Let's say you have a scenario where you do want to Okta's Device Trust, but you're not actually using OMM as your mobile device management provider. What you're going to do here is, the same workflows, I'm going to go ahead and log into G suite. Put in my credentials and you'll see that it's still going to prompt me to make sure that my device is secure, that I'm checking in or signing in, in a secure manner but, in this scenario I want the device to actually enroll to Air Watch as my MDM and so I'm going to be prompted to do that in this process.
We can see here that I'm automatically redirected to my Air Watch enrollment URL, I'm going to put in my information to actually enroll into Air Watch and that's going to allow me to finish that authentication process. It's a similar experience on Outlook, so let's say I'm doing the same thing on Outlook, I've put in my email address, and I'm going to sign in with Okta, I get redirected, I'm going to put in my password here into Okta Mobile, and again I do want to check the devices security posture, but I don't use OMM as my MDM solution. I'm going to go ahead and actually complete the Air Watch enrollment process in this scenario. I'm going to put in the credentials that I used to enroll into Air Watch, and then from there it'll prompt me to add that MDM profile to the device.
Once that MDM profile is on the device, the end user experience is very similar to what we saw when we enrolled into OMM which is that they're able to go back into their application without having to re-authenticate, and then from there they're able to access their email with no issues. Now that the profile is done being installed, the end user is going to get a couple of prompts that show them that Okta Mobile is now a managed application, as well as Outlook which is also going to be a managed application in this enrollment scenario. Just a couple of seconds that notification should show up.
We can see here that Air Watch is going to install a couple of items on this device. Okta Mobile management taking over control of Okta Mobile is one of them and then from there the end user has access to Outlook with no issues. All right, so you can see here that we're not restricting users to enroll into OMM specifically. We're going to be able to enroll not just into OMM but your existing MDM solution and that's something that we'll be releasing over the next couple of months.
Based on the demos that you saw there, here's a quick summary of IOS Device Trust specifically. The first is that our goal with IOS Device Trust is to restrict application access to devices that are MDM managed. We also are going to offer support for any SAML or WS-Fed application and this is going to be supported on anything IOS 9.0 and above.
Again Okta Mobility Management is not a requirement to enforce device trust on IOS. Lastly for the Exchange Active Sync piece of it, where Okta comes in, is where we create a sign on policy to explicitly deny access to devices that don't have that Okta CA cert on it.
That's all we have available for you to test today with Device Trust. You know when you leave Oktane and you decide that you want to go test this, you're going to be able to test Windows Device Trust and IOS Device Trust both of which will be EA.
A quick overview of Device Trust as a whole. First again we're going to be able to support all SAML and WS-Fed applications across all platforms. Device Trust provides a seamless and reliable end user experience. You can take use of your existing EMM or MDM solutions so that the end user doesn't have to go through the process of un-enrolling their device from an MBM in order to get this to work.
It's also a low complexity set up for Okta administrators. So what you saw in the org today when I just checked a couple of boxes for allowing or denying connections based off of the devices security posture, that's really all you need to set up. There's no dependency on like an Active Directory Certificate Services environment or any on prime servers to get going. Lastly again we'll provide best of breed interoperability with third party EMM solutions, so that's both on the desktop side and mobile.
Then the quick roadmap overview here, so again today we have Windows and IOS Device Trust in EA. Actually IOS Device Trust will being EA next week for production. Then around the January timeframe is when we plan to release Device Trust for MAC devices and Android and if you want to take a look Naveed's section or presentation tomorrow on not just Device Trust Roadmap but just our mobility roadmap in general. He'll be able to provide a lot more details on what you saw today plus some of the other cool things that we're working on.
We also have a few other mobility presentations coming up both today and tomorrow. So today we have Snegha presenting right after this, as well as Ankit and then tomorrow we'll have Mike and a customer panel around mobility and then again Naveed will be presenting his roadmap for mobility tomorrow. Alright, with that I wanted to thank you guys for joining. Hopefully, the title of this session lived up to its name and you have a little more clarity around Device Trust. Thanks guys.
Different browsers, platforms (Windows, iOS, Android, Mac), and applications make device trust a complicated topic. Learn how we're working to simplify device trust and empower you to only allow users with devices that meet your security standards to access corporate apps and data.