JumpCloud Go-es Beyond Chrome

[urvashi]

This is an edited transcript of the 04.19.24 IT Hour

Overview 

• Scott Reed, Senior Product Manager talks about the additional browsers that can now support authentication with JumpCloud Go. 
• He also answers questions from the audience 

Transcript 

Scott: Everyone should love device bound credentials. It’s just kind of the reality of the world now. Device bound credentials are the bomb - a better user experience, a more secure experience for us and our organizations. There’s no question that device bound authenticators just provide, in some ways, a more seamless and more secure experience and just a higher level of assurance for the entire gamut of our access. 

JumpCloud Go is an example of a device bound authenticator, which is only bound to a device that is managed by your organization and tied to that user account which is also managed. So when we think about the buzz around Zero Trust Access, it hits all three on the head. It’s verifying your identity, verifying your device, and also verifying the conditions of being a managed identity on that device. So all those aspects are baked in. And we’re super excited to bring this outside of Chrome to all Chromium based browsers as well as Firefox. 

And super excited to say that we’ve also released it for GNOME based Linux distributions which is essentially almost all of them - Ubuntu, Fedora, Pop!_OS, Debian, CentOS, Rocky Linux, and Red Hat. What this underscores is when your organization has users adopting JumpCloud Go, you can now take that step to shorten the session durations of all the Service Providers that JumpCloud is configured for SSO with.

With JumpCloud Go, the way that this device bound credential requests sessions is in such a way that users, once they have a JumpCloud Go session, are going to be continuously getting new sessions to the Service Providers without any sort of user interaction that requires them to re-enter their password or re-authenticate. 

And why that matters is in the event that a user is tricked into doing something they shouldn't do, putting their cookie out on the internet, because they made a mistake, that cookie is useless to a bad actor. In reality, that's really what we're trying to do with the JumpCloud platform, put together a suite of features around online security.

That just protects you the way your car now has a suite of security features that protects you and they all add up to make you safe when driving. So to that end, JumpCloud Go provides not just phishing resistant device bound authentication, but also protects us, because those sessions that we generate with the Go token, that device bound credential they're useless to bad actors in the event that someone shares that cookie out on the open internet and a bad actor tries to use it. So we're really, really, really excited about bringing JumpCloud Go to everyone in an organization, especially those Linux users. 

And the bottom line is that what’s next forJumpCloud Go is continuing to weave it into the platform so that we can lead with our most secure authentication method, and you can have confidence knowing that users, when they select and sign into their resources are using JumpCloud Go. So we're really excited, and we've been having a lot of conversations with customers about what we can do to improve the experience, the adoption, and ultimately try and make JumpCloud as secure as possible by default for all our users. 

Q&A

Q: What about Safari? 

A: So Safari is going to be a lot of fun. One of the realities that we face with JumpCloud Go is kind of the interface with how it communicates with the operating system. And what we're doing now is that it's extension based. So with Chrome and Chromium, we have the Chrome extension. You also use the Chromium extension for Edge right now. We have a standalone extension for Firefox, and that's the new way we're doing that. As we get prepared for something we're really excited about, which is bringing JumpCloud Go to mobile and supporting conditional access on managed mobile devices via that framework, we're developing a Single Sign-On Extension. So an SSOE.

And what's awesome about an SSOE is that framework that we're bringing to mobile is what will then bring the Safari. And SSOEs are not browser extensions. They're Single Sign On Extensions that are deployed. We can deploy it kind of alongside our agent and our tray app. So the experience for JumpCloud Go on Safari is actually going to be seamless when we get there.

It's currently in planning and sits behind the initiative to bring JumpCloud Go to Mobile. The SSOE though is pretty cool. It's what ties in with MacOS’ platform single sign on, but we'll be using it to our own advantage with JumpCloud Go. Essentially there'll be no other thing that you have to do than open up Safari as a managed user on a managed device, and you'll have direct access to a resource.No extension required.  

Which brings me to my next point. We say, “Hey Scott, how are you going to do that?”. Well, right now, JumpCloud Go with the browser extension requires registration. There's a registration step where when you don't have a device bound credential, you do a full authentication to the user portal to receive that device bound credential.

And a lot of what I've taken from feedback and kind of the interviews that we had with customers is that first touch, that first experience with JumpCloud Go feels a little confusing. And it feels confusing because there's no difference than what the user experience is today when they go to the user portal. 

So we're looking at and investigating how we can bring JumpCloud Go registration to the device login to provide a true seamless experience of- you log in with your device with your password that then generates the device bound credential (similar to the experience that you may have seen inside the Microsoft ecosystem with a primary refresh token), logging into your device gets you that device bound credential that then just seamlessly works when you open the browser. There's no additional authentication step, there's no user verification. Your verification happens when you log into your device, and that seamless, single authentication then covers you for the rest of the day. 

So to that end, we're looking at that device registration piece. It's always been on the roadmap, and we're really excited to continue that investigation to see how we can bring that to Mac and Windows. The reality is on Mac there's just looking to be a little bit more of a challenge than what we can do on windows given how that screen unlock and the login screen and the connection to actually getting and storing that, due to internet connectivity. So we're investigating there, but I feel strongly that we hope to have a solution to really complete and have a seamless flow from device unlock straight into the browser.

Q: Is there any reporting on whether someone is using JumpCloud Go to log in? Windows Chrome looks different from Mac Chrome when JumpCloud Go is enabled. 

A: Yes, inside of the events, whether it’s a user login event or it’s an SSO auth event, we have the auth context and there’s two pieces in that auth context. In that metadata, there’s a “JumpCloud Go Success” = TRUE. And that will show us that JumpCloud Go is being used as also a JumpCloud Go User Verification check, which is essentially saying “Did they use their local platform authenticator in this request?” 

So those two attributes are included inside of just those events, which arguably doesn’t make it the best to report on because it’s not like there’s a FALSE inside other events. We’re looking right now at that specific use case and what we really want to do is bring to our admins visibility the relative authentication strength of those user requests coming into their portal. So in some ways I think what’s most important is to bring to your attention any requests that are coming in without MFA. 

Users who aren’t logging in with MFA, to me, is probably one of the highest priorities from a  security perspective that I would be looking at fixing. Enforcing MFA and making sure they’re using MFA. But then we want to also bring in the relative strength of MFA they’re using. Given we now have a phishing resistant MFA authentication method which is device bound. WebAuthn is also phishing resistant but the device bound piece is pretty cool.

We want to bring to you and bring you visibility into how users are accessing resources so you can gauge for yourself the adoption of JumpCloud Go. And that should tie in nicely as we work to give you the option to, in a future release, configure which apps have authentication constraints that require certain MFA methods. Which is just a fancy way to give you the ability to enforce JumpCloud Go. 

So inside those Directory Insights events, exporting, filtering them, those would be the best ways to manage that now. Unfortunately with what we currently have in the DI Events you can’t get down to that level of metadata because it’s nested inside of the auth context. But the data is there. 

Q: Do you have plans to add a user’s JumpCloud Go status to the security status in the Admin Console like how it shows Password Active, TOPT, MFA Active, JumpCloud Protect Active, etc. in the left sidebar?

A: What we’d love to do is we’d love to expose and give you insight into which devices have device bound credentials, and which device bound credentials are tied to which users. So you can see the status of those sessions that are on devices. Because in some way, JumpCloud Go represents an MFA method that’s tied to a device so we want to make that visible and highlight that intersection of device identity and then access provided by Go. 

So bringing visibility to those DURTs (Device User Refresh Token) and how it’s being used as an MFA method, we’re looking at ways to expose that and illuminate that intersection of device identity and access using the most secure method that we have. 

Q: How is JumpCloud Go useful with Linux because there’s no biometric option tied to it?

A: On every device that we support, a knowledge factor is what can be used for local platform authentication. So biometrics on Mac and Windows are a convenience factor that afford users a faster login. Apple Watch authentication is another convenience factor that can afford users faster login. 

On Linux with JumpCloud Go, right now we don’t support using any platform authenticators outside of passwords. Because we support so many versions of Linux via GNOBE, our fastest path to market was just supporting local authentication via the device authenticator and password prop. 

To configure biometrics inside of Mac and Windows, you configure them with the password. If you fail too many times with the biometric you’ll be prompted for a knowledge factor. So there's no security improvement or way to enforce biometrics use for local platform authentication. We feel that when you come back to your computer after sleeping and it says “Enter your password to unlock touch ID” a knowledge factor always sits in front of a biometric factor in the operating systems that we support. In the future it’s on the vendors to provide biometrics as a first class primary authentication factor. 

You actually can do this on Windows. You can have a truly zero touch flow using Windows Hello. You can use it as a primary authentication factor. But on Mac, FileVault decrypt requires a password no matter what. There’s no way to get around the reality that you’re going to enter a password on this device. 

So the question of where do biometrics play into JumpCloud Go, it’s a convenience factor. When users have them configured, the true security benefits of JumpCloud Go come down to the fact that the credential is device bound, non perishable, non portable. And when that credential is used there’s nothing in transit or workflow presented to an end user where that authentication request could be phished. Really the meat behind the security benefits of JumpCloud Go are linchpinned on the fact that those credentials are stored on the device - stored in the TPM or Secure Enclave and therefore are inaccessible by any attempts by a bad actor, even with physical access to the device. 

Q: If JumpCloud Go is an available option, even if they don’t have Windows Hello or Mac TouchID turned on, are they really using JumpCloud Go? 

A: They’re absolutely using JumpCloud Go. The biometric is just a convenience. It’s the local platform authenticator so we defer to the platform. If your device is in clamshell mode you’re going to be prompted for a password no matter what, unless you have Apple Watch set up. The benefits of authentication happen behind the scenes is that we’re using a local credential. There’s nothing in transit that’s phisable, as well as the sessions are non portable. 

Q: Can I set up JumpCloud Go with my Apple Watch if my watch is set up with my personal Apple ID? 

A: Yeah, so it’s actually tying that to your device. So if you say “Unlock with Apple Watch” that becomes an option. So that’s how I authenticate Go with my Mac device in clamshell mode. Because double tapping this is much faster than typing in my password. 

[rjordan]

More go, means more smiles 🙂