 We'll welcome everybody to this OpenShift Commons briefing with Tremolo Security. We're going to get the inside scoop on OpenUnison, an identity management open source project that Tremolo Security is backing and has been working on. I have with us today the CTO of Tremolo Security, Mark Horsstein. And he's going to introduce himself and his topic. And we'll have Q&A in the chat section. We'll try and do the presentation and the demo first, unless something really pressing comes up in the Q&A and stop him from rattling on and interrupt him. But otherwise, what we'd like to do is have the presentation for the first 20 or 30 minutes and then do Q&A right afterwards. So try and get your questions into the chat and I'm going to let Mark introduce himself and his topic today. And thank you again, Mark, for joining us. Thanks, Diane. So like Diane said, my name is Mark Horsstein. I'm the CTO of Tremolo Security. Real quick, I want to talk about who we are. We were founded in 2010, built on the experience of our co-founders. So I started off as an engineered octet string now owned by Oracle and have been an open source developer pretty much my entire professional career. In fact, I got my job at octet string based on an open source project that's now part of Open LDAP, the JDBC LDAP bridge. And then over the years have been a consultant and contractor, different industries, different products. And so my co-founder, Brian Bullock, who wasn't able to make it, comes more from IT security background as opposed to the identity management background. And again, consultant and contractor. And so what makes Tremolo a little bit different from other identity management focused companies is that we're built on years of experience, 20 plus years combined. I'm not going to go through all the different bullet points here. But what we found was going through all these different deployments, some real common things, applications which really rely on this identity data and are what drives the business are often the hardest part of integration and figuring out how to do that integration. And that we wanted a lightweight system instead of having a large monolithic system that you spend most of your time trying to massage into what you need. We wanted to give you a set of building blocks that are small enough pieces that you can assemble into what you need. And so we want to have a very modular system where if you need use a provisioning, you can use it. If you need SSO, you can use it. If you need an additional data store, you can use it. But if you don't need those functions, you don't need to add the extra infrastructure to support them. Additionally, we go with a virtual directory approach. So I started a project called My Virtual Directory back in 2007, I believe. And that's really at the core of Open Unison. And so what that allows us to do is to connect to a whole range of different directories and be able to do things in a way very quickly that a synchronization based identity management platform might not be able to do. And then finally, we're open source. Today we're going to be talking about Open Unison, which is our open source project. What we did was we took Unison, our commercial project, and we took out the, I don't want to say core because we're not open core, but the functional piece. So the piece that does the SSO, does the provisioning, does the reporting, provides the web services, all the functional aspects. And we migrated into a generic J2E application that you can deploy on Tomcat, Wildfly, Jetty, pick your favorite. And so that's what we open sourced. And that's what we're going to talk about today. So before we kind of get into Open Unison, we want to talk about what makes identity management hard. The first question is authentication and SSO. Most applications, you've got users, you've got an app, whether it's J2E lamp or even .NET, and you got a database. And that's easy enough. But how are you handling your users? How are you handling your groups? And how are you authenticating users? Well, you know, put the user in the table, put a password in there. If you're really savvy, you can go ahead and hash it up. And you're good to go, right? Except you're in an enterprise environment, and so there's Active Directory. And there are policies. You've got to have, you know, passwords have to reset every 90 days, have to have a certain complexity. And you don't want to start handling that inside your application. So you're just going to talk to Active Directory. And, you know, most application platforms have a way of talking to Active Directory, so that's kind of easy. Except for the fact that since 2000, Microsoft has been telling everybody to break up your Active Directory infrastructure to multiple forests. Now, if you're living in a Microsoft world, this isn't that big of a deal. It all just kind of automatically happens. But in a non-Microsoft world, you have to know how to talk to those different directories, even their cross-forest trusts. That's not the same thing as a virtual directory. You still need to know how to talk to them. And so now you're starting to build a lot of logic into your application. You might look at something like a SSO system. You know, a lot of commercial ones out there, a lot of open source ones out there. And so somebody says, all right, we're going to stand up an SSO service. Most SSO services know how to talk to multiple directories. So it makes life a little bit easier. But here's the catch. You've got this line here between your SSO service and your application. You know, is an agent, you know, is your application, you know, if your application's in a position to use modern technology like OAuth2, OpenID, Connector, SAML, you know, that might lessen the burden. But if you're using an older system or a caught system, that might not be possible. And so you have to use the vendor's agent. And now the question becomes, okay, if the agent's broken, is it your application's fault? Is it something your SSO team is doing? Who's going to be doing the integration? And so, and from a DevOps perspective, you want to be in a, you know, branch develop merge, branch develop merge, not branch develop, wait for an agent installation, debug it, figure out what's wrong, code it, merge, move on. So that's one of the first aspects that makes identity management hard. The second aspect is, okay, you can SSO in and we've got that problem solved. And a lot of enterprises do. But now the question becomes, who should have access to your application? You know, there's really two aspects of that question. It's the ability to add users so you can onboard them quickly. But it's also the ability to provide a report to auditors, especially if you're talking about in an enterprise where you have Sarbanes-Oxley, HIP, other types of regulations that you need to worry about. And so you want to be able to provide a report that says who has access. Well, you know, your application, if it's using a database, you know, kind of standard model, users groups, you link them together with the table. And there are variations on the steam. So for instance, WordPress does it a little bit different. Drupal kind of goes with this. SugarCRM has its own model entirely. But, you know, you can always do reporting off of that. But the problem with that is it's not centralized. So, you know, maybe you want to work off of a directory. Again, you know, maybe you've got somebody with some LDAP skills, or there's a web service you can use. The big downside with going a directory is there has to be a directory, right? So the question becomes, who's directory are you using? Are you standing up a new directory? They're a central directory. Maybe you're using Active Directory. Active Directory might make a lot of sense, except for the fact that the folks who manage your Active Directory are a lot more worried about Windows workstations than they are about your app's authorizations. And then the applications can cause some issues. So, for instance, AWS integration that we're going to show. And yeah, build this funky string and send it up to the application. Depending on what your identity provider can do, that might be real easy to do on the fly. Might not. And so, you know, you might be storing this as a role, well, or an attribute somewhere. Where are you storing that attribute? And then finally, how are you going to report on all this? How do you generate a report that says Mark has access to these roles? This is the reason why he has that access. This is a person who approved that access. And this is why it matches with our corporate policies. Finally, you take this, and the great thing about OpenShift is that it makes it really easy to build applications. Kind of the, not downside, but one of the things that Sprawl now creates is that this process now gets repeated for every single application. And as you go through catalogs of especially open source applications, but also commercial applications, you'll find all sorts of different methods for doing identity management. And so, providing a central system to be able to do that identity management can really provide a boost in your development life cycle. Because now you're taking away the need to manage those identities in the same way. And you're also providing that central reporting function to get the auditors off your back. So, has OpenUnison helped? So, first off on SSO, we have a lot of SSO and authentication features, stuff that you'd expect using password, federation, we do an IDP broker, multi-factor using TOTP. We also have integration with Symantec Vip. And then some ones that you might not expect, we have a just-in-time provisioning provider. So, as the user comes in, we can create them on the fly. We have banner authentication. You know, I shall do no harm, I promise, when I come to enter the system. We implement that as an authentication mechanism. Oh, and also on the SSO system is our application integration, which really is, I think, one of our biggest strong suits. We run as a reverse proxy for the most part. And we have multiple ways of doing last mile. We could do header injection, but kind of the biggest issue with header injection is there's no way to validate it. It's just some text. So, what we've done is we've created a last mile token system that integrates a attribute, not before, not after, and a not, and gets encrypted. Oh, and the URL that's been authorized. So, that gets sent down to the downstream application. Then we have integrations for Apache.net and Java and multiple Java application servers that will validate that token and set the context for you. And there's no phone home the way you get with an agent. So, we don't call them agents for that reason. And so, that gives us the ability to, since we're cutting out that network hop to validate a cookie, to be able to validate every request individually. And so, what that actually allows us to do is have a set of trusted attributes coming from the reverse proxy. We've also recently had the ability to do Kerberos constrained delegation. So, if you have an app that is set up to only support Kerberos, we can generate a Kerberos ticket that it will accept using protocol transition and allow you to do SSO without any component integration. Now, for authorizations, we have a lot of different ways to do authorizations. Just kind of your standard directory, groups, dynamic groups, filters. We also have a custom authorization mechanism. So, the ability to write a rule that requires a little bit of logic in your authorization path. Examples of custom authorizations, we've built supervisor authorizations. We've built that as a custom authorization. So, your supervisor must authorize you to be able to do this, or your supervisor's supervisor must authorize you. A couple of different variations there. And then finally, we allow you to do reporting on this. We've got a very simple database. It's relational. We're not right now doing anything with Mongo or other object databases, but it's a published schema. So, we provide a simple reporting interface, but there's no reason you can't use whatever your favorite reporting or business intelligence system is with this. We've got customers using Jasper reports, but there's no reason any other reporting system could be used. So, now for the fun stuff, the demo architecture. So, what we've done is we wanted to set up a demo that showed off a lot of Open Unison's biggest benefits, especially to OpenShift. So, I've got OpenShift origin latest running here in my lab, and I've got two applications set up. Now, I'm going to be spending a lot of time on this particular slide because when I actually do show the demo, it's a really good identity management demo is wholly unspectacular because things just kind of work. You don't see the identity management happen, but there's a lot going on behind the scenes that get automated for you. So, first off on the left-hand side here, I have Active Directory, and right now I only have one Active Directory force set up, but there's no reason why this couldn't be three, four, five Active Directory force, whatever you want to see. I think the most I've ever seen in an organization is eight individual forests. Organization had one set up for each individual continent, a big global company, but no reason why we couldn't handle that. And so, this is going to be our source of truth for identity data. So, this is where you're going to get your first name, your last name, your email address, your ObjectWid, and your display name. Now, ObjectWid is an interesting one that is your unique identifier inside of Active Directory. It's a binary attribute, but it's one that if you can turn it into text is really useful. So, one of the benefits of Virtual Directory we can do data manipulation, and one of those manipulations we do is convert the binary ObjectWid attribute into a text-based ObjectWid attribute. Makes it a lot easier to use in other applications. So, we've got two applications set up inside of OpenShift. The first is what we call our IDAS, our identity as a service. So, we've got two pods. We have an open unison pod that handles authentication. It handles the web services for provisioning that we host. And it's also acting as a reverse proxy for scale, which is the application we've built to use those web services. And finally, it's also acting as an identity provider. It's using database data from an external MySQL server. And then it's also storing its configuration data on an external NFS server persistently. We also have scale. Like I said, that is our open source. It's a set of applications really, but the main app is the one that we've deployed that leverages our different web services to provide an identity service. So, when a user logs in, they will be able to request access to applications, see a dynamic set of links to be able to log into applications, update their profile if they wish, view reports, et cetera. And then over here, our second application is where we have WordPress. So, we've got another open unison instance. This one is primarily or is really responsible only for SSO into WordPress, and for just in time provisioning into the WordPress database. So, there is no extra database or directory here with this unison instance. So, like I said before about being modular, we're not using the different services that would require an external data store. So, no need to deploy it. So, again, we're very, very lightweight. And then we have WordPress instance. This is the stock official WordPress instance off of Dockerhub with the addition of our last mile integration for Apache. So, what will happen is when a user logs in, all the bouncing mouse, when a user logs in, they're gonna hit open unison. Open unison doesn't know who they are, gonna request you to put in your username password. Now, we have chain set up. So, this could be a username password, this could be federation of some kind, any of our different options, at which point the user will put in their username password, and a login will happen into Active Directory to validate that credential. Now, here's where the virtual directory comes into play. We're storing our authorizations down here in this database, but in order to make it recognizable, we need to be able to merge that data with what's coming from Active Directory. So, the first thing we do is we do adjusting time provisioning into this user database. So, that will provision just the user's UID or SAM account name in AD world and objectWID. And that's what we use to link the account into Active Directory. Then what we do is all directory operations go through a joiner. That joiner creates a profile based on the Active Directory attributes and the local data attributes. So, if we need to add additional attributes not managed by Active Directory, we could do that here and provide it without issue to applications. So, at that point, we go ahead and we're gonna get SSO'd into scale using the last mile system. Quest comes into scale, which is running on Tomcat 8. We've got a valve that's running that will validate the request and set the user context. At which point, web service calls will come into Unison to be able to load your profile, what you have available, et cetera. So, user's gonna request access, that access gets approved. At which point, they then log back in and they'll see a couple of links come up for the different applications that they've requested. So, let's say we click on the link for Amazon. That'll bring us to the console. Before it does, though, it's going to translate our internal groups into that crazy string that Amazon wants. So, we're getting the best of both worlds. We get to have a consistent way to manage our groups, but we also get to tailor things to the way applications need to see them. If we come back and we click on WordPress, this is where the application integration really becomes powerful. Click on that link to WordPress and a SAML integration starts with this application, the Open Unison over here. So, an assertion gets digitally signed, sent through the user's browser down to Open Unison in this application. Open Unison validates the assertion first off and then based on the attributes in there, we'll run a just-in-time provisioning workflow against the WordPress database. So, if you don't exist, it creates your profile. If it does exist, it makes sure that your profile matches what's in the authoritative data source over here. So, this provides you the ability to get both a centralized way of managing your data but not having to recertify that access on a consistent basis. It helps eliminate a bit of that risk between recertifications. Now, the practical side of that is, let's say I have subscriber or contributor role and administrator tries to make me another admin for some reason through the WordPress interface. Well, that's not gonna work. They'll make me an admin, but then the first time I go to log in, I'm gonna get reset back to contributor because that's what my role is here in the authoritative source. Once that happens, so the data is set here, WordPress is kind of an interesting application because it's not necessarily designed to always have to be authenticated. You really only have to authenticate if you're gonna do things that are authenticated but because this is a enterprise deployment of WordPress, we want users to always be authenticated. So, before you actually log in, before we send your initial request to WordPress, we do a pre-authentication. We have the ability to manage an internal cookie store inside of our reverse proxy. And so what we actually do is we go and we do a login to WordPress behind the scenes. Response comes back, we take those cookies and inject it into your cookie jar. So that way, when you hit WordPress for the first time, you're pre-logged in. So there is no quote unquote anonymous access to WordPress. So like I said, that was a lot. And we'll go ahead and go through the demo and actually show kind of how that all comes together. All right. And Diane, can we see my browser? Yep, looks perfect. It has origin all over it. Okay, cool. So this is my origin deployment. Here are my two applications real quick just to show you there's nothing up my sleeves. And then we've got two pods. Each pod has its own set of services and potentially a router if it's an external pod. And then the same is gonna be true here of scale. And we've also got everything's configured through the environment variables. So there are no passwords, no certificates, nothing's being stored on these images outside of application logic. So I'm gonna go ahead and log in. So the first thing I'm gonna do is log in as mMosly. Now, customizing these pages is very easy. It's just stock JSP. And so I'm logging in. And so that background process is happening where I'm talking to Active Directory. I'm coming back. I'm checking to make sure that my object exists. And this is kind of my super user map Mosley. So he has a lot of capabilities, a few of which are going to be, you'll see that I've got links. These links are dynamically generated. And then I'll also show you that, oops. Ah, I'm back here. Gonna show the responsiveness here. So this is built on Twitter Bootstrap. So it works great on mobile devices. And it's generic Twitter Bootstrap. There's nothing, there are no special themes put on top of it. So we've got a couple of apps. If I wanna come in here, here's my profile and roles. Now, I've got it set up right now for read only, but we can also configure this to show certain attributes as read write and then execute a workflow. So that would save it. So let's say we want to let users specify their Twitter handle here for some reason. We could add a Twitter handle attribute and when the user hit save, execute a workflow, they'll write it to the local database that we're using. And then any application that wants to access it, now can without having to store it in Active Directory. And over here in the reports, we allow you to build out an organization model, totally arbitrary, however you wanna set it up. One of the things that we let you do though is we let each organization have authorization rules on it. So for instance, this identity management reports, you have to be authorized to access. So some of these different reports that I'll kind of show you once we get going, I'll show some of them now. So like the single user change log, oh, that's right, I did this wrong last time too. The single user change log lets you see all the changes that have happened to a user. So for instance, I'm going to pick the Matt Mosley on his own right here and just run the report. And we're gonna do change log for a period. That'll be a little bit easier. So today is the 25th, so we're gonna do that. There we go. So now we have some data that we can show. Now again, this is a simple reporting system. If you want to be able to do more complex reports than the couple that we allow you to do, you can hook it up into any kind of business intelligence system. And these reports are all just SQL, so it's very easy to build different types of reports and add them. So I'm gonna go ahead and log out and I'm going to log in with my new test user. And now I'm trying to remember I created just beforehand and I can't remember what I named that user. It was, oh, now I do. Actually before I do that, so that's SSO into the console. Let's go ahead and go into WordPress real quick. So you'll see I'm SSOed into WordPress. I'm an administrator. And if I come to users, you'll see all the previously provisioned users here. And what I'm going to show you soon is that there is no one here named Jennifer Stanton. I'm gonna go ahead and log in with her for the first time. So let's go ahead and log out. So now I'm signed in as Jennifer. And here my attributes, you'll see I have no roles assigned. So let's go ahead and first I'll show that there are some reports that we can run, but you'll notice that identity management group is no longer here. That's because I'm not authorized to even see anything in there. So you can do interesting things like if you talk about privileged access management, you don't want people requesting unless they're already pre-authorized to be privileged access managed to do things like that. And so you can actually limit what people can request. I've got one customer that's doing it with police officers. If you're not a sworn police officer, they don't even want you to be able to request access to certain things. So first thing I'm gonna do is I'm gonna request access to Amazon and then I'm also gonna request access as an editor for WordPress. You'll see that we've got a cart-based service for this. You know, if I log out, there's some error checking, some error checking there. So I'm gonna go ahead and submit my request. So that's gonna go ahead and submit a workflow request. Now our workflows are asynchronous and we're built on top of JMS and Qs. So every task in our workflow goes on to a JMS Q. Nice thing about that is it makes us really scalable and also reliable and it works really well in OpenShift because there's no persistent data inside of the system. So I'm gonna go ahead and log out and log back in as our super admin. You'll see I've got a couple of open approvals here. So this is all configurable. You know, we can configure what is seen and let's go ahead and enter a justification of demo. I'm gonna improve the request and I gotta confirm it. Then when I look at the second request, we can already see that the user's been provisioned. So typically your workflow will look something like maybe load some data, do some data manipulation, get an approval, maybe two. We support escalations and approvals. So you can say, all right, if this hasn't been acted on in six days, go ahead and escalate it to the next level and change who the approver set is. We'll be supporting delegation in the not too distant future. So if you're on vacation, you want one of your deputies to be able to do approvals on your behalf. You can say, okay, I'm authorizing this. And so that way there's an audit log of that process. So at this point, Jennifer has received an email saying, hey, you now have access to these applications. Thought log in. And you'll now see I've got these dynamic links have now been generated. I have these roles. And I'm gonna go ahead and go ahead SSO into AWS. And if you take a look 1F844D7, 1F844D7, I use the object grid because I really like the fact that it's immutable. If names change, et cetera, that ID never changes in Active Directory, whether it gets moved around, reorganized, et cetera. So it's a really good ID from that perspective. And then I'll go ahead and log into WordPress, which okay, we're gonna go live demo. We're gonna try this again. I know why. The user doesn't have an email address. So I'm gonna show the virtual directory here in action real quick. Go to here. And let me see if I can find Ms. Jackson or Ms. Stanton. So yep, no email address. And so I'm gonna come back here. I'm gonna log out back in here that we now have an email address. So again, this is all being done in real time. We're not syncing information in. Now I log into WordPress, I get in no problem. You'll see I'm already logged in. And we've got a form of single log out here set up. So I have to log back in again. And then you'll also notice when we go to the WordPress dashboard, we don't have all any of the administrator stuff. That is because we're not an administrator. We're a subscriber. And so we're gonna go ahead and show the just in time provisioning, kind of changing that right on the fly. So I'm gonna log out. I'm gonna log back in as my super user. Oops. And I'm gonna go right into WordPress. So I'm logged in as Matt Mosley. And I'm gonna come down to users. And there's Ms. Stanton, our user who is an editor. So we're gonna go ahead and change her over to a administrator. We're gonna hit update user. So now when Ms. Stanton logs back in again, she's gonna see administrator rights, right? That's, you know, I just enabled it, right? So now we're Jay Stanton. However, we don't have administrator rights. That's because the just in time provisioning process said no, that's not okay. You can't go ahead and be an administrator because the authoritative source said no. So let's come in here and let's request access to be an administrator. Now you can see we get some indicators that we've already been approved as an editor. And I'm going to say for admin. And now I wanna know what the status is. So I'm going to take a look and see my open requests. Okay, well, this guy Matt Mosley is still sitting on my request. That's why I can't make the changes that you keep asking for. And again, these reports are all customizable. You know, just some SQL you need to know and our published schema. And you can also go ahead and, you know, we allow parameters to current user. We let you specify a user. We let you specify a date range. We showed you a couple of those before. You know, some other things that you can do with open unison from a deployment standpoint. We have a TOTP app. So being able to not only request a TOTP key but be able to import it into your phone. We've got a user self registration application. So users can go ahead and if you're talking about folks from the outside being able to register for your systems. And then we also have a single request application. So like the privileged access manager use case I had mentioned before, you know, it's more trying to stop users from just requesting everything. And so what we did was we let you deploy a version of scale that all it's gonna do is request that one request for you execute that one workflow. And so if you've got privileged access, folks you want to give privileged access to you can give them that URL a little bit of security through obscurity there. So that's really the demo. Like I said, everything, you know, minus a couple of little glitches there. You know, kind of just came together from a deployment time standpoint. Once we had open shift up and running. You know, getting that first open unison instance took the longest. That probably took me about a day. Just trying to tailor the image correctly. But scale was very easy. That probably took me a couple of hours. The second unison instance really only took me about half an hour. And then WordPress took me about 45 minutes to an hour. So very quick, very easy to deploy. All right, let's come back to our, so questions gonna come up. How does open unison and key cloak relate? There's certainly some overlap, you know, kind of in this slide, can't give either project, you know, can't do either project justice and the breadth of features that they have. You know, in common, there's a lot of SSO functionality in common. We can both do identity provider brokers. We can both do federation, social login and a couple of different multi-factor methods. You know, we can both integrate using SAML 2, reverse proxies and there are mechanisms to be able to do just in time provisioning. You know, kind of where we really separate out is on the user provisioning side. We're not, we go beyond SSO. SSO is certainly one of our capabilities. But really, I think our most powerful capability is in the user provisioning aspect of things. You know, we've got a very simple workflow engine. We specifically didn't go with a standard like BPM or BIPL because we wanted to keep the workflows very simple. We find that engines built off of BPM or BIPL tend to become very big and very difficult to manage. And you know, for what they're built for, they're great. But for a really constrained use case like identity management, they tend to be overkill. You saw our reporting integration. What you didn't see behind the scenes is our queue integration. Kind of touched on this. We ship with active MQ embedded. However, we can integrate with any JMS based queue. That makes us very, very scalable. Task can be run on one server and then next task can be run on another server and next task can be run on a third server. And I mean, you know, this is open shift, right? And open shift leverages that same type of queue infrastructure. So you know how well that helps things scale. And then we've also got the ability because of that to retry. So we can't get a network connection for some reason. It can go off into a dead letter queue and when you're ready and the system comes back up and running, you're able to go. And then we also have integrated distributed scheduler. So built on Quartz and what this actually lets us now do is anything that's time-based. So for instance, reminders, you know, every morning we want to remind folks that have open requests that have been open for more than a week. Send them an email, you know, the ability to change who the allowed approvers are for a given request are a couple of examples. Some other examples are automatically disabling users after a certain amount of time. Well, this user hasn't authenticated or has been disabled for a certain amount of time. We actually wanted to delete them, things like that. So what are we up to? You know, what's next for open unison and TRIMO security? Well, right now we're working on a white paper on cloud server management with open unison and free IPA. The idea being that you've got this great tool and free IPA for managing servers but what if you can't build a Kerberos trust with Active Directory, usually for policy reasons. You know, we provide a very powerful mechanism to be able to do that integration in a disconnected fashion, makes it a great tool for managing servers up in the cloud. Now we can also manage the authorizations. You know, you can define in free IPA, you know, which roles have the ability to do what on which hosts but we can also add that capability to say, okay, well, instead of having to manually add them or rely on Active Directory administrators, admins can log in and request access to these different services, get it approved and you know, you've got an audit report. We're also gonna have a white paper on building an open source identity as a service with open unison. So what you've seen here, a little more generic built on just generic Docker with a more open shift focus coming once we have a source to image built. So now that we've gotten it up and running, we've kind of, you know, we've got generic Docker builds for everything but now that we've gone through open shift, you know, there are certainly updates we can make to make that process easier. We're gonna do some integrations with Key Cloak. Some of them a little more theoretical that I don't know how much value they'll provide but they might just be a lot of fun to code and some of them, you know, I think would be really useful. You know, we're looking at on the, why I think it's a little more concrete side of being able to have an SPI where if you've got Key Cloak set up, you can leverage our just-in-time provisioning solution to be able to go ahead and update downstream applications. So broaden Key Cloak's ability to access those systems and provide reporting and whatnot. And then on the more theoretical side, I think it would be really cool to have a virtual directory on top of Key Cloak. You know, Key Cloak has a way of managing users and doing things that a directory can do. You know, I don't know how great it would scale as a directory but certainly be an interesting exercise. So that's one that I'm hoping to be able to do. And then we're going to build a AngularJS version of scale and that's in process now. And yeah, you can see our progress on GitHub. And so the idea will be is instead of having to deploy a separate J2E application, you can sit directly on OpenUnison running AngularJS. We're not going to retire scale. You know, we're just want to offer multiple options. And finally, this is all in lead up will be, we're proud to announce that we'll be sponsoring Red Hat Summit again this year. We had a great time in Boston last year and we're looking forward to seeing everybody in San Francisco in June. If you'd like to get in touch with us, you can catch us on Twitter at Tremolo Security, the web at Tremolo.io. And our GitHub repository is Tremolo Security. The OpenUnison project itself is OpenUnison. We have an open source first mentality. So whenever we add a feature, it goes straight into GitHub. You'll see a lot of repositories in there of stuff we haven't yet merged into the main system. The only time we don't start with open source is if we don't own the code. So for instance, like Symantec, we don't own the code to do that integration. And so we didn't want to open source it without really making sure that we could. So, but we're all in on open source from that standpoint. Perfect. And now open it up for discussion. Well, we were, we can go back and forth in the chat and you have really covered off pretty much everything that I was going to ask you a question on. So the KeyClub stuff was one of the key things that I was curious about because there's a lot of discussion about KeyClub around OpenShift as well. So, and there will be an upcoming presentation. I think I've got someone lined up in April to do a talk on KeyClub. So we'll get you back on at that time to have that conversation. But this has been really great. I love the open source first ethos at Tremolo security. It's really wonderful to see. We've had a whole bunch of people on the call today. So, but I'm not seeing any questions, which means you just did an awesome job covering off identity management for me. So thank you very much for coming and doing this talk today. We'll have many more, I'm sure, with Tremolo security and on identity management. I am thoroughly impressed with the production readiness and especially the auditing reports that are available because I think I come from a long time ago on auditing the IT background and having those compliance things there is really a necessary evil for goodness depending on your outlook on life. And so they're often an afterthought and an add-on to different projects. So it's really nice to see how thorough your UI is and your reporting is and your coverage of different applications, identity management practices. So thanks again, Mark. And we look forward to seeing you at Red Hat Summit. Thank you for sponsoring. And if people have questions, you can post them on the OpenShift Commons mailing list and Mark will pick them up there or pick him up at Tremolo security and we'll make sure we keep him in the loop on our further identity management questions and briefings. So thanks again, Mark, and we'll talk to you all soon. Next week- Thank you very much. We'll be having one more OpenShift briefing. I think on March 10th is the next one. We may slip one in between. Next week if the speaker that I have lined up, mystery speaker decides to commit. But I think the next one is on March 10th and it will be with Andy Goldstein on the service catalog and service linking with OpenShift. So again, Mark, thank you very much. Thank you.