 Hello. Hey, this is Mike Schwartz. Hi, this is Mohammed. Hey, just a couple more minutes for everyone to get on the call. I'm just gonna paste a link to the attendance list. So anyone that's, oh everyone's already familiar with the drill, if not, or if you're new here, please just add your name and if you don't want to be called upon just please put no update and parentheses next to your name or if you're new, just leave it blank and we'll introduce you during the check-in. I think there's a couple of folks that are having some trouble with the new login system for Zoom. Sorry, what was the last bit? They're having a problem with the login? Yeah, it's now, I think it seems to require a Zoom login to actually join the call. I guess it makes sense. Yeah, I had a problem with that. The article two weeks back on pranksters going into public meetings that weren't secured. I had a problem with that a week or so ago and opened an issue to have us move away from Zoom, hopefully. For lots of reasons, not just this, but I recall that. I think you also put together an issue in the tracker there in GitHub, right? Yes, yeah. Is it something that, I was debating this myself, like do you think it makes sense from your perspective Zoom for public stuff that we don't mind sharing? I mean, the only time I think we'd ever have to change anything in a public meeting is if for some reason we had to edit a video because someone accidentally drops an F-bomb or something. So, do you think that Zoom is still acceptable for public stuff and then any private correspondence we get a WebEx or Slack instance? Well, I mean they've there's a lot of other concerns like anyone who's using the Zoom client on their system. I hope is doing so inside of a virtual machine or some other contained environment that make me fairly nervous about Zoom in general. And there's also things that, you know, there's a nice report by Citizen Lab talking about some of the privacy and other concerns with Zoom in particular about how they've gone about doing things and providing keys to, you know, on servers in China for reasons that you can probably guess and so on. So, I don't feel, I think it's not just something where there's like the one tiny potential, like the one tiny thing that happened that is the reason why you move away, but I think there's just a whole litter, you know, like just a massive number of reasons to perhaps not use Zoom, especially since we're SIG security. Well, the way you drive to get to running a PM or a box, then that's pretty concerning. It sounds like basically malware. Well, Apple pushed something that removed functionality from Zoom's client as part of like an update that they did a year or so ago. So and that's like unprecedented for them. They usually only do that to remove malware. So I'll let you draw whatever conclusions you want about it. How did they do that? Do they sandbox it or some sort of security policy that locks down syscalls or something? The way some people paint it is that like, do you recall entering your administrative password to get it installed? It kind of miraculously arrived on your system which is why it's so popular because it's so easy to start using it. But you can actually, you know, it raises some questions like how it's happening. You don't like to put your root password to get it installed. Well, it can do a lot. This almost feels like it warrants a review itself. So Matthew, to your your comment about, you know, public versus private considerations, you know, just to to riff on where campus was going like that with that for us in particular, you know, we are, you know, essentially modeling you know, to other groups. And so if we use the technology and, you know, therefore kind of promote it, right, we're seen as you know, sick security and authority in cloud data space and then you know, the technology that we're leveraging and everyone sees us, you know, and joins our meetings and is invited to use that technology. You know, it just doesn't play well. Well, Justin made a good point and this runs a bit against the one you brought the previous meeting on. Let's go, you know, get on the same ship as everyone else within the CNCF versus let's be the vanguards of security, given it's in our group's name. Do we have a point of contact for say whoever which individual set up the automated, say YouTube uploading and stuff like that, because if that's a process that's easy to replicate with another software stack, I'd be happy to at least get started with that and act on this. That's automatic inside of Zoom. Yeah, but it's not a, I don't think it's exclusive. No. I'm trying to remember which one, whether it's Yeah, I'm trying to remember whether it's BlueJeans or WebAX or something else I've used has it. And there are definite pros and cons to really all of these systems, but we should I think I think it makes sense to at least consider alternatives. You know, especially now given so much more is known, it was Zoom was always something where there was a fair amount known that it was problematic, but it was I think you could have made an argument three months ago that that Skype and WebAX are worse And now I think that would be a pretty hard argument to make They feel pretty equal to me now In terms of reliability, security, usability, adoption, or In terms of embarrassing security vulnerabilities that have been recently published comparing things like the WebAX RCEs and various Zoom vulnerabilities that people have been talking about Well, Justin's comment there on how it might be warranted to run into VM already like that immediately is a red line for me So I'm actually going to start reading more of what he posted after this meeting But these are all really good points I'll just get on board with the the agenda. I should stick to I think everyone's had ample time to hop on board And if not, I'll just keep an eye on the roster there So let's see attendance. Um Is there anyone that we could volunteer as a scribe slash meeting minute taker today? We could use up to two if possible Seems we have at least one person starting to type in the scribe role there. So I'll take that. Thank you, Ray And if someone else is able to ah ash Thank you, Ray. Thank you ash. Perfect. All right. Let's get this underway attendance check-in here Are there any working groups or CIGs or partner groups that have any check-ins today or anything to bring up? I don't see anything in the attendance thus far So we got Campos and uh, michael sports Okay, look like they have uh Updates, okay. I'll just go from the top of us down. So good day, Justin Floor is yours. Hey, uh, yeah, great. Just have a quick update. So um as I I wonder if I didn't check to see if Andreas is on here Whether he'll give an update or talk or anything about the harbor assessment, but that's going along well one thing I wanted to just kind of mention in general that um, I think I'm going to be adding a little more clarity to in the assessment plan documents like the way which you do a security assessment Is to make sure that groups are being very explicit about Like uh, how they handle security compromises and failures I I don't literally mean like a zero day Uh issue here. I could mean this could be something like um an administrator makes a mistake and accidentally discloses a private key Or um, you know, somebody steals uh, like a login credential for a party or things like that And uh to talk about not only sort of the potential damage one can cause in those cases, but also The ways in which you you mitigate them um, because I think that that Needs is one of the most important things and I think can can be missed with our current process So I will add some text to make that more explicit Um, that's all I really wanted to say for the update, but things are going well with harbor and they will likely present Um, I think in something like two weeks if if we're open for them Um, given the scope of the project and things and the fact they've presented a bazillion times to the toc and everywhere else Um, we may send out have them send out something ahead of the meeting To indicate to people. Hey like watch this five to ten minute primer on harbor So you have at least some background. Um, so that we're not spending all the time answering Like very very basic questions about like what is this thing? Um, that's it for my Thank you, justin just justin just a clarifying question. Um, I see in the issue that Um, it's noted for next week. Um, do you expect it to need to you know another week? Okay, no, um, I don't think so I'm not trying to make that that uh that judgment. Um, I had I wasn't remembering whether it was The upcoming week or the week after so I that's why I left it big not because I have I want to Make any uh claim so on the issue, um, you know got it lined up for for next week and I want to make sure we you know kind of Um, give it enough visibility and uh get that lined up It'd be great if we had a presentation since we've had a couple working sessions back to back actually I had a question on that. Uh, justin this is vene Here, uh, you know, what is the exit criteria? I mean, uh, so I think michael had also asked the same question Uh, so at what point does do do we conclude this? Is there some kind of guidance as to Resolving all the comments, etc They're working on resolving comments and they have been pretty diligent about it. Um, one thing that I said in that working meeting on monday and uh, we'll repeat again here for the record is, um Like this is a process that's done kind of when it's done And um, we're not, you know, it's not something where um, there's like, uh, there's like a game clock and we have to Just, you know, stop at that specific time on the other hand because they're being so responsive and have been You know helping us. I think it's reasonable to expect that Um, at least the parts of the document that we've had a chance to see Uh are in reasonable enough shape that they're that they're kind of ready to go that we can make a recommendation and And um, you know sort of say our thoughts about there's some things missing. Um Those actually revolve around the things that I just mentioned Like understanding kind of the blast radius when things go wrong and how to recover and what the implications are um but I But presumably we'll be able to finish um You know, if they continue at the pace they have for and get a set information in the next 24 hours or so I think um, we probably will be able to to wrap it up, uh, but we don't have a We have not yet, uh in the ones that we've completed the two of them that we've completed. We haven't yet had a firm Uh timeline in part because we're still trying to um, you know figure out And different groups have different amounts of time they take to do things as you know, things come up for the security Um assessors and so on so Got it. Thank you Are there any other questions or comments for Justin? Okay, we'll send the mic over to michael schwarz. Good day, michael Yeah, hi guys. Um, can I share my screen? Let me try See we've got your video feed still So I have to kill that too. Okay, let me try sharing. I got it. You have to drop the video just the little share thing Takes over. Gotcha Yep, we see your browser with cncf So so this is just um, I guess the first time I'm I'm presenting to the group I um You know, it was inquiring about Contributing the core glue technology to cncf and I was directed here And I put together these slides. Um, I also I know that there was some formal questions I I address those sort of at the end, but if it's okay, maybe I'll give some background about where we're coming from and You know, some of the some of the goals of glue and then and then maybe at the end or or later We can we can dive into the the questionnaire. Is that okay? Yeah, that sounds about right. I'm just checking here the presentations was this part of um Um Okay, yeah, sounds good. Please go ahead I can send it weirdly. It's not seeing I'm showing in my whole whole screen here Huh, I don't know why so weird zoom thing Um, I'll just stay on the slide doc. Um, so um, so so you might know glue We've been around will be 11 years in may We have the team is very globally distributed. Um, we're on every continent basically except Antarctica The counting the deployments over the years, you know, we're estimate around 3000 deployments and The business model for glue is we sell support on the glue server And we have serving mostly large enterprise customers around the world. So there's 50 enterprise customers um good partner network And anyway, so that's a little background about us um The glue server so what can be confusing to people is differentiating the glue server from its components So the glue server I tell people it's a little like red hat You could think of red hat as a distribution of open source components Some of which red hat wrote some of which they didn't but they're integrated together Given a version supported for years. So it's productized and the glue server is like that So it consists of a number of different products Um, and that's our commercial product the glue server And I'm not proposing that now that product some of those products are You know conducive to be made cloud native some of them aren't but I'm not proposing that we make the glue server That we contribute that to cncf what I'm proposing is that we contribute What what is really the core technology of glue, which is the oauth Open id Fido part of glue. So really the the cutting edge part of glue As as a new project at cncf So this isn't where we are today, but this is where we're moving to So the the core oauth service Um The phytoservice, which is currently integrated into the oauth service, but we think we can break that out um a skim service, um, which which is currently in our admin component, but we think we can break this out and a config service, which is also currently in our admin service, but The basic idea is you know different components for um, but the oauth service is really the one that drives most of the functionality and the performance So just sort of a high level vision And now now the glue server If you look at the the market for access management There's a lot of solutions out there and we have very specific segment that we're serving and It's always been the high end of the segment We felt like the low end of the identity segment is well served by SaaS services like octa and So the design for the glue server was always to be really fast Horizontal scalability was an important design goal from day one Low operating costs So customers or who deploy the glue server They'd probably rather use a sass like octa, but they can't But given given that we were even though They might prefer a sass we want to focus on making it as easy as possible and keeping their long-term costs down Because operations just goes on forever and it ends up being the biggest portion of your total cost of ownership So we always focus on low operating costs Flexibility was really important to us It turns out that you'd think authentication is like everyone does the same But it turns out that everyone's authentication business logic is a little different And we wanted to make sure that you could implement your business Rules without forking the code forking the code means makes it hard for for end users because They have to merge their codes Merge their updates and it makes it hard to keep current with the latest version So we created sort of interfaces that allow you to customize the behavior of the glue server Without having a fork and there's currently like 14 of them. We're adding a couple more Um, we have a loose persistence to to the persistence layer So a lot of the performance of glue is driven by the database that it connects to Um, initially we built glue around LDAP like most of the other access management platforms out there um Two or three years ago. We decided to implement another database. Um, we chose couch base In the future. We actually on the roadmap this year. We're looking at supporting amazon Maybe dynamo db is is what we're thinking But but basically there's an abstracted persistence layer and caching layer so that we can implement different persistence backends We've always had a test driven development strategy So you have to you can't submit features unless you submit the the corresponding tests And as a design goal when glue started in 2009 There was probably like 20 other companies or organizations that had a SAML product So we always said we wanted to be the best in the next thing which in 2009 was oauth and open id So we've made a big investment in sort of um being on the cutting edge and really being innovative In in the oauth area Um, so a little bit of a spoiler. We just put out this press release yesterday And it's showing uh, we basically did a benchmark where we started one morning And we spooled up enough servers to to to show a sustained rate that would get us to a billion authentications per day And when our competitors do this they tend to do You know, they tend to hit the back channel endpoint and send the username password and call that an authentication But what we did was actually show how do you scale the web tier because in open id You're talking about presenting a web page Processing the you know returning the code trading the code plus client credentials Getting a token hitting the user info endpoint. So we looked at the whole web-based open id flow not just sending the username and password and calling that an authentication and how do you scale that to A sustained rate of a billion authentications per day. It's a pretty hard problem I did benchmarking for rack space We were trying to achieve this. We never could with LDAP based infrastructures Or if we could it was only by using proxies Which were really hard to scale up and required a lot of operational expertise in terms of how do you manage the database We were able to do this test basically because of advances in cloud native technology and Advances in the persist in scaling the persistence But there's no other I don't think there's any other commercially available system that can do this Other systems tend to show how they could maybe scale But they can't scale like they can't autoscale to get to this rate I'll go more into the benchmark results later on But but just to give you an idea So in terms of the quality of the implementation glue has always been a leader in the Interop testing Before there was open id certification. There was the interops These are results from interop for that shows that glue. This was from 2013 january So glue was actually leading the interops in open id connect Before companies like ping and ford rock even had a server So we were pretty early on leaders in open id Today you can check the certification page and see that you know glue 4.0 We submitted all the test we're passing all the tests We are also we have login tests which happens to even be published. We're ready to pass those and submit those We submitted glue We to the there's a fappy open id provider set of conformance profiles and glue 4.2, which we're about to release is Passes both of those so clues a very comprehensive open id connect implementation I would also say that these tests are like the bare minimum of what you should be doing You could drive a truck through what's not in these tests There's a lot of missing negative tests also So I would say in my opinion these tests are the bare minimum of what vendors should be doing We're also the only implementation to recertify four times It's important that when you make a new release you're according to the terms of service. You're supposed to recertify and we've done that But we're the only implementation to actually recertify four times I think we'd be the only one to recertify three times even So going a little bit into what's in there In the open id connect we implement basically all of all the different You know features including Dynamic client registration Which is actually a pretty important feature For automation of managing clients Discovery is the configuration endpoint Front channel back channel logout Siba is a new open id profile that is used for call center push notifications to mobile devices So if you call at your bank and they want to push a notification to your phone There's a new the new open id standard for that. That'll be in 4.2 There's also a certification that we expect to pass in 4.2 for that Quick question michael sorry to tell you I should ask this at the beginning Do you want to tackle questions as they arise or do you prefer to shelve them all for the end of the presentation? um Let me let me Feel free to put the compressions in the zoom And I'll tackle them at the end because they might be answered along the way Got it. Um We implemented actually glues the most comprehensive implementation of this profile called uma user manage access um It's actually um, we're one of four implementations that that supports this profile But we're the only implementation that implements the authorization endpoint In oh, there's two endpoints. There's the authorization endpoint and the token endpoint Token is back channel authorization is front channel Glue is the only one that actually implements the front channel endpoint, which is critical For use cases where you want to get consent Like in gdpr the european privacy regulations. You might want to get consent from a user To call an api on their behalf You might need there's also use cases in the health care industry for consent to medical records Stuff like that. So we like uma especially where Consent of the user is needed After authentication happens and you need to go back to the to interact with the user We love fido. Um, we've built a fido into the glue server. Um, including u2f and and fido too We actually um, maybe this is a little bit of a non sequitur, but we um implemented a skim endpoint endpoint for fido also Because one important question becomes okay. What happens when you lose your fido token? You need some way to to unassociate that fido token from the person So in addition to the fido endpoints that are defined in the spec We also have a skim profile for fido. Um, that is conducive if you want to enable user or A user self service portal um to allow users to say okay those tokens are really small Eventually, you're going to lose the thing you need to handle that Um, I mentioned skim Um, we have a very comprehensive implementation of skim Um, we did interops with sale point and paying and others Um, this has been in production a long time skim2 is actually pretty standard if you don't know what skim is It's basically there's a slash user's endpoint and you can post to add a user Put our patch to edit a user But glue has a database with user information in it And this this is one of the ways That you can get user information in there and probably the most scalable way Um, so a little bit about the architecture. Um glue the glue server is written. It's built with the weld platform We we like the stability of this platform And um and and glue has a lot of code So we're we're using it extensively Um, let me just say a little bit more about um, well I think I have some another slide later, but so we actually are I mentioned it Somewhere, but anyway, yeah here. So we're we're looking at other platforms For the smaller services the phytoservice the skim service the config service for those services We can use lighter weight Like corkis is what we're looking at but there's for for these smaller services. I think it's okay But there's some for the for the core oauth service Even though it might be You know larger than we might like We still feel that the stability is really important for us for this kind of product We we need the stability And we think it's been serving us well. Um, there's been a lot of features in here that we like We deploy in a jetty server container. Um, so we don't require An ejb even though it's weld. Um, we don't we don't need a An ejb server like wild flyer or something like that And we're we're actually using the amazon JDK Is what is what we're using? We've you're probably all familiar with those issues, but Um Okay, so persistence glue does a lot of persistence. Um, you wouldn't think so but users clients Some types of tokens like um, like long live refresh tokens Those types of things need to be written to a disk and those And and that ends up being the barrier for performance Um is write operations and replication ends up being really an important driver for When you want to scale and so We have a and as I mentioned an abstracted interface That allows us to maintain different different back ends LDAP and couch base for us supporting back ends is a big deal because it's not just doing the mapping It's also, you know, doing enough performance testing to make sure that we have the queries optimized and Everything else about it the operational replication. There's really a lot to it. So before we take on a new database It's not a trivial undertaking We're targeting dino db dynamo db The We know a lot of our customers don't want to be in the in the database management business at all They really just rather like use a cloud database So we're looking at that rdbms has been a no-go for us We'd actually like to see an rdbms for smaller applications But because of issues with replication And scaling it hasn't been a priority for our use case which is performance and horizontal scalability Caching is really important also actually So we support a number of different cache models Couch base has memory buckets This is good when you need multi data center replication of the cache We also support redis and in memory We support database caching which might sound like an oxymoron But it it eliminates the need for the cache because we can use the database for replication So in cases where maybe performance isn't needed and you want to simplify the number of components You can actually specify the database instead of instead of the cache Um But um, but man, but there's some data where it would kill your performance to write it to the disk like the code and the authorization code flow It's only you should be used one time. So there's just no point in writing it to the disk Um, so for those types of like short lived objects, we need to use the cache Um, there's pre authentication state. There's a number of cases where it's not just the persistence You need to think about but also the caching Um I mentioned the interception scripts before as a way to an upgrade friendly way to implement Um business logic. Um, the scripts are written in jython um, the we we we are um Have shied away from java Having worked, you know for 10 years before I started glue. I work with every SSO platform out there that was available at the time And I felt like java was a big barrier to system administrators And so our goal was even though we love java glue Was to expose an easier interface for customization. We chose python as the syntax We could have chosen javascript or groovy, but we chose python partially because i'm a big python fan We used jython because that's that was the java implementation of python that made it easy for us to implement In the future, I think we might actually Enable in these interfaces in pure java We're that's on our feature wish list But these jython scripts have served us well and have enabled our customers to implement lots of crazy like You know use cases that we never thought possible Like i've never heard any customers say I need to do this with a glue server and I can't We've seen all sorts of like very creative implementations Of glue to get to get various use cases done Out of the box, we still have a lot of two-factor support social login inbound SAML phyto authentication, which I mentioned one time password sms x509 certificates I have a link down here to even more Reset your password after 90 days. You know try these two LDAP servers on the back end call this api. There's basically like lots of Different ways you can implement How the user gets authenticated There's lots of other interesting interceptions grips introspection Oauth token introspection is one that's used a lot when you want to add scopes or otherwise stuff other information into the oauth token client registration If you want to use software statements To as an alternate trust model to lock down dynamic client registration Maybe it's too open for you. So there's just a bunch of ways you can implement these scripts to meet your business model Okay, so there's actually Oauth is a big topic if you look at the oauth working group at the itf you'll see there's like I think 18 rfcs there's a probably like another 10 draft rfcs at least So oauth like LDAP is a bunch of specs, you know related Oauth is the same thing. It's not just rfc 6749. It's actually the whole a whole bunch of these related rfcs that have come about to promote best practices and also to mitigate certain vulnerabilities of oauth that have been discovered over time Glue we we implement pkce. That's a really important one And anyway, I don't want to get get go into the weeds too much, but it's a pretty good implementation So One of one of the important directions we're going at glue is to align with cloud native design principles And in fact, we currently have two products one we call community edition, which is based on vms That's actually going in the direction of snap We currently have a churrut, but we're we're beta testing snap, which is a new distribution packaging strategy For customers who aren't ready or don't have economies of scale to go cloud native But for our larger customers, especially consumer and citizen facing applications We're really pushing customers towards our kubernetes helm distribution of glue And anyway, we did a quick chest checklist to see, you know, how we're aligning with some of these principles You can maybe I don't want to go into too much detail here, but you can you can check it later We have a huge effort on kubernetes year years long effort in In and and even before kubernetes was out. We were looking at how to Use orchestration for example, some of you might remember juju We tried that we were we were trying basically we knew we had this autoscaling problem Before juju we were looking at platforms like puppet and other configuration manner We we knew we had to figure out some way to autoscale kubernetes really solve those problems for us Once and for all But not without a lot of work Years of work Partially because as you know the platform itself was changing a lot as as we were innovating there'd be new versions of everything It was really a lot of work but after after You know Two and a half years or so. We really have a pretty solid kubernetes Helm distribution of the glue assets each service running in its own container All of that is open source And if you go to glue.org slash docs, you'll see there's kubernetes installation But this gave us really the the autoscaling we could not otherwise achieve no other platform enabled us to do it The the automation the failover you guys are already drinking the kool-aid. So you know the the advantages Um So I mentioned before on the benchmark results actually in the press release there are our instructions on how to replicate our benchmark And um, and we actually we we actually did benchmark both the resource owner Password credential flow. This is basically where you're just sending the username password to the token endpoint and asking for a token Um, we also benchmarked the authorization code flow but this is um Again, um in the press release. There's a link In the glue docs. We actually documented how to achieve these results. I believe that for the for the code flow It took almost 500 glue server 500 servers. There's no way you're slowing up 500 vms to do this so So you really need the scalability and we do think that actually this scalability What was previously only available? Like sure google and microsoft and octa and ozero. They can do this Um, but you can't license their technology stack for authentication Uh, or not even license. You can't deploy So we really feel like this is the first Sort of stack where you as a cloud provider can say I need to authenticate Like google at that scale and here's a recipe for for how to do it um, so in talking with um, some of my friends at linux foundation um If we were to contribute the core glue technology it has to be rebranded um, now we actually have a separate open source and um Um and commercial brand so the the the the open source stuff at glue we've always we've always had prefix at ox So there's ox off. There's ox trust. There's ox d But we decided actually we can go we can go further and maybe break and just come up with a totally new name Um over the years. I've gotten complaints about ox off being impossible to say for french speakers um, also I'm not sure. I love the metaphor of an ox being a castrated male cattle So, um, so i'm up for so we're up for changing the name I'm suggesting a new name. We're named after racing pigeons the fastest racing pigeons on the planet Um, we're bred by these guys janssen. So janssen racing pigeons are Are sort of the known for being the fastest pigeon in the world. I'm proposing that as a new name um, I have some more, um Um, I have some more comments that specifically address. Maybe I'll just leave these For people who are reading offline because I don't think I want to read this much text. And let me take the questions um, there was just actually a Um, a release for jython Um that um, so there is a there was a new Jython release that we're integrating into 4.2 You know, we are you know, as I mentioned, we are looking at other interfaces For example, just exposing pure java as an alternative We try not to be paternalistic at glue and realize that our customers have a range of security requirements Some of them are very paranoid like the the navy is a customer of glue the us navy um, and and well others of them are In other areas and using the glue server for other things where maybe they're not quite as paranoid and so So I think that um, it's important to remember that um securities about mitigation not about perfection and the extent of mitigation That we want to leave that up to um, we want to make good default choices for the customer, but we also want to leave You know some Flexibility to the customers to find the right security Profile that that meets their needs Um, this is especially true in open id Where there's lots of signing and encryption options and we're not saying you have to use them all We want to make them available to you and then let the customer choose So the question about jython and python 2 7 You know potentially you could map other scripting interfaces You could do jute groovy or javascript. We had that idea in the past I think for the for how these things are exposed and compiled I I think it's okay I'd like to see what is the attack, you know that we're mitigating. What's the likelihood of that attack? So I think that just just saying sort of need jerk We should get rid of this But um, yeah, thank you. Those are the slides. Um, you know, it's maybe premature It's something we can look at but um The other question is let me just read it. How many enterprises are in production with the core aspects being discussed today? So Well, I said around 50 I mean almost all the glue customers have to be using this core feature You can't use glue without using this open id connect component The SAML components are chained. So when you do a SAML authentication, we actually redirect you to the open id connect Provider to be authenticated and send you back to the SAML idp. So there's no way to use glue without using this portion of glue And so we do have a commercial product called cluster manager But this isn't a cloud native product. This is only for VMs. So there's two cluster strategies at glue There's kubernetes and helm which is open source And then but it's what some of our customers aren't ready for cloud native or they don't have economies of scale Or they can't they don't have an elastic kubernetes service available that to them and they don't know how to build one And so we have another distribution of glue using Linux packages And if you're using these linux packages, we have a commercial product called cluster manager Which is a deployment tool that helps you that makes it easy for you to deploy A highly available topology of glue servers It's not used at runtime. It's just a deployment tool. But that tool is commercially licensed We actually document how you can cluster glue In the documentation. So there's no secret about what cluster manager is doing But I also say, you know to the open source business people out there Just because your product's open source doesn't mean that everything you write has to be open source and this tool we figured saved customers a lot of time Created commonality across cluster deployments for this VM distribution and we felt like it was fair game to license it But so there's no I wouldn't say that clustering is commercial kubernetes clustering is is that's built in and free You can cluster it. You just can't use our you know cluster deployment tool to cluster it That makes sense Let's see I think there's still A bit confused about which parts of our Software is commercial or not kubernetes in general The the setup of kubernetes with glue is not commercial the cluster manager Is is using VMs. It's nothing close to what kubernetes does On the cloud side. So it's it's not even They're two different tools kubernetes and that deploy and the deployment that it brings to glue is all Open source and you can you can just follow the docs on how to install that There's nothing commercial about that and that's what we use in the press release. That's that's how we reached the scale We didn't use cluster manager for that right Also, keep in mind that what we agree to support like the software the the binaries The documentation that's all open source, but that doesn't mean we have to support you Glue does a lot of community support You can look at our support forums and we have a whole team that does nothing but community support We find that actually supporting clusters is an enterprise requirement And and plus we would need to expand our community support capability and we feel like We can't support the world, you know, we can give you everything we can document it, but But we are what we choose to support commercially The community can answer other community questions about clustering, but But we don't feel like we have an obligation to support And it support is what we sell and and so there has to be a business model that's our business model and We we we want to support. I always say, you know open source. We're not a charity for big businesses We give a lot of free software. We do a lot of stuff for free We also have to figure out some way to fund all that good stuff And and the and what we sell this support There is no So glue is not open core There is no enterprise version Or or community version. There's just one version of glue There's one specific tool cluster manager that's licensed And as as we said about four times that tool only relates to vm deployment. It's not you would never use that if you're using kubernetes So everything at glue we don't believe in open core because we believe that that creates A bad incentive or it creates a conflict of interest with the developers Where developers are saying well, what should I work on the enterprise features or the open source features and the enterprise features End up having more priority So we didn't want to create that bifurcation of of motivations at glue. So there's only one version of the glue server But um So it it might not be as clear on the marketing but There's really If you look at glue not only is the glue server open source But glue gateway or our api gateway based on con community addition. That's open source our plugins are open source Super glue our mobile app is open source also our client software oxyd and one of my missing Casa our two-factor credential of application all open source However, we're just we're not talking about those those projects. Those are separate projects. We're really just talking about The core oauth open id service in glue, which we think is the most relevant to the cloud community I like this last question about What do we want to get from cncf membership? Well, we want to build the community for glue That's that's the main reason is So we've done a good job. I think getting the product to where it is today Um but in order for We think it would be hugely advantageous to us if we could attract a bigger community to collaborate with and the cn and by Aligning with the governance model of cncf and making Glue is pretty stable at this point. You know, we've implemented a lot of features. So At this point we we think that if we could formalize How features get added to the glue and create a more consensus driven approach to to that process We see collaboration opportunities with other cncf projects In particular, we already have an integration with opa In our gateway product, but we really are big fans of the declarative security model of opa Also, we like falco A lot of our customers Need a multi-tiered security approach and having falco To monitor sort of the kernel level Events to detect anomalous activity. That's really interesting to us So we're excited about some of the other projects But the main over our writing goal for us is, you know There's actually a number of large organizations that we're working with today that would Like to collaborate on the glue server more closely and moving Glue the the core technology out of glue the company and and into a foundation Would provide some assurances and every once in a while I mean, we've been committed to open source for 10 years But every once in a while we still get, you know Questions about what if somebody buys glue, you know, what if you decide to unopen source? So we think that moving the core technology to a foundation would eliminate some of those questions and also Enable some of our partners Like idemia who's mentioned in the in the press release They're a very large publicly traded identity security company So the glue is very tactical for them Evernote who's I mentioned in the slides later on is one of our customers They're they're deploying glue at that scale And also service Other companies who want to launch their own octa So we have a number of partners globally Who want to launch a hosted identity service based on glue and so moving moving glue to cncf We believe would create a more Would create the governance structure Which would enable us to collaborate with a larger ecosystem of developers I'm going to jump in just quickly michael 1054 i'm just going to call it up in one more minute just for okay Thank you, michael. Uh, we Got a number of questions that michael's gone through here if there's any additional ones We can just post them or reach out to you afterwards presumably With the last michael Yeah, um Just a clarification on jensen versus glue Um, you know as you're going through this, uh, I'll be honest disentangling glue the company glue server and all the various components You know to you know figure out, um, you know which aspects we're advocating for You know lots of setup And i'm not sure you know besides you know just being able to say, uh, it's the oos part You know not having a Uh a focused project to focus on Is really hard. Um, so, you know, is it is the correct understanding that jensen would be That circumscribed oos componentry That you're considering Uh, you know bringing into the cncf or is that uh, you know the glue server that Is open source, uh And you know the name going forward. Yeah, so so the closest thing that we have is really ox off Um, that that's our core oos Fido component today. Um, so we're really talking about renaming that jensen Um Breaking out the fido and fido is only like a couple of end point It's not a really big part of the glue server But we don't want to hold back innovation of fido for new versions of of the oos server because fido is Perhaps on a could be you know if we have a new fido release Maybe we should don't have to wait for the next release of oos. So we want to decouple these things Um Really you need a config service. We already have a config api, but we're breaking that out Into a separate lightweight config api and the skim service likewise also exists, but we just want to break that out So these are the four you need the skim service because you need a way to add edit delete users in the glue server You need the config service so you can automate not just deployment, but also configuration of the glue server And fido and oos we see as as as core services So this is really this bundle of services is is what jensen would be But oxoth today has oos and fido And our ox trust has skim and config so we but So basically we're we're actually doing this right now is we're breaking these guys out And we will bundle this all as one new project called jensen Thank you, michael We have a couple minutes left for open floor. Does anyone have any additional topics they'd like to bring up and If there's any additional questions for michael michael, can we reach out to you via the ticket number 366 associated with this presentation or Absolutely. Okay, perfect Does anyone have anything else they'd like to bring up in the last few minutes before hard stop? Okay, 10 seconds of cricket says no No, they're from mike. Thank you mike and thank you for putting on this presentation today and With that I think we'll call it a stop and hope everyone stays happy and healthy Thanks, everyone. Thank you Thanks. Thanks Matthew. Cheers