12.08.23 - IT Hour Transcript | Amazon Verified Access Partnership

[urvashi]

Key Takeaways

• John Brunot, a Partner Solutions Architect at Amazon Web Services (AWS), is instrumental in developing technical strategies with partners like JumpCloud and influencing AWS-integrated products.
• AWS Verified Access offers secure, VPN-free access to corporate applications using a Zero Trust model that relies on continuous validation and multiple factors like identity and device posture.
• AWS Verified Access simplifies connectivity and security, allowing application access from anywhere and integrating easily with existing security systems for streamlined policy management.
• JumpCloud plays a key role in the AWS Verified Access ecosystem, particularly in identity and device management, and simplifies integration through JumpCloud Go

• For a comprehensive understanding and more insights, be sure to check out the full video discussion.

Introduction

In this week’s IT Hour, we dive into a detailed discussion led by Becky Scott, featuring key speakers John Brunot from Amazon Web Services (AWS) and Joel Rennich from JumpCloud. 

John Brunot, a Partner Solution Architect at AWS, shares his expertise on AWS Verified Access, a solution offering secure, VPN-free access to corporate applications. He highlights the importance of Zero Trust and its implementation in enhancing security. Joel Rennich, representing JumpCloud, discusses the integral role of JumpCloud Go in the AWS Verified Access ecosystem. 

The conversation navigates through the intricacies of AWS Verified Access, its impact on traditional VPN usage, and the future direction of secure application access. This episode provides a deep dive into the technological advances and collaborative efforts of AWS and JumpCloud in shaping the future of corporate application security and accessibility.

Full Video

The IT Hour | Amazon Verified Access Partnership 12.08.23

Speakers

• John Brunot, Partner Solutions Architect, Amazon Web Services (AWS)
• Joel Rennich, Vice President of Product Strategy, JumpCloud
• Tom Bridge, Director of Product Management, JumpCloud
• Becky Scott, Head of Technical Community, JumpCloud
• Urvashi H.V., Technical Community Champion, JumpCloud

Transcript

Introduction

Becky Scott:

We are going to let John, Joel, and Tom talk about the Amazon Verified Access Partnership. Now John's going to start out and talk about his part of the deal. He's got a few slides to share, and then he's going to give us his part, and then Joel and Tom are going to talk about what JumpCloud is doing with the verified access partnership. So John, do you want to talk a little bit about what you do at Amazon and then start showing us your piece of the puzzle?

John Brunot:

Yes, let me start first by introducing myself. Becky, thank you for allowing me to be here with you and your team today. And my role at AWS, basically, I am a Partner Solutions Architect. I am responsible for creating and driving the technical strategy with our Independent Software Vendor (ISV) partners, such as JumpCloud, and I also play a lead role on go to market products built on, or integrated with, AWS. 

Alright, so I'm going to talk about AWS Verified Access and how it can help you provide secure access to corporate applications without VPN. And this will be my agenda today. So we'll dive in and talk a little bit about connectivity challenges that customers are experiencing and how AWS Verified Access helped resolve these. And I'm going to talk a little bit about AWS Verified Access, what it is, and then go into how it works.

The Need for AWS Verified Access

And then after that, I'll transition to Tom. So I hope you'll be excited about AWS Access just as I am. So let's get started. So at AWS, we really prioritize offering diverse connectivity options to meet our customers' needs. Whether it's connecting to applications, resources, or workload, we make it possible. 

So many of our customers, they utilize on-premise VPNs, and we support these customers with side-to-side VPNs with Direct Connect and Cloud One. And for those customers who prefer a direct link to our applications, we introduced AWS Client VPN. 

Then we started to hear from customers that they needed a simpler yet secure connectivity to access their resources. Customers were asking to connect to their AWS resources from any location using a simple browser and have control over who can access their applications, at what particular time, and from what particular devices. Essentially these customers were asking for Zero Trust access.

Zero Trust Explained

So at AWS, we believe that Zero Trust is a conceptual model, and you should not rely on networks or network perimeters. You should also use non-network based controls to provide access for your users to your applications or any resources for that matter. 

So let's unpack how this looks. In a traditional network model, it says that once you're on the network, you can access your applications. But a Zero Trust principle says that, let's use other signals, for example, identity. Now why stop at identity? We can use even more signals. We can use device posture, and identity together to allow the users to access the network. Why even stop at identity and device? We can even use more real-time contextual signals to let customers access applications. 

Then the second thing is that once you are on the corporate network, a traditional method says that you can always access any applications. Zero Trust, on the other end, says that you have to perform continuous validation. You have to check the identity, check device posture with each request. 

So when I try to access my application it checks, then the next time I try to access another application or even the same application, the validation happens again. So it is a continuous validation process with Zero Trust.

Traditional Access Management vs. Zero Trust 

Now let us explore from a traditional versus Zero Trust perspective. Traditionally, if you are in the headquarters of your company, you access applications via the corporate network. Remote locations like home or another site require VPN logins for access. Opening a new branch office involves connecting it to the corporate network. A process that can take weeks or months, Zero Trust shifts that paradigm applications become the focal point of your IT infrastructure. 

Therefore, access is defined by policies surrounding the applications, not the network. Whether you are at the headquarters working remotely or at a new branch office, you simply connect to your applications. Policies validate, and grant access, eliminating the need for VPNs and extensive network setups.

Now let's see from a security perspective what it looks like. If someone gets a hold of one of your servers in a traditional method. Since the server is in your corporate network, they can use this server and potentially access your applications. In a Zero Trust environment, since we are saying that it will do continuous validation access, your application will be denied because Zero Trust, when you first access your application, it verifies. Then each subsequent access request is also verified. 

If someone were to gain access to one of your servers, then obviously, they would try to gain a foothold into your application. What will happen in this case? Well, either the identity or the device posture will not match. So access to that application will be denied in a Zero Trust environment.

The current solution that we see customers are using and they have been using that for a number of years now to incorporate Zero Trust capabilities into their networks. So the current setup typically involves protecting the perimeter with VPNs and firewalls, and remote access is governed by VPN policies. Application developers would coordinate with the security team to integrate identity-based access control, setting specific policies for who can access what. 

Meanwhile, the IT team would enforce device compliance policies allowing only approved devices on the network. This results in multiple layers of policies managed by different teams making policy changes or new application integrations, time-consuming, often taking days or even weeks. It's in response to this that AWS developed AWS Verified Access to streamline this process.

Introducing AWS Verified Access

So with AWS Verified Access in looking back from the needs of our customers, we knew we could do better. We knew we needed something with less assembly, something that can provide continuous verification and provide you more context so that you have an enhanced security posture. 

So introducing AWS Verified Access, basically AWS Verified Access simplifies connectivity for users enabling application access from anywhere. It enhances security teams faster by adhering to AWS Zero Trust principles. It gives you the ability to set fine-grained application-specific controls using real-time signals like identity and device posture. 

From a management standpoint, it is streamlined. Policies for each application can be managed in one place. Adding applications and updating policies is just a few clicks away, reducing time from days or weeks to mere minutes. So for the IT operational folks, you'll be happy to use AWS Verified Access to manage your policies. Now with AWS Verified Access from a connectivity perspective, users no longer need to use VPN. From a security perspective, you can manage your application access policies from one single place.

How AWS Verified Access Works

Now let's look inside how AWS Verified Access works. It does three things. 

The first thing that it does is that it offers precise control over application access. Basically, you can set specific policies for each application. For instance, finance team members can access their applications only with compliant devices under certain specific conditions, while everyone else can access the corporate IT help desk. So you can define those fine-grain policies. 

Secondly, AWS Verified Access, meticulously logs all access requests, whether they are allowed or denied. This feature is invaluable for our customers because they now can use this rich data for troubleshooting for audits, compliance, and investigating security incidents. 

Third, we are focused on creating an open ecosystem, recognizing the challenges of transitioning to Zero Trust, AWS Verified Access integrates with existing security systems like identity and device security providers.

Integrations with AWS Verified Access

Our goal is to simplify this transition to Zero Trust while it will allow you to maintain your current systems while enhancing access control with AWS Verified Access. In the AWS Verified Access ecosystem, our partners, such as JumpCloud, play a pivotal role across three main areas. 

• Trust Providers
• We have identity providers. These partners manage corporate identities, define user roles in departments, and we collaborate with major identity providers, JumpCloud among one of them, to facilitate integration using standard protocols. 
• Then we also have device management partners. In this category, they're focused on securing devices and endpoints, which JumpCloud is one of them, and we use their security signals to integrate them to shape your access policies. 
• Then we have providers that give you contextual signals. We're partnering with firms like this to offer additional contextual signals like location and behavior analytics aligning with Zero Trust principles that more signals equate to enhanced security.
  
  
• SIEM/Observability Providers
• Additionally, we have partners who specialize in analyzing AWS Verified Access logs offering valuable insights for audit compliance and troubleshooting. 
  
  
• Managed Connectivity Providers
• Lastly, we have our managed connectivity providers, who give us the ability to look at foundational components and create and manage comprehensive connectivity solutions that extend beyond AWS to other cloud services and on-premises environments. 

These partners ensure a holistic approach to your connectivity needs. So these are some of the partners that we work with to integrate with AWS Verified Access. 

Now let's dive deep into how you integrate with identity and device trust partners such as JumpCloud. So for identity partners, we have three ways you can integrate. If you are already using an identity provider, you just integrate with the AWS IAM Identity Center. This acts as an identity hub from which AWS Verified Access users can retrieve user information. 

What is the benefit to that? Well, once identities are in the identity center, they can be utilized for various AWS services, including AWS Verified Access, Grafana, or IOT devices. If you don't have an existing identity provider, the Identity Center can be used to manage your user pools. Then your third option will be if you can directly integrate your identity provider with AWS Verified Access using OpenID Connect.

So from a device management perspective, partners like JumpCloud oversee the devices, and endpoint security. Integration with these partners allows the use of their signals for policy definition, including contextual signals like location and behavior analytics providing better security. While many of our partners in this category, they run an agent on devices to monitor and determine compliance. 

To facilitate this, AWS developed a browser extension. This extension used on user devices communicates with our partners’ agents to gather information such as device compliance and operating system details. When accessing an application, this extension sends device claims along with the HTTP requests. Note that this browser extension is only necessary if your policy utilizes device claims. If device claims aren't part of your policy, a standard browser can be used. 

Setting Up AWS Verified Access

So how do you set up AWS Verified Access? Setting up verified AWS Verified Access is straightforward and involves just four steps.

• First, you create a verified access instant in the AWS region where your applications are hosted. Then you connect to one of our partners, such as JumpCloud, who is a provider for identity and device management, allowing Verified Access to receive the necessary data. 
• Second, you add or you associate your applications with AWS Verified Access. These applications may be in different accounts or VPC.
• Third practicing list privilege principle, initially, the default policy is set to deny all. So you'll need to configure your specific access policies. 
• And lastly, after setup, users can connect seamlessly from their laptops without any change to the application name. So they would basically type the application URL like myapplication.com to access it.

Top Use Cases for AWS Verified Access

These are the top use cases that we have for AWS Verified Access. The first one, secure distributed users. So with AWS Verified Access, users can access their corporate applications based on AWS Zero Trust principles using multiple security signals like identity, location, and device security status. AWS access evaluates each request in real-time against security requirements as defined in the policy to ensure secure access to the applications. 

The second use case that we have is to manage corporate application access, and using AWS Verified Access IT administrators can define the policies and onboard new applications within minutes. IT administrators can also use AWS Verified Access to build a set of fine-grain policies using security data like device security status and up-to-date software security software that defines a user's ability to access each application. And the benefit of that, instead of fine tuning multiple policies across your layers of protection, you can simply update the policy in AWS Verified Access centrally to reflect the new requirements to access applications. 

Then the third use case that we have, the most common use case, is to accelerate time to troubleshoot. So AWS access, as mentioned before, evaluates each access request and logs all request data, including security signal input used to authorize or deny requests. So this provides a complete visibility to the network team into corporate application access requests, thereby enabling them to quickly gather data and intelligence to direct faster response.

So this is our current list of AWS verified partners. We're happy to work with you and your partner to expand this open ecosystem. As you can see, JumpCloud is one of our verified AWS Verified Access Partners. 

Well, thank you. I appreciate you giving me the time to speak to you about AWS Verified Access and now we're going to transition to Joe who will talk more about how they're using AWS Verified Access.

JumpCloud’s Partnership with AWS Verified Access (AVA)

Joel Rennich:

Thanks for that, John. Yeah, we're really excited. I think we got into this probably only about a month or two ago, and if you're cool, you call it AVA, right John?

John Brunot:

That's right.

Joel Rennich:

Put that out there, so everybody can be on the same page. So we started working with Amazon about a year ago on the identity side, which was cool, right? And part of it was because anything that works with Identity Center can be piped through to AVA. So then it makes it really nice and easy that if you've got a resource, a service, something running in your VPC, in your Amazon tenant, you may not want to really have to do a lot of work to mess around with, okay, how do we protect this? How do we keep this secure? How do we add this Zero Trust flavoring to it? 

And so AVA then works out really nice, it's just an ingress method into your PC C real nice and easy, and you can use all the plumbing and the normal piping that you already have within Amazon, all those other Amazon toolings that you have just work.

JumpCloud Go and AVA 

So that was really cool. About a month or two ago, we started thinking about, hey, we got this really cool JumpCloud Go stuff, and we're minting a lot of tokens. It's got a hardware-backed key pair. There's a fantastic white paper that just got released that will walk you through all that stuff. So you should definitely look at that if you haven't already. It's another throw to that white paper. 

So there's some really cool stuff in there, and we wanted to incorporate all of that into AVA and add that devices piece because what John you already mentioned is that prior to when JumpCloud came on from the devices side, there's an Amazon AVA Chrome extension that you can use and that can work with some of the other partners that are doing the device trust. We wanted to do it even easier. So if you have JumpCloud Go already enabled for your browser, you don't even need the Amazon Chrome extension. We'll automatically be adding in the JumpCloud Go JWTs that you need to for all of those AVA requests.

I believe we're currently working with a five minute time period. So if your device becomes unmanaged or you remove it from JumpCloud or anything that you would do, changing the user's password, that would invalidate JumpCloud Go for that user within a few minutes, you're going to get blocked from all of your access that you have with AWS Verified Access, which is why we're really excited about this because it's that very high fidelity of knowing when something has changed and when your security posture has made something that you might want to re-authenticate, reevaluate, do those kinds of things. So we've just started kind of scratching at the surface of what we want to do here. 

You're going to see us coming out with more continuous conditional access and other kind of flows very heavily predicated on JumpCloud Go. So if you are somebody that wants to use this, you can go as John showed you through some of the slides, go to your Amazon console, go to, I think it's VPC, and then Verified Access.

Setting Up AVA with JumpCloud

Set up a new one. You'll have two options, one for identity and one for device. JumpCloud will be in both of those. Say identity, you can flow through the Identity Center, or if you want to create just a standard OpenID Connect flow, you can just punch in an OpenID Connect app from the JumpCloud console if you want. I don't know that I've got an opinion one way or the other, although it can get a little philosophical. 

You may not have control of your Identity Center setup because your IT team may be managing that. So if you want to do, and I won't call this Shadow IT, but if you want to do some testing with this and you maybe only have limited abilities within the AWS console, you can actually, again, like I said, just put in a raw OpenID Connect app into that verified access setup so that can the identity part, which is really cool.

Then there's another option which is the devices, and there's a pull-down for JumpCloud. You just do that. All we're going to ask you for is your tenant ID, which you can find in your admin console. Tom's going to tell me exactly where that is, Admin Console -> Security, I think, or Info somewhere there, get your tenant ID, put that in, and then boom, you're done. 

As long as you've got the JumpCloud Go extension on there, we're going to be adding those JWTs with a five minute signature into the services. So it'll just be flying like that. Really cool stuff. All right, so questions before we get into what we're kind of doing with this internally, I don't see any.

Becky Scott:

I haven't seen any yet. They're kind of quiet in the chat.

Q&A: VPN vs AVA-JumpCloud Integration

Joel Rennich:

Little quiet. So internally, and maybe this will give you some ideas of how I can use this, we have a couple of different apps that we use, a lot of cases for our customer service teams that when you might have a ticket, when you might have a question or something like that, the customer service teams use these apps to just get a better understanding of what your JumpCloud tenant looks like and what you're doing. 

Obviously, those are somewhat sensitive. We want those to be very highly protected. Currently, those are all behind some VPN infrastructure, and that's not to say VPNs are bad. VPNs are great…

Tom Bridge:

Yeah. When we think about the kind of technology being used here, VPNs have their own overhead. You may be paying for a service on top of your AWS bill. You may be paying for a license on top of every user that you have associated with it. There are a lot of costs to an organization for adopting a ZScaler or a Palo Alto Cortex or any of these other kinds of tools that are based on this regard. 

And being able to simplify that down to a tool you already pay for, like JumpCloud, to manage your identity and to manage your devices and to be able to empower that tool across your entire fleet, Windows and Mac, is a huge substantial increase in the ability of your organization to be safe and sound. 

Steven asked a really important question, is this a replacement for VPN, or is this to be beside a VPN? And my general thought process is this kind of replaces that VPN functionality for applications that are held within your AWS environment.

Joel Rennich:

And to keep in mind right now, Verified Access is purely just web-based, and there's good and bad things to that, right? Yep. You've got this idea that you don't need a client whatsoever as long as your user has a browser. And this goes back to a lot of our customer service reps. If you've got users working remotely, things like that. If they've got a browser now, you've got a much better security posture that you can enforce on some of these applications. You don't have to worry about a client getting installed, and you don't have to worry about them maybe going other places. Very, that's exactly it streamlined into just that application that's on there. 

So other things that I think are really unique to JumpCloud, and I'm glad we have them. We're the only provider with AVA that does both identity and device trust at the same time. With the other providers that you have out there, you're kind of using some identity provider and then a different device management service.

Since we do both, we're there for you both right in there. And we're the only device provider that does this for both Windows and Mac at the same time. So we think that makes this journey so much easier if you're trying to roll this out across a larger fleet, you've got mixed environments and things like that, and we're very much looking at the impact of this on Linux. 

So if you do have a use case or a need for this on Linux, please let us know. That's going to help us maybe prioritize that, push it out a little bit faster. We do think that it should just work. So if you do want to have AVA on Linux, which otherwise, from a device perspective, there's nothing that you can do with that today with any vendor. So we're looking at that as what we go through there.

Q&A: Managing AVA Policies with Cedar

Managed browsers through Google Workspace? Should just be perfectly fine. It's literally just the JumpCloud Go Chrome extension and then it's just adding a JWT as a cookie under the covers is how it works. 

And then on the AVA side, and this is really cool, and John, I don't think gave this enough attention, Amazon's got this very cool conditional or, I guess, policy language called Cedar and Cedar allows you to really pick apart, have a lot of options, and you can take that JWT that we supply with this information that you have on there from AVA and you can write very elaborate Cedar policies to determine it's 8:00 AM you're coming from this IP address, your username is this, your device is managed by JumpCloud, the time is right. 

All of those things can be put through there. Cedar can be a little bit daunting at first because it is a very, very powerful policy language, but it does have some really cool stuff that you can do. And as we decorate the JumpCloud Go JWT with more attributes, more information in it, we're really excited at what people can do with Cedar to parse those things through.

John Brunot:

Yeah, actually, I'm glad you mentioned Cedar. I just didn't think I didn't want to make it too lengthy and go to policy. See, I didn't know how many people would start leaving, but yes, Cedar was created specifically for, well, AWS Verified Access is one of the services that it was created for. So really cool the way that you can use it and with a bunch of if-else, and it's very fast and allows you to basically create your policies and not have to rewrite them for each application.

Future Plans for JumpCloud Go and AVA

Joel Rennich:

Yeah, we're excited at what the future holds as you see us do more. Again, like I said, with continuous conditional access, we want you as the admin to be able to have a lot more filtration opportunities here as you can go through that. And for the user, I mean this is really, we've done some demos of this internally, and people are like, well, wait a minute, what happened? And we're like, no, everything happened. It was fantastic. You went to A URL and it just worked. That was exactly the way it was supposed to happen. 

And if you're not using JumpCloud Go, you should run, not walk, to start using JumpCloud Go on your systems because it's a fantastic user experience to just keep them re-authenticated with local hardware back keys. And so integrating that into AVA was really nice. You're going to see us do more with JumpCloud Go and maybe other services and other things that you could do going forward. That is someplace we're spending a lot of time with? And this is a great example of it.

Multi-layer Security with JumpCloud Go + AVA

Tom Bridge:

Well, I think it's really exciting to think about all the possibilities that this represents for organizations out there to have really great private applications and to have applications that are so private that you can trust AWS with their functionality and their execution, but really lock down who can have a direct access to those devices in a place where there's just no way around it. 

And having a network layer as well as systems layer as well as authentications layer set of security procedures associated with your individual application, you can rest comfortably knowing that that's not an application that can be accessed from outside of your device fleet. And if you've kept your device fleet in good working order and your authentication solution in good working order, you can trust that that's a really secure application posture for your organization, especially for those people who have customer data in databases and services. 

Urvashi is exactly right. It's a whole fortress of protections that verified access and JumpCloud together help you own and control. So I feel really great about the future that AVA really represents alongside JumpCloud Go.

John Brunot:

I agree. And, I wanted to say also internally, we have used verified access to replace many applications that we used to access via VPN, and it used to be a pain for me each time I log in, and I have to log it to VPN, and then once we started transitioning to Verified Access, some application would be part of it because it was a phased approach and then with some application I would've to log into VPN and then some I didn't have to. Now it's pretty much 99% of all of our applications all connected using AWS Verified Access, which makes it much easier, much safer, and the overhead is less.

Tom Bridge:

Absolutely.

Urvashi H.V.:

And here I'm still entering SMS one-time passwords, logging into my bank. Everybody needs to get on this.

Tom Bridge:

All of the different ways in which we have to authenticate securely to our environments, it's varying degrees of security and that gives us a really interesting opportunity to kind of talk about the authenticator levels that are available as part of multi factor authentication and JumpCloud's solution in this case is an AAL3 high level of certainty, multi factor authentication that takes place in there because it is really, really a protected set of credentials that can't be separated from your operating system environment. 

And so JumpCloud Go really is the most secure way to partner with AVA and to really protect your environment. Lots of great stuff.

Q&A: Addressing Prerequisites

Urvashi H.V.:

I have a question that often comes up in our communities, which have there been any sort of cautionary tales that people need to plan for, any prerequisites that maybe often gets skipped, because that's something that gets talked about a lot in our communities is how do we make sure that we've got everything set up in the right order? Following the documentation is one thing, but then there's always a surprise.

Joel Rennich:

We've done a couple of setups with AVA specifically with JumpCloud Go, and it is kind of on rails. I mean, you have to opt into a lot of these things. So setting up AVA isn't going to give you access to the whole internet. It's very limited to just things in your virtual private cloud, and you have to do all the routing rules and everything within AWS. 

So obviously get those rules correct. If you pointed to the wrong service, that's going to be bad, but there's nothing that will accidentally happen in that flow, right? You've got to go through, set up the right subnets and everything else that it's got access to and it's flowing in. Other than that, I mean the big gotchas are making sure JumpCloud Go is working. So if you don't have JumpCloud Go working today, make sure you can sign in.

We've got some documentation on that and that you're seeing that little cloud and shield that's verifying your device and your user when you connect into some of the JumpCloud resources. So if that's in there, the rest of this should be pretty simple. JumpCloud is already making sure your agent's up to date. So as we put new things in, that'll be in there. 

All the JumpCloud Go pieces shipped a while ago, like two or three weeks ago, because we came out, I think we launched on the 16th of November 2023. There was a Chrome extension update, but that came out in the beginning of November. So you need to make sure you're on the latest of all those things, but most of those should happen automatically. If you're not using Chrome, if you're not forcing the JumpCloud Go extension through Chrome, that's a recommendation because that just makes it real easy for everybody.

There's no questions that they have to use there. And then, as soon as they sign in to Chrome with one of your accounts, push it through the Google Chrome Cloud browser administration. There's some acronym that I always mess up for that. So Chrome extension being pushed and forced, fantastic. That'll be updated automatically. The JumpCloud agent gets updated automatically. 

Then it's really a process of going out and just setting it up in AW wss. And again, this won't just automatically happen. The user has to go to a URL, so when you set up AVA, you get a URL public facing that you can use. So you've got to set that up and go through there. And so there may be a little bit of IT work that you have to figure out. Can your private application that's in Amazon handle a different URL, maybe smooth out some of those things. But those should be pretty simple and won't be really that unique to this flow. Mostly just if you are going to be doing any sort of reverse proxy work or anything like that, it would be very similar.

Q&A: Policy Concerns

Urvashi H.V.:

Another question I'm thinking of, based on the questions we get a lot, are there any policies that might accidentally contradict the setup requirements? Because every now and then a weird combination of security policies will accidentally make something not work.

Tom Bridge:

Well, I mean, you wouldn't want to, at that point, have a policy to ban the JumpCloud Go Extension and enforce the JumpCloud Go Extension because that's going to be a pretty complicated, undefined condition to resolve.

Urvashi H.V.:

Not allowed on the internet.

Tom Bridge:

I was going to say, you were going to want to make sure that internet access is available to your devices, especially if they want to use the internet to access an AVA application.

Urvashi H.V.:

But the internet is not secure, Tom. I mean should we be allowing people to go online?

Tom Bridge:

This again goes back to teaching sand to do math. We have made a tremendous leap forward, all at the cost of everything.

Joel Rennich:

But we do look forward to people finding new and unique ways to do this. I mean, definitely things are still pretty early for us, but yeah, in the general sense, I do think it is pretty simple and pretty straightforward to set this up. But yeah, if you do run into any confusion, please let us know. We've got a number of avenues that you could talk to us, and we'd love to hear about your experiences, what you're using it for and where you want to go next with it.

Tom Bridge:

Absolutely. IT admins are in fact nothing if not creative. That's very true.

Becky Scott:

Yes. So if they can find a way, they might, they probably will. Right? Anything else you wanted to bring up on that topic, or do you think we flogged that horse enough for now? There'll be more later.

Final Thoughts and Call for Feedback

Tom Bridge:

I'd love to plant the idea with everybody who's listening today. If there's a use case that you have in mind for using AVA with JumpCloud, we'd love to hear about it. Drop us an email. My email's real easy. It's tom.bridge@jumpcloud.com, and I'll get you connected with John and Joel if we think it's appropriate. 

But we think that there's a huge amount of opportunity out here for making this an incredible success within your organization. And if you've got some things that you want to talk about, we would love to hear about it. So we want to make sure that you guys are getting everything you need from us, especially at implementation time. So please drop us a note. We're very curious to get this explored.