Managing passwords with Identity Federation

[urvashi]

This is an edited transcript of the 03.29.24 IT Hour

Overview

• Trevor Wiemann, Product Manager, talks about Identity Federation. He gives an overview of the concept as well as outlines two upcoming features. 
• He also does a demo of the set up and the new login flow that you can watch here. 
• He wraps up by answering questions from the audience. 

Transcript

What is Federated Identity

Trevor: I’m here today to talk about JumpCloud Federated Identity. So first up, what is it? When you hear Federated Identity at JumpCloud, think of it as Bring-Your-Own-Identity Provider (IdP). What does this let you do? It lets you log in with Google or EntraID or Okta, to be able to get into JumpCloud resources. What resources can you log into? Anything that supports OAuth and OIDC:

1. The user portal
2. Single Sign On apps (SAML/OIDC) 
3. Local Password Reset
4. Mac Automated Device Enrollment 
5. Windows Self-Service Account Provisioning (SSAP) 

So think of this like getting into JumpCloud with a Google login. What if you only want some of your users to be able to login with an IdP like Google? You can do that. You can scope the IdP to a specific user group in JumpCloud. You can attach those user groups to the identity provider. So you can have certain users logging in with Google, you can have the rest of your users logging in with JumpCloud, etc. 

What can you not use it for yet? Anything that doesn’t support OAuth. So for instance, LDAP, your RADIUS logins, and your device login, but we have a handy workaround for that that we’ll get into in a little bit. 

New Features

Externally Managed Passwords

What does this mean? It means “prevent password changes in JumpCloud”. So you can set a user to have an Externally Managed Password, for example, Google, because we know that they login with Google, if they try to change their password in JumpCloud, they’re going to get an error message. This makes us able to have users with locked down passwords. They can’t change their passwords in JumpCloud, they can’t change it through the tray app on their device. 

Disable Device Password Sync

This is what was alluded to a little bit earlier with how to handle device logins. If you have a federated user that logs in with Google, we still have to be able to get a password on the device. Those are the rules of the road, whether it’s Windows or Mac, you have to have a password on the device. For both Mac and Linux you’ll now be able to disable the password sync. Meaning you have a device with a local password. So if you think of your phone, you’ve got a PIN  on it, so it’s a similar concept here now. That PIN, that local password on your device will never leave that device. It’s a local passcode only. JumpCloud never sees it. JumpCloud doesn’t sync your JumpCloud password. But all of your web based logins can be done with an IdP like Google. What does that look like?

In the Admin Portal, you open up this user that’s bound to a device, you’ll notice soon that you’ll have a Password Sync column. Leaving that password sync column to “Yes” which is the default value, is the typical JumpCloud experience we all know and love, that should work for most use cases. 

If you have a use case where you need to have a federated user, but you still want them to be able to have a passcode on the device, you can actually break that syn between JumpCloud and the device and make that password local. So when you see Password Sync set to “No”, that means it’s a local password on the device. On Windows we can plug into Windows Hello, on Mac, it’s still just a password, but it’s a local password that never leaves the device. 

What happens if you forget the password? 

It’s local, it’s not synced with JumpCloud, that sounds scary. If you ever forget it, you can do a “Login with your Identity Provider” to be able to reset that password/passcode. So if a user forgets their passcode, they can do a self service password reset to be able to get into their device. 

Why should you care about any of this? 

It’s all about flexibility. If you love the setup you have with JumpCloud today, awesome, we love that. In the future, if anything ever changes, and you have certain users that you need to login with Google, or you need certain users to have a local passcode on their device, there’s lots of uses cases here, this opens things up for you to give you even more flexibility in how you use JumpCloud. 

So when you think about JumpCloud’s Open Directory, we’re really leaning into that. If you want to bring an IdP into JumpCloud, we’ll let you do that. If you want to keep JumpCloud as your main IdP, we’d love that. It’s all about bringing you flexibility. 

How to set up Federated Identity

You can read step by step instructions on how to do this in our Help Center Article: https://jumpcloud.com/support/get-started-federated-authentication

What does it look like to the end user?

The user goes to the JumpCloud User Portal, they enter their email address, they then get redirected to Google where they can enter their Google account password. When they hit Next, they’ll be redirected back to the JumpCloud user portal where they can click through to any of their SSO apps. 

Let’s see what it looks like on devices. If you have a new Windows device that you’ve installed the agent on with a local admin account, you can hand that off to the user. The user clicks “Sign in with JumpCloud”, which will redirect to the IdP, for example Google, the user logs in with their Google account and they come back to setting up and are asked to set a PIN. Once they do that they’re in and working in their new Windows account. You can provision an account onto that device for the first time on Windows or Mac devices. The only difference is that Mac doesn’t have a PIN code that needs to be set, but they can set up TouchID instead. 

Q&A

Q: In theory, could you daisy chain SSO logins?

A: Yes you can. You could start at JumpCloud, login with Google, get redirected to the JumpCloud user portal and then use SSO and end up in AWS.

Q: Does the device login flow bind the user to the device?

A: Yes it will. The only prerequisite is that you have the feature enabled. You can do that under Devices and then Settings. And you have the user in JumpCloud. 

Q: If there are users already bound to the device, how do we transition them?

A: If you want the user to login with Google and they’re already bound to the device, they can continue to get their password synced from JumpCloud as usual. If you want them to have a local password on the device, you can turn “Password Sync” to no. They’ll keep whatever the last password was that they had, but will no longer sync a password from JumpCloud and password resets will happen at the IdP.