Temporary Authentication for external users and sensitive applications with Cloudflare Access

Hey, everybody. Hello, everybody. My name is Kenny Johnson. I am a product manager here at Cloudflare.

Today, I am jumping on to talk a little bit about one of our newer features in Cloudflare Access.

It's focused on temporary authentication. So basically the idea of granting a user temporary access or allowing the user to request access to specific resources.

So very excited to take you guys through this new feature today.

It's definitely something that helps expand the scope of what we're able to secure with access, as well as think about your security posture of particular applications, be it sensitive applications or just folks like contractors or junior employees having access to things like production environments or just things that are of a sensitive nature.

Awesome. So to go ahead and dive in, what I'm gonna do is I'm gonna just quickly set the scene and start at a very high level of Cloudflare's overall product offering and then work my way down into what Cloudflare Access is and then how this feature actually works within Cloudflare Access.

And then we'll go ahead and finish off with a live demo of the feature.

So if we start off at a really high level, I always like to just set the scene of what Cloudflare does, what we do at Cloudflare because there's so many different products.

Most of you out there in the world probably know Cloudflare for our application services.

That's things like our web application firewall, our CDN and DNS hosting, basic DDoS protections at layer seven for applications.

This is really where Cloudflare got started. The piece I'm gonna be talking through today are Cloudflare's Zero Trust Services or more broadly Cloudflare One, specifically our ZTNA product.

So our Zero Trust Network product is what allows you to put Zero Trust controls in front of your self -hosted applications, SaaS applications, as well as any intranet applications as well.

So applications that might be secured behind a private IP or private DNS record.

This is where that component of temporary access has been built in. The other thing that I think is really important to underline or underpin in this discussion is Cloudflare's network.

And the fact that all of everything I'm gonna show you today is built on top and is built to run in every single Cloudflare point of presence or every single Cloudflare data center.

So this means that there aren't performance penalties for a user halfway across the globe attempting to access and request access to a particular resource.

That isn't having to be piped back to a central data center or back to your office or anything like that.

That is being sent to the closest data center, being efficiently routed over Cloudflare's backbone to the closest data center to you to then send off that approval request.

So there really is very minimal latency in terms of users being able to request access and be granted access to particular resources.

It's also a really important resiliency piece as well.

If one data center goes offline, we're able to reroute that request to the next closest data center.

So you have multiple hundreds of redundant data centers that provide a level of resiliency that you wouldn't otherwise get if you were relying on one or two points of presence.

So digging into the product itself, it's our Zero Trust Network product or Zero Trust Network Access product.

On the site, you'll see it called Cloudflare Access.

And what Cloudflare Access allows me to do is combine things like multiple identity providers.

So you can plug in your own Azure AD instance or your own Okta instance and pair that with a social identity provider like GitHub or LinkedIn for your contractors, even to the point of requesting a one-time pin.

Which is the identity method that I'll be using today.

You can layer that with things like device security posture.

So is it a managed device? Is disk encryption turned on?

Things like that. And then additional contextual factors. So what request is the country coming from?

Is there a certificate on the device? Things really of that nature.

That gets run through all of kind of Cloudflare's networking services.

So there's baked-in DDoS protection, firewalling, things like that. You even have the ability to render certain protocols directly in the browser.

So things like SSH.

And then the final piece that you're now able to do is allow users to request access to resources they might not already have access to.

And I'll show you what that configuration looks like in the Cloudflare dashboard.

So what I'm gonna go ahead and do is I will pull up the Cloudflare dashboard and take you guys through the overall configuration of what this looks like within Cloudflare.

So where I'm gonna start is the Cloudflare for Teams dashboard.

And Cloudflare for Teams is broken into two core products.

There's the access product, which is the Zero Trust networking product that we'll dig into today.

And that's where the feature we're concerned with lives.

And the other side is the secure web gateway. The secure web gateway is meant to protect users from Internet-borne threats.

So protecting against known phishing links, malware, things of that nature.

And they do pair really nicely together in the sense of you can put access in front of resources and then gateway is able to log and show what a user actually did in that particular resource as well.

So let's go ahead and dive into access and quickly walk through how I would actually set up and configure access temporary authentication for a particular resource.

So in access, I have applications that I'm able to set up and configure.

I can do this on a domain level, subdomain level, or even for SaaS applications.

So in this case, I've got HubSpot plugged in, Salesforce, DocuSign, really any SAML SSO compliant SaaS application can be set up via access for SaaS.

So the key step before actually configuring one of these applications for Zero Trust access is to plug in your identity provider.

So I'll step out quickly and just show you guys login methods.

The way that this works is for a given login method, I'm able to connect my application ID secret, as well as if it is an identity provider that supports something like identity groups like Azure and Okta do, we can actually sync down those identity groups as well.

So you can create things around particular user roles.

So given a user is in marketing, they can access this particular site.

It allows you to get away from static email lists or broad blanket access grants to your entire company.

So once I have set up and established my identity provider, what I'm then able to do is establish and set up my application.

So I'm gonna go ahead and use an application that I've already set up and configured.

The way that I define this application is if it's self-hosted, I'm able to select a domain that I'm hosting on Cloudflare.

You can do a CNAME for this as well, if you don't wanna bring the DNS fully over to Cloudflare, either way works.

And then I can be more granular about this. So if I wanna use, and this is actually what we do internally at Cloudflare, we're huge access customers ourselves.

We use a base domain and then create most of our applications off of a sub domain.

So I can go as deep in these sub domains as I want, as I define this application, as well as I can do it at the path level as well.

So if you have specific pages within an application that you want to have a higher level of authentication or different method of authentication, you can set up and configure that as well.

So once I've defined the application, the next step is then to actually go through and define a policy to require or to define which users have access to the particular application.

Since access is a Zero Trust product, the way that it's configured is it's default deny.

So I have to explicitly grant somebody access to this particular application.

It's unlike the kind of legacy way of using a VPN where once somebody has the VPN, they just have implicit access.

In this case, you actually have to declaratively give somebody access to a particular application and every request being made to that application is checked to see does that user match that particular criteria?

So I'll go ahead and step in and walk through what the actual policy definition looks like.

So in this case, I've already preceded this with a require temporary authentication policy.

What I'm then able to do is I can create a set of rules around who I want to actually allow into that particular application.

In this case, I just have a fairly straightforward check of I'm saying anybody who passes my identity provider check is allowed access in.

But I can be really granular with these rules.

So I can do things like look at the country that the user's traffic is egressing from, look at their email address.

So I can have a full list of email addresses.

I can look at specific email domains. So an example of this is I could for Cloudflare, I could say anybody with a Cloudflare email address, and then maybe I have five to 10 contractors that I want to allow, but I don't want to allow their full domain.

I can input those contractors in as a static email list to allow specific contractors access, but not their full email domain.

I can do IP range as well as certificate checks.

So these are actually, it's basically a level of understanding the machine that a user is attempting to access from without any additional software on that particular machine.

You just look at an MTLS certificate.

This is also handy for if you have IoT devices or a service where there's no person involved.

Same thing with service tokens. It's an API token that you can include in headers to be able to validate API traffic.

And then we start moving into user identity pieces.

So these are things like you can enforce a specific login method or MFA method.

So I can require that maybe I have regulations that say I can't use MFA.

I can't use a soft token MFA or a one-time pin MFA. I actually want to require that users are using either a form of biometrics or a hardware key or a FIDO key or something like that.

This is something you can layer on top of your identity providers and require in one place.

So even if you're using Okta and Azure AD, you can require that both of those authentications are being put through a higher level of multi -factor authentication.

And then the final pieces are actually around device posture checks.

So these do require that you run the warp client on your device, which is our Cloudflare's client that allows you to forward proxy traffic, basically meaning that you're as a first hop out to the Internet, you're being pointed to a Cloudflare data center, and then you're sent out to the Internet.

If you have that client running on your device, you're able to do additional levels of checks.

So the first two I'll highlight are the ability to require that warp or gateway are running.

So these basically allow you to require that your user's traffic is at least being encrypted or more heavily or more securely that gateway, your instance of gateway is running on their device, which means that all their traffic is being logged, their traffic is being protected from malware, things to that level, which that becomes really powerful because you can do things that say, in order to reach this particular application, you must be running gateway before you can actually reach that particular application, which gives you a lot of confidence in terms of the security of the connection of that user, as well as what the user is actually doing in a particular application if you do wanna log that information.

And then the final piece are just a set of device posture checks.

This is not the exhaustive list, but I'm able to look at various components of that device.

So what's the device's serial number?

Is the device firewall turned on? Is disk encryption on? Is there a specific file on the machine?

Things of that nature. And then we have partnerships with major endpoint protection providers as well to allow you to do a check and verify that CrowdStrike is actively running on the device or Carbon Black is actively running on the device before allowing access into a particular resource.

So once I've pieced together and built these policies, I'm then able to go through and actually configure temporary authentication for a user.

So touching on what that looks like is there's really two features baked into one here.

And you can mix and match these when it makes sense. So the first piece is the ability to capture a purpose justification on a particular application.

What purpose justification allows me to do is on an individual request to a given application, this allows me to collect a business reason from a user for why they're actually accessing that resource.

This can be really handy from both a regulatory as well as a security perspective.

Oftentimes there are regulatory requirements around collecting justification why a user is accessing sensitive information, be it HIPAA information or PII or financial information or something like that.

It can be a really handy tool for compliance teams to have a clear documented reason why somebody's information was actually accessed as opposed to just having broad access and having employees that are able to poke around in really anything.

It's also something that really kind of helps enforce or build this idea of, do you really have a valid business reason for going and looking at this particular resource or is this just something that your curiosity was peaked on and it's not actually something valid that you should be going and looking at?

So that's the first piece. And what this does is once I successfully authenticate or pass the policy for a given application, I'm then served just a basic page that says, please provide your business reason.

That can be set up in standalone.

So I can turn off temporary authentication and just collect the justification or I can layer on temporary authentication as well.

And what temporary authentication allows me to do is it stacks on top of purpose justification.

So the user will have input their business reason for accessing that particular resource.

And then I can define which approvers are allowed for a given resource.

So in this case, for this application, I've set myself up as the approver for this particular application.

And then I'll be able to demonstrate what it looks like as a user actually goes through the flow of requesting access to that particular application.

I think the other important thing that I wanna point out is that we do this at the policy level very intentionally because this allows you to define the pool of users that needs to either require, that needs to either provide purpose justification to access a particular resource, as well as the set of users that need to request temporary authentication.

So maybe I have an SRE team that I'm okay with them just having direct access to a production server.

But maybe my just pure software engineering team, I wanna allow them to have access, but I want them to have to request access from their manager before they're able to access a particular server.

I'm able to do this by creating multiple policies. So I can have one policy, I'm able to have one policy, just a classic demo issue there.

Anything, it's always Murphy's law giving these demos.

Sorry about that. Let me pull this guy back up.

All right, so I'm able to, in a policy view, I can create multiple policies.

So in this case, I've got a require temporary authentication option, as well as then I can create a just general user pool or something like that, where I'm saying, given that you're in a specific Google group or you're in a specific Okta group, then I don't want to actually require purpose justification.

So I can be really granular and really targeted about which users I do wanna require purpose justification and temporary auth with versus the others that can just as part of business as usual, have access to that particular resource.

Awesome.

So now what I'll go ahead and do is I'll actually demonstrate what this flow looks like end to end.

So I'm gonna pull up a new window. And I've just got that application, kennyatx.com, protected behind access.

Remember, this was the one that I, I'm allowing anybody who passes my identity provider check, but I wanna require temporary authentication.

So I'm gonna go ahead and request a one-time pin to my personal email address.

And then I've set up and configured my email address, my Clubflare email address to be the approver for this.

So I'm gonna go ahead and do my one-time pin that was set to my email.

This will then take me to my purpose justification screen.

So I can customize this message as an administrator.

So then I would expect a user to say something like triaging ticket number one, two, three, four, five, something like that.

I'm gonna go ahead and submit.

And then what this will do is this is going to go ahead and request access to my, to the set of approvers.

So in this case, I'm showing my Kay Johnson email as the approver.

I can optionally share this as a link. So if you're a big Slack or Teams user, you can actually just copy this, drop this in Slack, send it off to your approver.

They can open that and they'll go through and off. In this case, I also received a message to my email.

So I'm gonna go ahead and just pull that screen up.

I've paused share for a second. So you guys can't see what's in my email quickly while I pull that up.

Alrighty, let me get this guy.

So, and then the final step here is I'm just gonna go ahead and authenticate.

Cool, so I authenticated, proved I was who I said I was.

I didn't wanna show you guys the flow there.

So once I've authenticated as Kay Johnson, I'm then able to either approve or deny the request.

And then I can set the duration in which the user has access.

So if it's something really secure or something really sensitive, I can say, oh, I only want them to have access for 15 minutes.

Or if it's something I know they need for the full day, I can grant them access for the day.

And the way that that mechanism actually works underneath the hood is once a user is granted authentication, it works the same way as if you passed a normal access policy.

Basically what we do is we'll generate a JSON web token or a JWT that we issue to that user's browser session.

So it basically lives as a cookie on that user's browser for the duration in which their session was granted.

And there's handy things you can do with the JWT that's granted.

You can use that JWT directly in your application to build role-based controls and things like that.

But the user appears the same if they come in via temporary authentication or as normal user.

So I'll go ahead and approve this. And then if I jump back over to my access request, this should, it'll, takes just a quick second.

You can see it pinged over down in the bottom left there.

And then I'm allowed into my access protected resource.

So that's kind of the quick end -to-end flow of what temporary authentication looks like.

Really the basics are I just set up a group of approvers and I want to define the pool of who I want to allow temporary access requests to for a particular resource.

And then the user is able to request, share that link back to their approver.

And then the approver can grant that for between 15 minutes to an hour.

So then the kind of the final payoff here is that I begin to build a rich set of logs for that particular application.

So all of my access requests made to that particular application are then centrally logged directly in access.

So instead of having to go look in my SaaS apps for one thing, and then a central service that I had to build for my self-hosted apps or log files for individual self-hosted applications, all of that is centralized directly in your Cloudflare access dashboard or your Cloudflare for Teams dashboard.

So the blog that I was just allowed access to, I've now got rich logs around who was granted access when they were granted access, as well as the justification reason provided by the particular user, and then who approved that particular access request.

So this gives you a really nice audit trail for particularly sensitive resources, or if something happens in production, you have a very clear audit trail of who had access, when did they get access?

What's the timing of the access that they were granted?

And then this can be pushed out to, we have a tool called Cloudflare Log Push that allows you to push logs out to various security incident or event and incident management tools like Splunk and Datadog and things like that.

And then even more powerfully, if you wanna get into using gateway as well, is you can actually look at the individual DNS network and HTTP requests being made by that particular user, and you can search for a particular host.

So look for the host of the access protected application. So you can go as deep as you want, or as shallow as you want in terms of logging user behavior within your particular application.

Excellent, so that's kind of the quick overview of temporary authentication.

I think that the one other thing I'll call out is this pairs really nicely with our browser-based SSH and VNC tools as well.

So if you wanna grant access to allow a contractor to have SSH access to a particular resource, you can do this with our browser rendered SSH.

So I've set up and I've exposed an SSH server via this particular domain.

I'm able to come in and say that I wanna do browser rendering via SSH for that particular domain.

And then in my policy, I wanna require that temporary authentication is done to access that particular resource.

So I'm really able to stack all the various things that are available in access to create a Zero Trust option for allowing external users or internal users to have SSH access to a particular machine all directly within the browser as opposed to having to do it directly from their device which gives you a bit more control.

You don't have kind of cross attack service on the device itself where you have to worry about compromised devices as well as control over session timing and things like that.

So these start to become fairly powerful tools that you can stack and build together as you go through and do that.

Excellent. So that's kind of the quick overview of Access Temporary Authentication.

The final plug that I will make is if you wanna read more about this, I'm gonna go ahead and pull up the blog post that we had for it that got posted a few days ago.

So I'll go here. You can actually just search this.

If you look up Cloudflare Access Temporary Authentication, you'll see a blog here directly on the blog and it goes through and gives you a little bit more information.

And then most importantly, if you wanna go ahead and give it a try, it gives you some directions to go ahead and follow to either get this enabled in your Teams dashboard if you already are using Teams.

And if you're not using Teams, it's free up to the first 50 users if you wanna go ahead and give it a try.

And that is all kind of outlined on the webpage for Cloudflare for Teams.

With that, thank you all very much. Thanks for joining. Hopefully this helps solve some problems that you've got in terms of your access management challenges to particular resources and applications.

And thank you so much.

Enjoy your afternoon, evening, morning, depending on wherever you're at in the world.

Thank you so much. We're betting on the technology for the future, not the technology for the past.

So having a broad network, having global companies, now running at full enterprise scale gives us great comfort.

It's dead clear that no one is innovating in this space as fast as Cloudflare is.

With the help of Cloudflare, we were able to add an extra layer of network security controlled by our partners, including WAF, DDoS.

Cloudflare uses CDN, and so allows us to keep costs under control and caching and improves speed.

Cloudflare has been an amazing partner in the privacy front. They've been willing to be extremely transparent about the data that they are collecting and why they're using it.

And they've also been willing to throw those logs away.

I think one of our favorite features of Cloudflare has been the worker technology.

Our origins can go down and things will continue to operate perfectly. I think having that kind of a safety net, you know, provided by Cloudflare goes a long ways.

We were able to leverage Cloudflare to save about $250,000 within about a day.

The cost savings across the board is measurable, it's dramatic, and it's something that actually dwarfs the yearly cost of our service with Cloudflare.

It's really amazing to partner with a vendor who's not just providing a great enterprise service, but also helping to move forward the security on the Internet.

One of the things we didn't expect to happen is that the majority of traffic coming into our infrastructure would get faster response times, which is incredible.

Like, Zendesk just got 50% faster for all of these customers around the world because we migrated to Cloudflare.

We chose Cloudflare over other existing technology vendors so we could provide a single standard for our global footprint, ensuring world-class capabilities in bot management and web application firewall to protect our large public-facing digital presence.

We ended up building our own fleet of HAProxy servers, such that we could easily lose one and then it wouldn't have a massive effect.

But it was very hard to manage because we kept adding more and more machines as we grew.

With Cloudflare, we were able to just scrap all of that because Cloudflare now sits in front and does all the work for us.

Cloudflare helped us to improve the customer satisfaction.

It removed the friction with our customer engagement. It's very low maintenance and very cost-effective and very easy to deploy and it improves the customer experiences big time.

Cloudflare is amazing. Cloudflare is such a relief. HAProxy is very easy to use.

It's fast. Cloudflare really plays the first level of defense for us.

Cloudflare has given us peace of mind. They've got our backs. Cloudflare has been fantastic.

I would definitely recommend Cloudflare. Cloudflare is providing an incredible service to the world right now.

Cloudflare has helped save lives through Project Fairshot.

We will forever be grateful for your participation in getting the vaccine to those who need it most in an elegant, efficient, and ethical manner.

Thank you.