10.20.2023 - IT Hour Transcript | Federation and Dynamic Groups Demo

[urvashi]

Key Takeaways

• JumpCloud is expanding its capabilities to include inbound Single Sign-On (SSO), allowing users to sign-in with external Identity Providers (IdP) like Okta, Google, or Azure, enhancing the traditional outbound SSO to SaaS apps.

• The new feature set is currently in closed beta with limited functionality, with plans to add more IdPs and streamline the setup process for Federated Authentication in the near future.

• Setting up a new IdP in JumpCloud will be straightforward, requiring just a name, URL, client ID, and client secret to configure Federated Authentication using the OAuth code flow.
• JumpCloud supports local device passwords and pins, including Windows Hello, allowing for secure device access and self-service password and pin resets, with provisions for Mac users as well.
• Dynamic Groups is now in General Availability. For more information on managing user access, see how to configure dynamic user groups and how to configure dynamic device groups.

Introduction

Trevor Wiemann, JumpCloud Product Manager, discusses two key topics: Federation and Dynamic Groups. Trevor explains the concept of Federated Authentication, where JumpCloud is adding the capability for users to sign-in with external IdPs like Okta, Google, or Azure, and then use JumpCloud as a Service Provider to access downstream resources. 

He highlights that this feature is still in development but will provide flexibility for organizations to choose their preferred IdP while utilizing JumpCloud's functionality. Trevor also briefly touches on Dynamic User and Device Groups, a feature that allows automated grouping based on attributes and conditions.

You can find the full video recording here:The IT Hour | Product Panel 10.20.2023

Speakers

Trevor Wiemann, Product Manager, JumpCloud

Urvashi H.V., Technical Community Champion, JumpCloud

Transcript

Introducing Federation and Dynamic Groups

Trevor Wiemann:

Hey everybody, happy to be back with you all again. I'm going to talk about both Federation and then touch on Dynamic Groups as well. And just as a heads up, I'm going to be talking pretty briefly about Federation today as we're still finishing out the functionality here, but I will totally be back in the future to talk about this much more in-depth. But I'm going to go ahead and be happy to introduce it today and take questions as well. 

Federation

So Federated Authentication with an external IdP. What does this actually mean? Basically, at JumpCloud, historically, we have supported outbound SSO. So basically, we provide SSO with SAML and OIDC to downstream SaaS apps. This is the JumpCloud SSO you all know and love. What we're doing is basically adding SSO inbound into JumpCloud, so you can bring an IdP like Okta or Google or Azure and use those IdPs to be able to facilitate SSO from that upstream IdP into JumpCloud as a Service Provider.

Federation Setup

And then JumpCloud can then basically turn it back into an IdP and go do SSO into any downstream resources or get you into any other resources you might have. So basically historically, downstream is SSO, Federation is upstream/SSO into JumpCloud. So roughly what this will look like is in JumpCloud, you can set up an IdP. We're going to start with Okta, but we'll be adding Google and Azure pretty soon. You set up an IdP in JumpCloud, and as you can kind of see up here, what this is basically going to look like to a user is they'll continue to sign-in with JumpCloud, but if we see that do you have an IdP configured, we're actually going to redirect you over to that IdP using OIDC to authenticate the user and then they're going to come back over and be able to, whether it's Self-Service Account Provisioning (SSAP) into their device or SSO out to downstream applications, getting to the User Portal, etc., any JumpCloud resource where you're using a browser-based session, you'll be able to actually go sign-in with these upstream IdPs, and then JumpCloud is brokering that authentication. 

Federation Benefits

So again, you can keep your existing IdP, let users sign-in with that IdP, but get into your device with Self-Service Account Provisioning, you get in the User Portal, SSO into downstream applications, etc. So again, we're still putting the finishing touches on this. We're going to do a really limited closed Beta right now with some incomplete functionality for now still being this finished up, but later this year and looking into early next year, we're looking to be able to get this out, and into General Availability. It's going to be a super simple setup. You basically come in, you give your IdP a name, you provide your URL client ID and client secret (this is using the off-code flow), and then you have an IdP that is configured. We're going to actually go to this IdP URL, and using the well-known configuration, we'll grab all the OIDC endpoints that we need to make the authentication happen, and then you'll be set up to use Federated Authentication.

Audience Questions

Brandon, yeah, so you're using Okta to sign into JumpCloud. So, for instance, if you're looking at Self-Service Account Provisioning, which I think Scott may have talked about in the past, when I'm a user and I'm getting in a new laptop and I open it up and I click Sign-in with JumpCloud, I open up instead of signing directly into JumpCloud with my JumpCloud credentials, I'm actually getting redirected over to Okta, signing in with my Okta credentials, which then allows me to get into JumpCloud and then get an account provisioned on my device. Then looking ahead, if you think of if I'm a user and I'm trying to do SSO into Salesforce, instead of signing-in with JumpCloud, I'm actually going to get redirected over to Google or Azure, signing with my Google or Azure credentials, come back to JumpCloud and then get into my application.

User Matching and Prerequisites

“What happens if there's not a matching identity on the IdP end?” Great question. So one prerequisite is you'll have to have the user on both the JumpCloud side and the IdP side. So, for instance, if you're using Azure ID or Entra ID, you have to have the user already exist over there in that IdP, and you also have to have the user exist on the JumpCloud side, both Okta and Azure intra support, SCIM real time provision. So you can set that up to be able to create users in real time into JumpCloud. And then we do have the user import with Google, but yeah, the prerequisite is they have to be on both ends to start with, we have to match up on a unique identifier. And this is really used to your question, Nick, to be able to keep your existing IdP but also use all of the great functionality in JumpCloud or if you have certain places where you want users to sign-in with an upstream IdP, you can do that.

Local Device Passwords

“How does this work in terms of local device passwords?” Great question. You'll have the ability to set up a local password on the device. We can use Windows Hello. So we can have a local PIN on the device that never uses the device, but then use Federation to actually be able to provision that account for the first time and do self-service password and PIN resets on Mac. Of course, there's no Windows Hello or PIN available, but you will be able to have a local password on Mac. If you don't want the local password and you do want a JumpCloud password to get synced down to the device, but users still to be able to sign-in with an IdP will be able to support that as well. So again, that's going to be more similar to what you've always known, where you have a JumpCloud password getting synced down to the device, but users can sign-in with an IdP where possible. So obviously, you're going to have to have a credential on the device that can be either JumpCloud managed with password sync or local without password sync, but then users can still sign-in to the User Portal, do self-service password resets, et cetera with an external IdP. 

Use Case for External IdP

Urvashi H.V.:

There's one more Trevor, sorry. “What's the use case for external IdP if JC already acts as the IdP?”

Trevor Wiemann:

Yeah, so in that case, Federation might not be for you if you're totally happy and you don't, and your use case wouldn't benefit from having an external IdP, obviously totally cool to stay with JumpCloud as the IdP. We love it. This is just giving you more flexibility If you're an organization that wants to let users continue to sign-in with Okta or Google or Azure but still use JumpCloud as well for whether it's SSO, device management, etc. So if you're happy with JumpCloud as the IdP, great, that's perfect, we love it. And if you would rather have users sign-in with one of these providers, we're going to be very soon supporting that as well.

Federated Authentication Between Accounts

Urvashi H.V.:

And we have one more. This one is fun, I think. Would this cover Federated Authentication between accounts? Account A can sign into account B? Account B also has local users that only sign into account B?

Trevor Wiemann:

“Would this cover Federated Authentication between accounts?” No. If you're asking about being able to sign-in with multiple user accounts within the same JumpCloud tenants, no, that wouldn't be covered under at least this kind of our first pass at Federation. Definitely be interested to hear if you have a use case that would benefit from that. So if that's something that you know of a use case, please feel free to hit me up. I can put my email in the chat when I'm done for any additional questions or feedback, but I'm interested to hear your case there. One thing we'd like to do in the longer term is be able to support Federation between JumpCloud tenants. You're not seeing that on the screen yet, that's not kind of in our short-term plans, but it is in the longer-term plans to be able to allow a user in one JumpCloud org to sign into another JumpCloud org. So I'm interested to hear your case of that happening within this same JumpCloud tenant.

So that's Federation. Again, feel free to reach out on the JumpCloud lounge or email me directly with any questions. But again, this is, we're wrapping, we're putting the finishing touches on this right now, so you'll probably hear from me in a future IT Hour to do a deeper dive once we have this all finished up and ready to go out. 

Dynamic Groups

But with that being said, I'm going to touch on Dynamic Groups really quickly. So you all heard about this from Derek a while back, but just touching on Dynamic Groups quickly, for those of you that might have missed it, we now support, in General Availability, the ability to have both Dynamic User Groups and Dynamic Device Groups. So basically, in short, what this means is our groups, user groups, and device groups, you can now add rules or conditions to these groups with many different attributes to be able to let users move in and out of these groups automatically without you needing to manually touch the groups at all.

Dynamic User Groups

So on the user group side, we have several different attributes here. We also have exemptions. So if you have users that may meet one of these attribute conditions, but you don't actually want them in the group, or they don't meet the condition, but you always want them in the group, you can also add them to the exemption list as well. And basically, what that means is our rules and general just totally ignore those users, and they'll continue to be in the group or out of the group based on your preference. That's Dynamic User Groups, several different attributes there. If you're a new JumpCloud tenant, you're going to see a default Dynamic Group get created for all users that's going to be set up like this. So every user in your org will always be in that group unless you add them to the exemption list. And then, of course, you can create all the custom groups you want with custom with your own attribute conditions.

Dynamic Device Groups

Over on the Dynamic Group side, device group side. Very similar to here, too, we have several different attributes, so you can set up Dynamic Device Groups and let devices move in and out of these groups accordingly. Again, we also have exemptions over here as well, so you can include and exclude from these groups as needed, but that is Dynamic User and Device Groups. I'm happy to take questions here. 

Plans to Add a ‘Contains’ Operator

“Are there plans to add a contains operator?” There are, yes, that is in the works. We have a couple of different additional operators that should be coming out, so we'll keep you updated on the timeline there and what that looks like when that'll be in General Availability, but that is absolutely, that is absolutely planned.

“ETA?” Luke, you're asking the hard questions. I don't have an ETA now, but I will again, we'll as soon as we have a concrete ETA on when this will be available, I will update the group ASAP, whether it's getting that answer back out on the IT Hour or getting that updated in the JumpCloud Slack Lounge, etc. Yeah, exactly, Rob, the ETA is ETA. It's expected to be announced but not quite yet. But yes, that is absolutely, you're going to see that you're going to that coming sooner rather than later. 

Dynamic Groups Migration

“What's the migration scheme for those of us that have existing static group definitions? How do we upgrade?” That is a great question. The migration for an existing static group, and I'm guessing Jonathan, that you're asking for groups that have existing group suggestions, but they're not fully dynamic, and if that is the case, you can switch over to dynamic, and then you leave this box right here, “Require administrative review of updates” unchecked, and that is basically a now a fully Dynamic Group. So your rules will still be there, but you won't have an admin have to go in and every single time check and accept or deny those suggestions. So Jonathan, hopefully, that answers your question. If not, just let me know in the chat. 

Dynamic Groups Rules Engine

“Are there plans to allow us to use SpEL or OGNL?” Not yet. Right now, our rules engine is just what you see here with using, assuming I'm understanding your question there, right, to use the attributes and operators that we offer here. Again, not to say that couldn't change in the future, so if you have a use case, please reach out in more detail so we can be tracking and understanding that. 

“Can exclusions and Dynamic Groups be rules-based as well?” Never add a user with admin in the description. That is an interesting one. That's a great question. Right now, we don't have plans to add that it's on a specific user or a specific device basis, but basically, having a rule that doesn't add them to the group, I'm assuming, is what you're after there. Yeah, that's a good one. So I can take that back to Derek and the team, but yeah, I can say right now we don't have short-term plans to add that it's the exemptions are specific user or device based, but I can definitely take that as a Feature Request for sure, and I see a couple different reactions there, so I'm assuming that that would help several of you out as well. 

Urvashi H.V.:

One more point of feedback…

Trevor Wiemann:

“Please add ability to reference other groups.” I don't know if this is what you're asking or not, but I know one thing we're looking at doing is being able to link together user and device groups dynamically. So we have plans to do that. Oh, okay. You're saying “if they're in this group, also add them to this group”, so if they're in group A, add to group B. Yeah, that's a super interesting one and if that's what you're after, I can say that you could accomplish that now on a workaround basis by obviously just having the same attributes conditions set up, but I'm assuming you're looking for something a bit more robust there, so that's a good one. Yeah, I can totally take that back. We don't have short-term plans to do that, but can totally take that back.

Let me just pause and say I'm super pumped to hear the questions and requests here because Dynamic Groups just released here over the last couple of months, and I know that we're already getting a ton of feedback wanting more features and more robustness here, which makes me super pumped to hear that, that you all are interested in getting more functionality there. So I'm hoping that the Dynamic Groups have been super beneficial for you all. 

“There's does-not-contain operator, would that work?” Yeah, maybe. So that might help out with the exemptions, not as they haven't been flexible enough. Okay. Yeah, Luke, happy to, if you want to give me more details and chat or reach out separately. I'm happy to hear again if you have any specific requests for what you would need to be added to make Dynamic Groups flexible enough for your use case.

Nested Group Capabilities

“Is there a way to have nested groups, or is that coming?” No plans to add nested groups right now. For now, being able to accomplish what you would want with nested groups would have to be facilitated through Dynamic Group rules, but again, as always, I know we get requests for nested groups, something we're constantly evaluating. Right now, we're looking at solving that problem through Dynamic Groups as opposed to nested groups. But again, as always, I'm happy to hear the use case and try to understand if there's a need there. 

As someone who came from a prior organization with an on-prem AD deployment that had hundreds of thousands of users, and our nested group structure there was just wild. So hearing nested groups gets me. I can be a little bit shaky when I hear that, but I know there's totally a valid case there. So yeah, for sure, let us know if there's demand there for nested groups.

“If there are no nested groups, then let us copy an existing group.” Absolutely. Yeah, for sure. That's a great one. And that would, I know, help you all to be able to configure some pretty complex rule conditions and be able to drop those onto new groups. 

Wrap Up

Okay. Seems like it's slowing down a bit, and I want to give plenty of time for the other folks here, so I'm going to stop sharing now. I'll continue to look at the chat and make sure I didn't miss anything. So if there's anything else, please reach out there or hit me up in the JumpCloud Slack Lounge, etc. Thanks y'all.