Quickly onboard engineers and protect infrastructure with Teleport as a SAML and IDP

Quickly Onboard Engineers and Protect Infrastructure with Teleport as a SAML and IDP

In this webinar, we’ll go over how companies protect access to applications using Teleport. This webinar will focus on the workflow for quickly onboarding engineers to access your infrastructure and highlight how teams can use Teleport as a SAML and IDP for apps and websites.

In the latter half of the session, we'll delve deeper into the technical intricacies of SAML and share valuable tips for enhancing the security and modernization of your IDP through the implementation of passwordless authentication. Don't miss this opportunity to bolster your organization's access security with Teleport. This episode will have content for existing Teleport users and people just learning about Teleport.

Key topics on Quickly Onboard Engineers and Protect Infrastructure with Teleport as a SAML and IDP

• As teams grow, the need to quickly onboard and offboard engineers is very important for a range of things and is often accompanied by a growing infrastructure and more applications.
• Additional complexity and scale result in more risk.
• Increasingly sophisticated attacks are on the rise, often caused by a simple mistake made by a person.
• When attackers get access to a secret, they establish a foothold in your infrastructure and can then easily pivot to adjacent systems.
• Without Teleport, engineers must access infrastructure using an insecure and cumbersome mix of VPNs, bastions, secrets and legacy PAM solutions, each with its own access control and audit layer.
• With Teleport, every connection across your global infrastructure passes through Teleport’s Identity-Aware Access Proxy where it is authenticated and authorized based on human or machine identity.
• The SAML identity provider allows Teleport users to authenticate and authorize to external applications, both inside and outside of Teleport, that support SAML Single Sign-On.

Learn more about Teleport

- Teleport Labs
- Contribute on GitHub
- Join our Slack community
- Participate in our discussions
- Why Teleport
- Get started with Teleport
- Teleport Resource Center
- Teleport integrations
- Teleport documentation

Transcript - Quickly Onboard Engineers and Protect Infrastructure with Teleport as a SAML and IDP

Ben: 00:00:10.915 Okay. Hi, everyone. Thanks for joining us today. I see a few more people coming in. Just give us a couple more minutes. I know it's just 9 o'clock on the hour. I'll probably start just two minutes past. If you want to let me know where you're from, I see there's a few Teleporters here. Thanks for joining. We get started shortly.

[silence]

Ben: 00:01:04.902 Okay. Hi, everyone. All right. A couple more minutes and we'll get started very shortly. Yep, David, today's session will be recorded and will be available on this platform as well to get. And also happy to share the slides. Also, if you go in the right-hand tab, you'll see there's some documentation. There's some info to a blog post, which we cover a lot in this talk today and some docs about how to set up Teleport. Okay. So I'm going to get started. Mike, do you want to come join me from the backstage, make sure everything's working? Hopefully, be joining us shortly. He'll also be joining us on webinar today. But today we're going to be talking about how to quickly onboard engineers and protect infrastructure using Teleport as a SAML and an IdP. There's lots of acronyms happening in here, and this is going to be a sort of intermediate Teleport webinar, but we're going to cover a few of the basics to get started for people who aren't familiar with Teleport.

Ben: 00:02:30.275 Ashley asked ChatGPT about what would be a better title and — Teleport Turbocharged Streamline Onboarding Secure Apps and Unleash Some SSO. This is the power of access control. So let's get started. So myself, I run the developer relations team here at Teleport and you may have seen some of my other webinars. I have Mike with myself here who is the engineer who built a lot of the features and functionality that we're going to be demoing today. So if there's anyone technical in the audience, please ask as many questions as you can to Mike. Mike, do you want to give a quick introduction?

[silence]

Ben: 00:03:16.326 All right, let me see. Mike might be having some technical difficulties getting into the stage. Let me just check with someone else to see if he can come join us for a quick intro. [silence]

Growing teams, infrastructure, and applications

Ben: 00:03:41.354 Okay. I'll give Mike one more minute. Hopefully things can work out. There's always some technical difficulties, but I'll keep on going. Hopefully, Mike will come and I can come back here. So to set the scene, I think everyone has either growing or shrinking teams. These are some things that we're seeing, and some of the problems to solve. So as teams grow, the need to quickly onboard and offboard engineers is very important, and it's important for a range of things. And there's a few things we're seeing. So we're seeing growing teams, we're also seeing a range of growing infrastructure. Each year, this multiplies whether you're running your virtual machines in AWS or you have bare metal, just computing, in general. You have a range of infrastructure growing and yet you have an abundance of applications also growing. I think the average SaaS startup was running something like 150 software applications, and there's also internal applications that you run and maintain. Oh, here we have Mike.

Mike: 00:04:46.080 Sorry about that.

Ben: 00:04:47.523 No worries, Mike. All right. I'll finish problems that we're solving. We also have a range of growing secrets as you try to access all of these applications, and all of this complexity results in extra risk that you see in your infrastructure. And these are stats from our infrastructure access reports. The mixture of large growing teams, lots of applications, complexity of infrastructure, kind of causes all these problems due to scale and risk. So we are seeing lots of breaches due to shared secrets, many organizations using just a shared secret as their main access method. And then the third point is we looked at a room of people, 76% of people aren't even sure that the ex-employees still have access to the infrastructure, and this can create a range of problems, which should be pretty obvious. But especially if you're in a highly compliant industry, it's a big no-no to give people access to all of their secrets. And this will lead to a range of attacks. But before I go into attacks, I know, Mike, you just want to give a quick intro before we go further.

Mike: 00:06:04.991 Yeah. Hi, I'm Michael Wilson. I am a software engineer here at Teleport. I've been here for, I don't know, nine months or so. So hi, everybody.

Anatomy of an attack

Ben: 00:06:14.644 Hi. And then Mike's going to go over the second half of the slides. So I'm going to keep coming to what we see as a result of all these secrets. And this is what a standard attack looks like. We have secrets leading to a breach. We have individuals, humans making a mistake. A hacker will exploit their humans' errors, just all secrets. And also these mistakes — they may be relatively trivial on the schemes of a relatively advanced — last pass was an attack on a Plex server on someone's own machine. And so we're seeing increasingly sophisticated attacks, which may even be a small mistake on the person doing something. And then when they get access to a secret, they establish a foothold into your infrastructure. And then when you get a foothold, you can easily pivot to adjacent systems. And there's a range of sort of industry responses to all of these. So people do phishing training, people do vaults, people do endpoint security. But a range of these responses don't necessarily solve the [inaudible] solution. And this is one of the problems that Teleport solves in the world of zero trust. And the concept of zero trust is we no longer have the perimeter-based security and you trust the individuals and the endpoints explicitly and have checks in place.

Quick poll no.1

Ben: 00:07:39.108 So I'm going to just do a quick poll here to check where everyone is. So I'm going to open a poll for if you're currently a Teleport user. If you go to the polls tab next to the chat, you should see a little red button, and if you could just fill this in, let me know if you're currently a customer, whether you're in a POV or looking to learn more, and this will help us to share a bit more information. Okay. So I think these kind of votes are coming in. Let's see. We have a mixture of people using our self-hosted enterprise products, some clouds, some community edition, and people looking to learn more. So kind of a good blend of people. And for people who aren't familiar with Teleport who are new, well, our community edition is our open-source edition. It's slowly ramping up. This is available on our downloads page, but also GitHub. And one thing that we also believe is lots of our security features are also available in our community edition as well.

Before and after Teleport

Ben: 00:08:58.259 Okay, going to stop sharing the poll and come back to the presentation here. So for people who are new to Teleport or even people who exist in Teleport, this is likely what your lives look like before Teleport. You have a sea of infrastructure and assets available that you're using in the day-to-day that you've kind of connected. You've slowly cobbled together a solution of maybe some bastions on GCP, maybe a VPN for a database with a password, and maybe a dedicated PKI for Kubernetes, and you have this huge web systems, which slowly evolves over time. And as this system grows and your team grows, it becomes really difficult to manage. And this is our standard customer before Teleport, and this is what life looks like after Teleport. And so Teleport is a unified access platform and gateway to your infrastructure. Everyone, both your engineers and services connect through Teleport to access the resources. We have access policies and audits on Teleport itself. So this is the checks that you can perform to make sure that both engineers and services only have access to certain roles and resources on demand.

Ben: 00:10:23.917 And we started off providing access to SSH and Kubernetes, and over the last couple of years, we've continued to add more databases, web applications, and Windows desktops. And one thing that's sort of unique about Teleport compared to other solutions is that we always get very deep on the protocol. And so for example, for Postgres or for MySQL, we speak natively that protocol and so we get more information in our audit log. And I'll give you a little demo of what the UI looks like as well. And one thing that's sort of missing from that diagram, and I've kind of alluded to before, is we also remove secrets in all of this infrastructure. So there's no passwords in Teleport or private keys. Everything is certificate-based. We use stateless agents. We have biometric authentication. And for people looking for more secure options, we also have TPMs on the client with our passwordless edition, and also you can back Teleport or server using HSMs.

How Teleport works

Ben: 00:11:30.687 So I'm going to just share this quick diagram of how Teleport works to sort of tie things together. Going back to our initial diagram of all of the people, you have engineers and machines connecting to their various tools that they like to use normally, so kubectl — tsh is our command line tool. You come in. You log in for the day. When you log in, you go through the Teleport proxy, this goes out to your identity provider. The identity provider — this can be either GitHub or it could be an Okta or Active Directory. This checks whether you're still employed, which groups you have, what's the traits of your user? This will be important later on for when Mike goes into the demo. Then based upon that check, you say, "Hey, Ben is in DevOps." You get access to the production systems. Mike is in engineering. He does get access to the staging systems and some databases from any query. And so everything goes through the central proxy, everything is audited, and then you get access to your infrastructure. And so you can put all of your infrastructure in private subnets, run the Teleport agent as a reverse tunnel. So nothing has to be on the public internet.

Ben: 00:12:42.956 And just up here on the top, you see we have just-in-time access requests. This is a pretty cool feature for organizations looking to lead the principle of least privilege. And so Teleport lets you not only say, "Hey, Mike is still working at Teleport, he has access to staging, but occasionally Mike needs to access production systems for debugging." And the way in which we solve this is we have just-in-time access requests. So Mike can say, "Hey, I need to access the production server and the production database to run this query." These access requests go through Teleport and you can send this out to third-party providers. So if it's just a day-to-day thing, you can go into Slack. If it's a break-glass scenario, you might want PagerDuty to wake someone up in the middle of the night to give him access to — he can fix the solutions. In today's webinar, I'm not going to go too deep into sort of the introductions. We have lots of great webinars on the introduction to Teleport. This webinar from Jay and Dan is great. It's really popular on our YouTube. If you're new and you're just looking to learn more — I know there's eight of you, I'd really recommend starting with this webinar. But I hope at a high level, we're going to be talking a lot more now about SSO and SAML integration and Teleport as an IdP.

Teleport as a SAML identity provider

Ben: 00:14:02.595 So logging with Teleport. Teleport as a SAML provider. This is sort of the key topic for today's talk, and this is a new feature that was added in Teleport 12.2 or one of our recent patch, 12.1, Mike points out. And this is a pretty interesting addition to Teleport. And what it lets you do is sort of extend how you access applications. So I'm going to show this — actually, why don't I show you Teleport itself? I have this backup video, but it's always good to just do a live demo. So this is the Teleport web proxy. You see here I have GitHub as my identity provider. We also support passwordless. But I'm going to log in. Since I'm already authenticated with GitHub, you see the flow kind of work smoothly into Teleport. Here, you can see I have a range of my servers and my databases, my applications, and Kubernetes clusters. I'm going to focus next on protecting internal applications. So this is an example of — say, you have internal wiki or Metabase or Jenkins, these are all tools which — if you see in this URL, we have Jenkins. — the URL of Teleport. These are only accessible and protected by Teleport itself.

Application Access

Ben: 00:15:33.196 So if I was to go to this URL — authenticate me in. So let me open up the wiki. It has this slight thing, so it's sort of authenticating with Teleport service, and it's going to connect me directly to the wiki. We'll give it one moment. The demo gods still waking up this morning. Let me pick this webinar app. So you can see this is our webinar app. The URL has changed to webinar. I don't think you can just see it because it's cut off in our webinar platform, but you get access to this application. And you can use this to protect a range of applications both internal, and also we're going to be talking about protecting external ones. You may see here — we also have AWS. This is another feature that we support, and this lets you share AWS IAM roles with AWS. So for example, here I have an AWS [inaudible], just scoped to CloudWatch. And if I click this, it's going to take me in. It will route me to AWS, and this takes me directly to CloudWatch. I have a role that I can view your CloudWatch dashboard, if I was to come in here to go to EC2. I think I have access to an EC2. Let's see. Yes. I wouldn't have the permissions.

Ben: 00:17:07.616 And so this is another great addition if you want to share access to resources. So you see, I didn't have the access policy. And it makes it very easy if you want to give access to specific roles in users, also mapping to your Okta identity, as you sort of mentioned before. Okay. So this is protecting internal applications, and, just for example, I'll log into Grafana here. And you can see here at the bottom, I've logged in as Ben Arent, and this flow uses our SAML SSO connector. So I've logged in with GitHub as my SSO, then I've gone into Teleport's, then I've given my SAML information assertions to Grafana, which is protected by Teleport. So we come back to the slides. Let me share this slide. Okay. So I'm going to do the same flow again. You can see we have the app. This is a Jenkins example. You can see I'm logged in as myself, and I have my Jenkins user.

Why we built a SAML provider

Ben: 00:18:18.139 So this is just sort of a short demo. Oh, and I think actually, this is another important part of Teleport, is that we have an auto log of all of the activity. So you see I successfully authenticated with the SAML service provider, and you get a full information log that you can send off to a SIM solution using a Fluentd plugin. So why do we build a SAML provider? One, it extends logins beyond Teleport protecting apps and also supports SaaS providers. What does this mean? This means previously, you had to protect an app by Teleport, but now you can just access other apps. So this is Jira on atlassian.com. I'm going to log in here. I'm going to just log in as [email protected]. If I log in here, it — actually log out. Let me come to Jira again, log in. I'm having a 404 error. But the demo gods, Mike, haven't been kind to me.

Mike: 00:19:38.950 No. [laughter] It's good that we have the video.

Ben: 00:19:41.598 It's good that we have the video. So if I come back to the video here, I log in at sort of atlassian.net, it will take me to Teleport, and then it redirects me back in, sends the SAML assertions. And so I'll show you that demo next. Another benefit of a SAML provider is often the IDPs and some providers are owned by IT. But if you're in the engineering team, you have to go through a long process to sort of protect your apps. So it's very easy to get SAML plugins for all of your applications, but most people don't go to the effort of it because it's very easy to add it to your application, but you have to go all the way through your IT source to get everything sort of set up, configured. Another benefit is the greater unified audits, and then also access requests. So you have the ability to require access to different applications. If I come into access request here, you can see you can limit the access. So you may just want to give access to Grafana based upon access requests. This is sort of the flow that you'd go through. You'd say, "Hey, I need to run something on these different systems." And then you can change your SAML provider. It's a reason of access request as well.

Ben: 00:21:00.300 And then also Teleport can run self-hosted or on-premises. And so it lets you provide support for custom apps and also [inaudible] environments as well. So this is luckily, the Jira example, I'm going to log in as Bob. I likely had a shared session. So I log in. I've come back to Teleport. Here I'm going to log in with my username and password. The same thing would [inaudible] my identity provider. And then I'll be redirected back to Atlassian. And then here I was just configuring this. It's sort of an example that you see in the URL. We have atlassian.net. And then here I've logged in as [email protected]. And then you can see my permissions. So let me keep going. So this is the flow. So we've had login with Teleport, we go to the sign in, and then you go back to your application, which is a pretty standard SAML SSO flow for people who aren't familiar. And I think, Mike, you're going to take it from here.

Demo with external app

Mike: 00:22:18.256 Yeah. Yeah, definitely. Yeah. So if you're familiar with SAML, there's a bit of a dance between the service that you're trying to log into and the identity provider. In this case, Teleport is functioning as the identity provider. So you'll go and attempt to log in to your service, a request is made back to Teleport, which then performs the SAML authentication dance. Can we go to the next slide?

Ben: 00:22:51.900 Yep.

SAML attributes

Mike: 00:22:53.755 So when you log in using SAML, there's a number of attributes that come along in the assertions made by SAML. To date, we support just a user ID and the list of groups, and these are the attributes that come as part of the assertion. Depending on the application, you may be able to configure it to use these attributes to control access. It is very dependent on the application that you're targeting. But if there is need, this is definitely something that can be expanded in the future, but this is just kind of our first start at it. Shall we continue?

Ben: 00:23:42.358 Mm-hmm.

Mike: 00:23:44.416 So at the moment, this is a Teleport Enterprise and Team feature and Cloud. So this is not available in the Community edition at the moment. There is no extra configuration, however. It just is turned on. And it can be disabled, if you don't want it turned on for some reason. But it does come enabled by default. We've tested this with a number of different dev tools. You saw Grafana. We've tested it with Jira. But it's very application dependent — how the SAML configuration works. So there are some external tools. We had good luck using this, www.samltool.com, to help get the information from the application that we were targeting into Teleport. There is documentation online that kind of describes us all in greater detail. Yeah.

Application Access Okta integration – Teleport 13

Mike: 00:24:53.837 Yeah. Okay. So in Teleport 13, we are going to be launching Okta integration. So to clarify that, do you mind going to the next slide?

Ben: 00:25:07.335 Yep.

Mike: 00:25:08.698 So one of the things that we've noticed with Okta is that management of Okta right now, it's hard to do using the principle of least privilege. The example given here is some developer needs access to five different production applications in Okta. Okta, as is, this is something you'd have to go in and assign a user directly to some groups, let them do what they need to do, and then come back and alter their access afterwards. So what we're trying to do is close the gap here by, for one, allowing Okta applications to be synchronized with Teleport. So they'll display in the list of applications that Teleport already shows, and additionally, tie in our access request functionality with Okta so that you can do things like have an access request granted to these five production apps in Teleport, which is then going to be mirrored in Okta. And then it will be revoked when the access request expires. So this is a way of getting kind of like this short-lived access that Teleport provides in Okta itself. Could we head to the next slide?

Ben: 00:26:39.801 Yep.

Teleport resources associated with Okta integration

Mike: 00:26:41.254 Yeah. So as I said before, the applications list in Teleport will be populated with Okta applications. The access requests that are in Teleport will support hitting Okta directly and granting access within Okta. And just as with everything else in Teleport, you get your policy as code, you get unified audit. But now we kind of envision Teleport to just kind of be the source of truth for your infrastructure even outside of Teleport [inaudible] extending into Okta. We head to the next slide. So just to start with, this is an example of some of the Teleport resources that are kind of associated with this Okta integration. We have this notion of an Okta import rule, which will apply the labels that Teleport already has to the applications and groups imported by this Okta integration, which you can then use as part of Teleport's RBAC policies to grant access.

Mike: 00:28:04.635 We have this new notion of a group here, you'll see, and these are groups pulled in from Okta, and they'll be kept locally within Teleport and then you'll be able to request access to those groups as needed. And then with the role mapping here, you see we have these app labels and group labels. So if you are a user — yeah, sorry. If you're a user that has access to some of the labels injected by the Okta import rules, upon login, this Okta integration will detect that you have access to this and grant this access automatically. So in this example here, we have this Okta grant access admin. If you're a user that is part of this role, you'll be granted in Okta any apps with these labels, `value1` or `value2`, and any groups that have these labels. So we have some label name along with Okta prod admin.

Ben: 00:29:17.980 I could probably share that briefly too, if I remove my request. So these are the similar labels that you're talking about for RBAC [crosstalk].

Mike: 00:29:30.500 Correct. Yeah.

Ben: 00:29:32.895 Yeah. And so for people who are sort of new to Teleport, you have your identity provider, which maps to different roles that you create, and these roles, resources, you can define and add in, let's say, the [inaudible] or other information that you want to provide access to. So I think that's a kind of a good overview of the primitives. You wanted to touch anything else in here, Mike?

Mike: 00:29:57.909 Oh, I think that's good for now. I know we have a ton of questions [laughter] in the Q&A section.

Quick Poll no. 2

Ben: 00:30:06.146 We do have a lot of questions. So before we get to the questions, I can do another poll to say what information you would like to know about Teleport as an IdP, whether you're sort of interested in this feature that we've sort of gone over. It should be available in the polls tab. So if people can see that. All right. We need to work on our marketing. We have one person, still don't understand what the feature is. So hopefully, we'll get to that in our Q&A. Let me share the survey. Maybe some people will need a little bit more info, and one person is excited to do it tomorrow. Okay. Oh, we've got three people, so that's good. We've got some good activity on Teleport as an IdP [inaudible]. It's definitely a unique sort of interesting feature beyond the Teleport call, but we hope it will really sort of empower engineering and development teams. So I'm going to stop sharing and go back to it. You should be able to just keep filling that in. The poll is still open. I'm going to skip this one and just go to our questions before we get to next steps. I know we have a lot in the Q&A. So I'm going to go from the top downwards. Let me share this one from Tad. So you can use access requests to assume membership of Okta groups, correct. What configuration is required on the Okta side to allow this? This is going to you, Mike.

Q&A

Mike: 00:31:54.644 Yeah. You'll need an Okta API token, which can be created fairly easily, that has the access to grant and remove group membership and application membership.

Ben: 00:32:11.428 Okay. And then another one is documentation for AD. I guess, is Active Directory integration being updated? And if there's a kind of follow-up question on — if there's anything specific you're looking for, if you want to leave in the chat, maybe. Okay. We'll keep going. This one from David, "With Teleport agent running a reverse tunnel, essentially means you don't have to open up any security groups or firewall [inaudible]." Yes, that is correct. For the agency you're running, you just connect to the proxy. So everything is going outbound. You may want to do an outbound firewall. But inbound, you can just keep it completely closed. "After logging in, can the user be immediately redirected to the protected web app?" Yes. In this example, you might have seen I had the URL. So you have jenkins.teleport — cluster name, that will take you to a sort of login page which looks like Teleport. If you go through that subdomain, that will automatically direct you back to the application that you have. All right. Mario. "If we already have Okta audit logs, what is the benefit of Teleport as an IDP here? Do you work in tandem with Okta or you're substituting it?" Mike, do you want to give this one a bit more —?

Mike: 00:33:43.623 Yeah. This is really working in tandem with Okta. So if you're using Teleport internally for certain things and not for others, this is kind of giving you the opportunity to expand what Teleport can manage, and then kind of have a central auditing location. I think, yeah, saying that it's working in tandem is probably the most succinct way to put it. It's meant to kind of complement.

Ben: 00:34:15.926 Yeah. And I think, similar to the point, depending upon the size of your organization, it may be difficult to get IT to give you access to Okta groups and Okta resources, to set up an IdP or SAML for your internal apps. So since most teams already are quite comfortable with rolling out Teleport, it makes it very easy for them to protect internal web apps that they might maintain that might have no authentication or may just have JWTs. This is another option that is — another option for finding access. And last one, yes, the presentation will be available. I'll share as a PDF, and then also the recording will be available as well. Oh. And, yeah, the follow-up questions says, "For Azure ID, the documentation needs to be improved." So I'll definitely get the team's feedback, yeah, from that. So we'll look at fixing that as well.

Ben: 00:35:18.234 So let's see. "When will custom SAML and IDP come with the community edition?" It's a good question, Jordan. I will talk to my product person. I think in an ideal world, we would like to provide a little taste of this in our community edition. We'll have some interesting new sketch coming out next week. We'll make it definitely more accessible on Enterprise. I would just basically say, watch this space, come back on Friday and subscribe to our blog. We'll have more information that will make this more accessible to people as well. All right. Any other questions? Okay. I'll give people a couple more minutes. Okay. So support was good at helping. So recommended next steps. So if you want to try this, you can try Teleport's free for 14 days. I believe Teleport's cloud is now running 12.1. Is that right, Mike?

Mike: 00:36:35.800 I think so, but I am not the authority on that.

Ben: 00:36:38.772 Yeah. I'm 99% sure that you can try Teleport as a SAML provider. And the other information with Teleport as an Okta integration — this is going to be coming in Teleport 13. Teleport 13 will be coming out the second week in May. We're currently testing and debugging this. So our documentation and more information will be available. But we wanted to give you sort of a sneak peek about what was coming and getting people more interested. If you're interested in trying a beta release or alpha as part of the trial, we can probably get you set up to try out the software, if you're sort of new and very eager to get trained. Then last up, we have our getting started guide. This is a good resource if you want to run our community edition. And lastly, if you want to stay up to date, join our community Slack. And then also Teleport is an open-source, open-core business. We always appreciate a star on our GitHub repo. And you can follow Mike's updates too. So you can follow his issue and anything else that comes up. Create issues in GitHub and the discussion. Oh, thanks, [inaudible], for putting that up there. So let me just come back in. It doesn't look like we have any more questions. So I would like to thank everyone for joining today. Thank you, Mike. Thank you, everyone, for being here today. So really appreciate your time and looking forward to chatting more. Oh, Mike, he's got a compliment on your beard too.

Mike: 00:38:15.102 Thank you, Jordan. I really appreciate that. [laughter]

Ben: 00:38:18.963 Thank you, David. All right. I'm going to work on my beard game and to improve it. But thanks, everyone, for joining. Have a great week.