Loading summary
Transcript72 lines
- [00:00]
Patrick Gray
Foreign and welcome to another edition of the Risky Business Soapbox Podcast. My name is Patrick Gray. In these soapbox podcasts, everyone you hear in one of them paid to be here. They're sponsored podcasts, but you know, they're actually very interesting because we get to speak to interesting companies all about what they're doing, how they see the world, so on and so forth. And today we are joined by Fletcher Heisler of Authentic. Now Authentic is an open source based idp, so you can think of it in terms of like being similar to Okta, I guess, but you can run it on Prem. You can also get it. Well, eventually I think you can get it as SAS from Authentic themselves. But the idea is you can really take the reins of this thing, get under the hood, make a bunch of changes, only use the features you want, write new features if you want new features, so on and so forth. And Fletcher is the chief executive at Authentic, which as I say began life as an open source project. So he's not the founder or a co founder of the open source project, but he's certainly a co founder of the commercial side of things over at Authentic. Fletcher Heisler, thank you so much for joining us.
- [01:10]
Fletcher Heisler
Thank you Patrick for having me.
- [01:12]
Patrick Gray
Now, how did I go with the intro there? Right, like, because I often find I introduce a company and they'll, they'll cringe when I say it's sort of like an open source octa or something, I'll say no, it's completely different. Like why don't you articulate to us like how you would describe Authentic?
- [01:26]
Fletcher Heisler
That's a pretty good one, Leider. And as you mentioned, they're kind of the two components there. So our founding cto Jens, started building Authentic, the open source project, nearly seven years ago. And so as a full fledged idp, it's had a long life. It's had hundreds of thousands of home lab users building up and contributing and giving their feedback across that community. Authentic Security, the company was also formed as a public benefit company around Authentic, the project a little over a couple years ago. We have that mission of maintaining, supporting, building upon that open source project while building up the enterprise side of our subscriptions. Obviously support from the team, but then everything on top of that, that typically a Homelab user doesn't need all the bells and whistles of auditing and compliance or other specific integrations. But any company at scale with hundreds, thousands of users and beyond is going to need a little bit more beyond that standard IDP as well. So yes, we are right now focused on self hosted, it is a standalone Docker or Kubernetes. You can run that in your own private cloud. We just released cloudformation templates, so a one click deployment on AWS and we'll be probably moving into sort of managed hosting and making that even easier for folks to stand up over time as well.
- [02:51]
Patrick Gray
All right, so we know Authentic is an idp, we know it's based on open source, we know all of the things you've just told us. But how is it different to the incumbent idps? Why is there a need for people to look outside? Because this is a mature product category, right? Like it's not like IDPs, it's some race, startup race, right, where everyone's getting their Series A rounds and like trying to build out this thing. IDPs have been around for a long time. We're talking publicly listed multibillion dollar companies. You know, why is it that we have you now stepping into what is an extremely mature product category? What is, what's different that you're bringing to the table here?
- [03:26]
Fletcher Heisler
Sure. So we do have a little bit of a startup race going on the last couple of years in identity and hidden access and I think that's because there are so many problems to solve. But as you're saying, what we're seeing is here is your Windows onboarding for desktop, auth or very smaller pieces that someone can bite off with a seed series, a small team, and build on over a year or two. We're in the rare situation where we've been building out this full fledged IDP from the ground up with security and customization and flexibility in mind over the number of years that it's taken to get, you know, all of the sort of standards, you know, Name your protocol, SCIM, LDAP, RADIUS, SAML, OAuth, et cetera. All of that takes a whole lot of time to build an idp. And obviously there are not many, but a few very large incumbents that are in the space. That is a very sticky one. So there's also a lot of cost to changing over your idp. So the difference for us is it's all a Django project under the hood. Everything is very configurable. And so as an end user, once you've been using more of a legacy provider with their own black box solution, the same sorts of things start happening over time. You're paying more for getting less, you have to pay extra for the SSO tax. Except it's API access or whatever other security mechanisms you might need or want there. You're also spending a lot of engineering time building some duct tape widgets around those APIs to make them work with other integrations and applications. And so where someone might get you 80% of the way there, you end up building out so much extra infrastructure to manage on top. Something about that underlying system changes and then you're left in the dust. So we really let you customize as much as you'd like from the ground up with a very, very flexible solution that you own. So you can use Terraform for everything. Everything you could do in Authentic in the UI is available over an API. You can even write your own custom expressions. So if you want to reach out with your own provider, you could do that directly in Authentic. Similarly, for a lot of big companies, they might have even multiple idps or multiple systems and directories, sub organizations that they need something to cohesively talk to. Within Authentic, we're very much sort of vendor agnostic protocol. Agnostic. You could, as an example, say we're migrating away from this legacy provider. Let's reach out to them dynamically as part of the Authentic registration process. And so that's seamless for your users to be able to pipe that data in. They don't see any difference. They don't have to take any other actions. You don't have any day 0plug it in and hope that it works. But similarly, if you need to access, say, a legacy application that doesn't even have sso, you could do that through a reverse proxy through Authentic. So really it's sort of the breadth and depth of being able to use your IDP the way that makes sense for you and is much more manageable for these teams over time that they can fully customize that to their needs.
- [06:49]
Patrick Gray
Yeah, I mean, I find the business opportunity here actually really interesting. Right. And I forgot to disclose at the start of the, of the, of the podcast that I do have an advisory agreement with you guys, which means, you know, you do well, I do well. So it's good to be transparent about all of these things. But you know, the, obviously it, all.
- [07:05]
Fletcher Heisler
The advice along the way, but all.
- [07:07]
Patrick Gray
Of the, you know, the interesting thing is here, right, you would think, well, this is a home lab sort of thing, right? Like started as a home lab sort of thing. So many people using it in their home lab. But, but when you really think about the most likely candidates to jump on board in a business context, it's the very large companies first who are going to be wanting to do this simply because well, first of all, there's a cost reason there because you know, the IDP tax at a major enterprise is a very real budget item, right? Like this stuff is not cheap, so there's a budget reason. But then, yeah, again, there's that flexibility reason. So I'm guessing you would have already had some extremely large customers say, well, we're going to change this, right? So that's the thing. You can actually get in there and just say, oh, so many people using a major idp. Oh God, we would solve so many problems if we could just make this one little change. But people with Authentic are able to actually make that change. So I guess this is all leading up to a question, which is what are the first sort of changes that people are making? What are the first little ones? What bits of tinkering that you see from very large enterprises?
- [08:13]
Fletcher Heisler
So those earliest changes have already wrapped themselves up into features in Authentic that other users can use as well. I think that's become kind of the natural progression that something might start as.
- [08:25]
Patrick Gray
That's the beauty of open source, right? Is someone says I need to do this because it's useful and then it gets merged and everybody's got it.
- [08:31]
Fletcher Heisler
Yeah. And I suppose application integrations are probably the most common, but we've also seen that with GeoIP, for instance, setting policies to say, we expect this kind of team might be accessing for this kind of location, but if these folks do, we might want to level that up with additional constraints that might start out as six lines of Python that you embed within Authentic. Not even a code change necessarily, but then we see that from customers and say, great, let's templatize that, let's make that even easier as a best practice for someone else to adopt. Similarly, on the application side, if you go out to our integrations page on our homepage right now, it's very B2C looking in that most of the community driven stuff is I want to use this with Discord or things like that with our first major enterprise rollouts, Workday is probably a great example of an API that is challenging for any software to work with. Usually we didn't have a pre built workday integration, but we worked hand in hand with a customer, built that out as some custom expressions and scripting for. I think it took under a week. And then again we can leverage that with any future enterprise customers to say, yes, Authentic can work with that and we can make that easier in the future for everyone else to benefit from that effort as well.
- [09:55]
Patrick Gray
Well, it's Interesting what you said about B2C. Right. Because it's something that I haven't mentioned mentioned yet in setting all of this up is that, you know, a huge use case is you've got that. That what in the commercial space would be more that auth0 piece, which is when people want to add, you know, proper authentication to a web application and whatever, they can use authentic to do that. And you know, that stuff again, very expensive, right. From the commercial providers. So being able to get that for free. I have, I have. I am completely unsurprised that that's a popular use case. But I just want to go back to this issue of features, right? When you're talking about, okay, you see a lot of people doing this sort of thing, so you merge it as a feature. This seems a good way to sort of prioritize like what should and should not be a feature. But I also imagine you see people doing stuff where you think that's either stupid or dangerous and you decide not to merge it. Right. So how do you actually make that those decisions? Do you have any sort of formal processes in place where you evaluate and say, well, well, some people want to do this with our product over here, but we don't really think they should be doing it, so we're not going to merge it because how do you stop that sort of enterprise software bloat from taking over the product?
- [11:04]
Fletcher Heisler
Yeah, great question. And we routinely have these conversations internally. I would say for anyone. I think we're moving past the days of open source is scary just in general, but I hope no one's picturing that we just accept all contributions from anybody and that gets merged in. Fine. We keep a very tight watch on what gets merged in and why. We're really the ones, especially on the enterprise feature side, driving what that roadmap looks like. I think maybe the best example we've had where it's not a completely decided discussion yet, but we've had a couple folks come in asking for SMS as a primary factor. We never built that in because we thought it was a terrible idea.
- [11:47]
Patrick Gray
From a security perspective, this is a pickle. This is a dilemma, this one. There's actually a case for it, especially on the B2C side. There's definitely a case.
- [11:58]
Fletcher Heisler
Exactly.
- [11:59]
Patrick Gray
But you don't want people to be doing it.
- [12:02]
Fletcher Heisler
Been presented with a couple ideas or a couple scenarios of customers saying, here's why it's not quite the standard auth, but the risk factor is very low here. Here's why we might want that. And so there are a couple options there. We've started hiding things behind admin flags so that the folks in charge of the rollout can get all of the nasty warnings ahead of time of you can turn this on. Here's what might result. But there's always that discussion of should we provide the footgun if there are a few legitimate use cases there. I think it's really just about providing that flexibility so that everyone can meet their needs, but also defaulting to sane, having SANE defaults and having awareness from the end user and the end admin of what the end result will be there.
- [12:58]
Patrick Gray
But I mean, this is a great example of security, what I'd call security ideology, colliding with the real world. Right. Where sometimes you're going to have to pull the trigger on a feature that you, as you described it, it might be a foot gun, but you have to do it.
- [13:12]
Fletcher Heisler
Yeah. And so it's about also providing enough warning and enough context where the folks who need that can get to that. But you're not going to have someone mistakenly implementing something that's less than secure.
- [13:25]
Patrick Gray
Yeah. So look, why don't we just have a quick chat about what sort of customers are actually using this at the moment. I understand there's some really interesting use cases. I think emergency services call centers is one because if they lose their link, you know, they still need to be able to authenticate to their computers and things like that. People in Europe concerned about American spying and using American vendors, ironically enough, I think there's, you know, going to be traction among some of the agencies those people are scared about too, because they're running air gap networks, which I think is quite ironic. But why don't you just walk us through where this is getting the, you know, early adopter traction.
- [14:05]
Fletcher Heisler
Yeah, you've gone down the list there. And I think there's maybe a fourth category of folks who, as I kind of alluded to, are finding they're spending too many cycles building on top of their implementation of a standard legacy player. And they're ready to take a little bit more ownership of what that IDP looks like without having to build everything themselves as well. On the emergency services side. Yeah. The Emergency Service center for the State of Washington is using authentic to add in biometrics. They have six or seven different ISPs, but when things are literally on fire, they can't necessarily guarantee a connection there. They need the ultimate in terms of resiliency and reliability. Authentic can even be run air gapped on the healthcare side as well. You Might have a case where you have two instances and you have sort of a fallback when Internet connectivity goes out, but you want authentication and all of the systems that come along with that to still proceed as normal for however long is necessary there. And as you mentioned also in Europe, Jens is based in Germany. And a lot of our very initial customers and early adopters were folks like German cybersecurity companies, but really any folks who don't want to be just handing all of their PII off to a US SaaS provider, you can now do that and still own your data while running your own identity product. We have extremely limited and optional telemetry there again, can even be red hair gapped for folks in some more sensitive labs or agency type situations as well.
- [15:54]
Patrick Gray
Yeah, yeah, it's funny, right? Okay, so here's the thing that I, you know, if I had the crystal ball, if I could ask the Oracle sort of thing, the thing I would wonder about is where you're going to land in five years with regard to the business side of authentic. And the reason I say that is because, you know, a big selling point at the moment is on prem. On Prem and control, right? So you can run it yourself, you can fiddle with it yourself, it's all within your control. But I think IDPs are SaaS business models for a reason, right? In that it's very easy to not have to worry about running that infrastructure and whatnot. So while you're capturing all of these people who want the on prem and stuff, you are spinning up a SaaS version of this. And I sort of wonder if at some point, you know, you're going to become what you hate, right? Which is you're going to become another SaaS, you know, SaaS, IDP. I don't know, I just wonder what your thoughts are in terms of like. Well, first of all, you know, how's the SaaS stuff coming along? Because funnily enough, this was something that you were, you know, really putting a lot of effort into, but you've been so busy just servicing the demand for on prem, it's like it's less of a rush at the moment. But yeah, so walk us through like the journey to SaaS and how you expect that to wind up, because I'm real curious to see how that's going to go.
- [17:17]
Fletcher Heisler
So I was literally about to say the same phrase. And we don't want to just become what we're actively rallying against here. I think there's kind of a philosophical stance where we do think that folks should avoid Benderlock and should aim toward ownership, et cetera, et cetera. But if the mission is to make authentication simple for everyone, there is clearly a let us help you run that component. So we are not actively actually working on building out a SaaS solution right now because again we've had enough inbound interest and that's continuing to grow on Prem.
- [17:54]
Patrick Gray
To be clear, that was kind of the plan, right? And now it's like, well we're so busy with this other stuff that's just sort of back burned it a little.
- [18:00]
Fletcher Heisler
Bit was originally the plan. I think folks are more on board with on Prem or whatever version of on Prem you want to call it than we were expecting.
- [18:10]
Patrick Gray
Run it yourself. I mean, yeah, if it's in your aws like is it on prem? No, but you are managing it yourself. I get what you mean.
- [18:16]
Fletcher Heisler
Yeah, right. It's much more typically run it in your own private cloud using the same tools and infrastructure that are running everything else in your own private cloud. And so it's much easier to talk to that than to talk to somebody else's SaaS. Black box for teams that are large and capable enough there there is an overhead obviously when it comes to your own containerization, you have your own database, what does high availability look like for you and so forth. So our focus right now is making that as easy as possible. Things like the cloudformation template. We have a AWS marketplace offer now as well, so I think when we dip our toes in it'll be more managed hosted of how can you still own your data but we can help you set things up, configure things and keep things up to date. If we're to offer SaaS that would start out as if you want to try this out, but we'd very much like to graduate you to full ownership if and when that makes sense as part of that.
- [19:14]
Patrick Gray
But what happens if they don't? What happens if they're just like no, we're good. That's the question.
- [19:19]
Fletcher Heisler
That's another ongoing conversation similar to SMS primary factor. I think that's going to be somewhat let the customer choose their own adventure, but try to guide them towards what we think is the most responsible solution. I think the most important point to me is with IAM as a service there are the reliability concerns but even bigger is the shared attack surface there. I recognize that that's a very big problem to solve when you are taking in all that information for all of those companies and being the single point of failure for them directly One of the many nice parts about sort of on Prem is that you can lock things down as much as you need for your company specifically. You don't have to rely on us deciding what reasonable rules or what an attack looks like from our perspective on behalf of your company. But again, like everything, I would like to keep that separation.
- [20:28]
Patrick Gray
Everything that you're saying, it's like the people who are going to do a better job of that than like the majors, they're going to be big enterprise, right? They're going to have security teams, they're going to have monitoring, all of that.
- [20:36]
Fletcher Heisler
Right.
- [20:37]
Patrick Gray
So this really does look like it's for the time being targeted towards people who have specific requirements. You know, like those call centers that need to operate offline air gap networks, you know, sensitive labs, things like that. And also very large enterprise. Right. Like it's unlikely to see, you know, a small to medium business that might have one IT person going off and spinning up their own IDP in Kubernetes.
- [21:01]
Fletcher Heisler
Depends. We've seen quite a few of those who go from the home lab to their SMB and decide I'm already familiar with this, it's easy enough. But yeah, I see it as kind of if there's a bell curve, we're attacking both ends there where there might be some very specific use cases regardless of team size. Often quite small, sometimes. And there are some very large enterprises that have that ability and ownership to run things in a very complex environment and are looking to level it up from there.
- [21:32]
Patrick Gray
Well, I mean that might be the bell curve in terms of users and people adminning it, but the money is very much concentrated up the right hand side of that bell curve, which is the enterprise market. And speaking of, you alluded to this earlier but Authentic makes money by selling sort of enterprise features around compliance modules and whatnot. Is that about right? And are there any features that you're offering that you can't get from the majors in terms of those compliancy, logging, et cetera features.
- [22:05]
Fletcher Heisler
So yeah, on the enterprise side it's things like Chrome enterprise browser device trust and things like that. You won't see it at a HomeLab user, but we've seen quite a few enterprises who rely on Chrome and all things Google for sort of that layer of trust and they want to bring that into their idp. So that's one of a few examples of specific enterprise features. There's also enterprise support obviously that's included with that from our team that we want to make sure that it's a Successful rollout for those very large complex environments. Also that's where we get, as I mentioned, a lot of our ongoing features. So there might be a case where someone says we are rolling this out, but we need actually as an example, application entitlements. That was our most recent very large rollout where application level folks wanted to be able to assign roles and groups and permissions. Sort of like similar to a sail point kind of setup. Because of the flexibility of authentic. We were able to build that in just a couple of weeks. That may be a many, many months project, if ever for some more of the legacy players, if they'd like to build that kind of flexible layer in.
- [23:26]
Patrick Gray
Yeah, I mean one nice little feature that you've got. I don't know if the majors offer this. They might, but you can gate SSH access behind the IDP and serve it in a browse, which I like. That's a cool little trick. I'm working with another company that does like gated access via whatever IDP you're using and they can do it via network controls or whatever. But yeah, essentially proxying stuff through like a web enabled gateway. Is that popular?
- [23:53]
Fletcher Heisler
It is. It's actually just as popular with our Home Lab users. And so we're looking at allowing that in the open source rather than just enterprise because you can imagine someone who just wants to SSH or RDP into their remote box at a small scale. But then I'm sure there will be enterprise features on top of that. If you want to say record sessions or something like that, that's probably something that more on the enterprise you'd be interested in as well.
- [24:22]
Patrick Gray
You doing that yet?
- [24:23]
Fletcher Heisler
A lot of the. Not yet, but it's built in. The pieces are there if we see the need from customers to do so.
- [24:31]
Patrick Gray
I mean there's all of these companies that make stuff specifically for that.
- [24:34]
Fletcher Heisler
Right.
- [24:34]
Patrick Gray
Like the one that springs to mind is like strong dm. They're really good at that. Just having that box between you and your prod environment and doing all of the auditing and access control and whatever. But I can imagine that for people who don't need to go necessarily the whole way with that, like something like this would be tremendously usable and you know, it would tick the box basically.
- [24:57]
Fletcher Heisler
And to your earlier question of what can't you do with other idps? Because there are broad strokes, you can compare similar features and functionality across any major IDP and we help check those boxes too. I think it's the additional levels of flexibility and access and customization so, as an example, if you are enrolling employees with Yubikeys, you can actually check that ID and ensure that that is a secure Yubikey. It's a particular version, essentially. That's not something that if you want to ensure further security, all of the data is available to you, essentially. So that's one piece where we built it in as a templated feature, but there are many others where all the data is available to you. Let's say you wanted to use, with the GeoIP example, any other customer metadata. Maybe it's even coming from another identity provider. We don't have any qualms about letting you do what you'd like with that as an admin. So it's really just about that flexibility that's provided to allow you access to all that information in a way that makes sense for you and your team to use it appropriately.
- [26:18]
Patrick Gray
Now, we've spoken about some of the positive features people have tried to bake into this. What about some of the worst ones that you've rejected? Have you got like a top three?
- [26:26]
Fletcher Heisler
You should get Jens in here for that. I think he's probably got a long list of things we won't do. Let's see. I think what's happening more and more, there's kind of a marketing strategy of you should integrate with our platform so that there's some awareness there. And so we get a lot of requests to work with a particular hosting provider or work with a particular application that we've just never heard of. And we're looking to do that if a customer requests that from us. If a vendor comes to us without any proof points there, we might be a little more suspect of shoving that into the docs and the code and bloating things with something someone hasn't asked for actively. As an end user, I imagine there's.
- [27:15]
Patrick Gray
A lot of managed service providers and whatnot who white label this too, right?
- [27:19]
Fletcher Heisler
For sure, yeah. And we see, every now and again we will see authentic login pages come up in unexpected places. And we just take it as a side of pride that we're glad to see our name out there. And we're certainly the ones who know the system the best. And so I'm not too worried about anyone building on Top. There's a reason this is open source, but we're happy to see what works the best and add on Top as our customers and our community want us to.
- [27:48]
Patrick Gray
Yeah, I mean, I can't imagine that's a bad thing, right? Having MSPs do this because yeah, it's more awareness, it's more authentic everywhere. And I mean it's kind of like comes with the territory of being open source.
- [28:00]
Fletcher Heisler
Definitely. Exactly.
- [28:02]
Patrick Gray
Now Fletcher, one thing we're going to argue about now is the security benefits of open source. Because this is something that you wanted to talk about. The many eyes make bugs shallow. You know, substantiate that claim for me please, because this has been a long term argument that I've had over the last 20 years where, you know, I think in my mind having something be open source is great, but that doesn't necessarily motivate people to go forth and audit the code. How many eyes do you actually have on your code, you know, and what brought them there?
- [28:38]
Fletcher Heisler
For sure, while we get lots of our customers testing authentics code directly, whether that's black box or white box, you can actually see the code. And so they've done some code reviews as well. We get our at least annual pen tests and we publish all of those results as well. I think our fourth or fifth hire was on Security ops, which is rather unusual for a startup. So we've been taking this pretty seriously as a, a matter of transparency and prioritization from the start. That's what we could do on our side to encourage that. By way of comparison, I would say encryption is probably a good example. As a developer, would you use an encryption library that's been examined and out in the world and you can take a look under the hood and see what it does and how it works for a number of years, or would you go with the package that can only be examined by attackers and you don't get to know how anything is done? That sounds like madness, but to me that's kind of the state of identity and access as an industry point of comparison. Octa Nauth 0 these are both proprietary code bases that have been leaked on the Dart web. We as end consumers of them still don't get to know how things are secured unless a vulnerability is found. And then we get to know possibly about the change that was made rather than everything is open source and source available. You can see under the hood. You can see the decisions we've made over time. You can suggest changes, you can code review that yourself. That just seems like a no brainer in terms of the approach to take for building a secure system out in the open.
- [30:31]
Patrick Gray
Probably the strongest part of your argument there is that, you know, you've had customers actually do code reviews and I can imagine that's, you know, absolutely true given that you're in some pretty big environments and if they're going to make the switch, they're going to want to throw some hours at it. I think that's my, my issue with that just general argument that open source equals more secure is that quite often you'll have a project just sitting around and everyone assumes someone else has looked at it.
- [30:52]
Fletcher Heisler
Right.
- [30:52]
Patrick Gray
And they haven't. But for sure, you know, if you are going into high security environments and very large enterprises that do have teams, they're going to actually spend a bit of time with it. Can you think of like, I imagine some of the early code reviews would have been sobering. Right? They always are.
- [31:07]
Fletcher Heisler
You know, Bienza's been very careful in terms of building things out from the very ground up with security in mind. So it's not like we've never made any mistakes. We certainly have had plenty of CVEs, which again, we publish, we fix as quickly as we can. And I'm not pretending that we will make a bulletproof system. From day zero, we've actually had a hard time finding really good pentesters and so we had a pen test that essentially said we've come up empty and we got a second one. For the past year to really try to dig in, there was this code.
- [31:47]
Patrick Gray
Review or looking at your infrastructure or what was the scope of the test?
- [31:50]
Fletcher Heisler
It was both. Yeah. But I think the code review view in particular, to your point, open source doesn't guarantee more secure by default, but it does allow you to dive in and see how things were done very specifically. And if your attackers are going to see that, then it seems like your end user should also be able to see that, examine it thoroughly. And we have had a lot of really good even advice, not even necessarily security findings, but suggestions from customers of better ways to do things that we've implemented.
- [32:28]
Patrick Gray
I remember once an audit, a company I was working with years ago, they have a kernel driver, a Windows kernel driver, and they had that audited by a guy who's a real specialist in that and he didn't find any bugs, but he said you should take this part here and move it into user space because it doesn't need to be there and you could do this and just a few architectural suggestions that they, they acted on. But sometimes that can be the most useful part of the process, is just the resulting advice, which is there's nothing here, but that's because you got lucky.
- [32:58]
Fletcher Heisler
Yep. One that was interesting finding from our pen test, which was a little bit of sloppiness on our Part the testers pointed out that we didn't have secure password requirements for our testing at, you know, staging server that they tested on. Again, this kind of goes to do you supply the foot gun to the end user? To us, there wasn't a big security concern with doing that, but the more that we thought about and talked about it, if we did that, our customers are probably doing that in more production sensitive environments too. And so besides just adding stronger passwords onto our testing environment, we turned that into we should have some better default policies that you really have to work around to be able to spin up authentic without having secure passwords from day zero.
- [33:53]
Patrick Gray
Yeah, I mean sensible defaults are good, right? But then there's the question. So you act on a finding like this, whether it's a CVE or a change to a default, you've got all of these customers running this stuff on prem. How do you then distribute fixes, configuration changes and whatever? And because this is customizable, how do you do that in a way that's not going to break your customer deployments? Because I can totally see that you could give a customer a really bad day by shipping an update that's fine for everybody else but ruins their lives. How do you manage all of that?
- [34:30]
Fletcher Heisler
It is a lot to manage. There's no quick, easy answer. Besides, we have a very long checklist and we try to be as careful as we can with any breaking changes. We have pretty standard docs of Here is how to upgrade authentic and communicating ahead of time to our customers and their security teams. What to expect. The nice part about open source is we also get a lot of early testing in. And so as soon as a feature is merged or technically even before then, we have a lot of folks out in the community who are alpha testing that. And so we can get ahead of a lot of those issues before officially hitting publish and say good luck everybody, roll it into your production environments and get back to us.
- [35:18]
Patrick Gray
I mean, I guess the issue there is just having a patch bump into a customization, but again, having a hot site backup of your idp, I can't imagine that's too difficult or expensive, right? So you could just have that thing sitting there, roll out the patch to the prod, and then if it goes sideways, you just cut over. Do most people run like a dual setup like that?
- [35:40]
Fletcher Heisler
So authentic itself is stateless and beyond that in the background is postgres for all of your backup data and so on the enterprise side that's high available postgres, there's some Replication. There's some offsite backups happening as well, and we've seen a lot of those configurations where we can make recommendations depending on the particular use case.
- [36:03]
Patrick Gray
But, I mean, I'm not just talking about the database here. I'm talking about, you know, all of the custom scripts and all of the little bits and bobs, all of the weird stuff people have done with it. I just would have thought it would make sense to have that mirrored on some other box. Right. So you could, you know, do an upgrade and if things don't go well, you'd revert.
- [36:20]
Fletcher Heisler
Yeah. Yes. And that's all, you know, essentially those two components, there's the stateless authentic, and there's everything that gets stored in the database and. And called up from there. We do use Redis a little bit for sessions. But yes, that is essentially, you can pull that back from your backup along with all of the customizations you had in place.
- [36:42]
Patrick Gray
Yeah. Without breaking anyone's.
- [36:45]
Fletcher Heisler
Yeah. So I think the only other separate piece you might have there is maybe some terraform scripts in terms of provisioning some separate components there.
- [36:55]
Patrick Gray
Yeah. All right, well, Fletcher Heisler, we're going to wrap it up there. Thank you so much for joining us to talk all about authentic. And that's authentic with a K, not a C. And yeah, anyone who wants to go and just spin it up and play with it, they can. I mean, you know, I'd imagine you do a lot of, you know, like, downloads, just an insane amount of downloads of people spinning it up. So where can people find you?
- [37:17]
Fletcher Heisler
Yeah, millions and millions of them. They can go to our GitHub, they can go to our site goauthentic IO or just search for authentic A U T H E N T I K and I'm sure it will come up. You can, as Patrick said, download it, get started locally right away. You don't have to sign up for anything. You could just run it in your own little Docker, compose and then reach out if you want to scale up from there.
- [37:43]
Patrick Gray
All right, well, we'll be talking to you a lot more through the year. Fletcher Heisler, thanks for joining us.
- [37:48]
Fletcher Heisler
Thanks so much.