 Does anyone not know? We'll see. All right. Well, I'll get into it. So my name is Rob Crittenden. I'm going to talk about Project Ipsilon and federated identity. So, meet Joe. Joe is just your average guy, likes using the web. He's got a bunch of different identities. He's got a work identity. He's got a home identity. He might be a gamer. He might be a blogger. A lot of people know him in a lot of different ways. He really likes to use the web. This is a typical, you log into a website. They have a local user database. He does this all over the place. The problem is, he's got passwords for everything. Different usernames, and he's not always good at getting a good password or choosing good passwords, because he's just an average dude. So, there are fixes for this. You can think of LastPass, lots of other tools to help you consolidate your password, which unlocks all the others. Federation is another solution. So, you basically have one account. The astros there, because you can actually multiple accounts one for each identity. You might have a work identity, you know, home identity, you know, gaming identity, etc. Trying to oversimplify things a little bit. So this is good, because then you have one password for a account anyway, and you don't have to remember all this stuff and hopefully you have a better password. It's good for the web applications that use federated identity, because they no longer have to do password resets. And they don't have to worry about getting their database hacked and having all the passwords stolen. It's notify everybody. And it's awesome. Some federation can be good for administrator with people leaving too. So, for example, in a work environment, if you have federation, you can log into Oracle and Salesforce and a lot of other things. When you leave, they don't have to go to Salesforce and delete you and go into Oracle and delete you and go into the HR system and delete you. They just delete you out of the federated identity system and you're gone. And you can't log in anywhere. This is a very simplified version of what federation looks like. So Joe goes to example.org which wants authentication. So his browser redirects him to an identity provider of some sort. He provides some sort of authentication. It's validated locally there and then he's redirected back to example.org with some sort of token. And this token identifies who he is and it might say some things about him. It might say his name, his address, his email address, or other interesting facts. This is not federation. This is stolen screen from CIMO. This is example.org is basically sending your password onto another site. You can't control your credentials this way. This is totally not safe. It's literally a man in the middle. It's a terrible idea. So some general information about federation. You're basically outsourcing your identity. Now outsourcing might not be very far. It might be outsourcing to IT. But you could be giving, turning to somebody else. For example, Google is an open IP provider. So they're providing an identity for you. So they're certainly a third party. Usually these are HTTP-based protocols. It doesn't have to be. And they're usually done in a browser. So there are rich clients. You can do SAML. It's one of the federation technologies and you can use that from a command line. But typically they're browser-based. Some use cookies for steak. Some don't. And there's, I'll get into this in a minute, there's a centralized or decentralized federation. And then here's some common examples you may have heard of. So we'll start with SAML. So this is centralized. So by centralized it means there's one identity provider. It may have multiple instances, but there's one place you go for identity. It was created in 2001 or so. And the last spectrum of SAML 2 came out in 2006. It's pretty stable. But because of the time it came from, XML was hot then. So that would say XML-based. And it's hard to read. And it has to be a race to be asked because otherwise the content's readable. And you have tokens going back and forth. So you definitely want SSL. For SAML, it requires an agreement between parties. So if you want to be a web provider and deal with a SAML IDP, you have to exchange the information. So it's called metadata. You basically exchange keys. So that when you get an identity from the SAML identity provider, you can confirm that it's from them using a signature. And you can even be encrypted if you were longer that far. SAML provides cross-domain single sign-on. And what that means is, so cookies are domain specific. But with SAML, the cookie is for the IDP. And so you go to the IDP and you get your cookie and then you provide additional data to the service provider, which can be an any number of domains. And so you can get cross-domain single sign-on that way. SAML also has single logout. So if you log into a bunch of different websites, you can click one button and log out all of them at the same time. Which is pretty spiffy. I'll go over that. Now this is the race to order picture we saw before. Joe here in non-stick figure form starts by going to a service provider. Service provider is a fancy way of saying website. The service provider doesn't see a cookie for Joe, so it redirects him to the IDP and his browser takes care of this. The IDP is going to present some sort of page that's going to say authenticate. Now you can authenticate any way you want the IDP, whatever way it supports. And this is another advantage of federation is that Joe's web service isn't going to want to have, you know, one-time passwords in Kerberos and a lot of other some of them are more difficult for authentication mechanisms. We're an IDP, that's all they do. So you can, typical as Kerberos, LDAP back-end authentication, simple form-based one-time passwords at whatever you want. Once you're authenticated, SAML issues a token, sends it back through Joe's browser to the SP, recognizes the token and the way you go. Inside the token for SAML are what are called attributes and these attributes contain information about you. They might contain what groups you're in, your email address, things like that. And it could also contain additional information, which is kind of beyond this talk, but this is a basic overview. This is what single logout looks like. I had to grossly oversimplify this because the lines got a little crazy. But basically Joe logs out of search bar out of one. And the first thing that SP-1 does is redirect back to Joe's browser and sends it to the IDP, because the IDP is where all the real action happens. So the IDP looks for all the login sessions that it has for Joe. And then it's going to one by one iterate over those and log them all out. So the only one left is the originating logout request. And so in this case, I'm showing logout over SOAP, which is basically an HTTP post. You can also do redirect logouts, and that's actually recommended by the SAML specification, but it wasn't possible to draw. So basically logs out of search bar two. Once the IDP sees that everything else except for the original ones logged out, it logs them out of there, and then redirects back to the search provider, and he's done. And if Joe went back to any other provider, he would have to authenticate. OpenID is another pretty common federated identity solution. It's decentralized in that you can have identity providers anywhere. Your identity is neural. And the neural basically contains information that says who you are and who's going to authenticate you. And basically with OpenID you prove that you own this URL by providing a password. And with OpenID you can run your own server if you wanted to. It seems a little hardcore, but you could if you wanted. So the OpenID itself is, like I said, it's just an URL, and it could be whatever. The only thing, like for example, my URL, let me skip forward one slide. I'm a Marker in that idea of neural project. So you know something about, you know, my fast login because I'm Marker in, you know, related for your project. So you had some idea about who I am, but otherwise you can't glean any of the information out of it. So, and similar to SAML, you can provide via consent any number of different national units. And OpenID is extensible, so depending on what extension is available defines what data is visible. So, oh, goodness sake. So this is, when you fetch this URL, you're going to get something that looks like this. And part of it is OpenID server, and so we know to go to iddepradorproject.org. So when you try and authenticate with this, it's going to redirect you there to log in. There's actually a pretty complex discovery process where the URL is going to be much more. The data contained with the URL can be much more complex, but like I said, I'm just trying to give you a basic review. So then what happens is a shared secret is established between the So I've been using the term server survivor and iddep and SAML. It's identity provider and relying party in OpenID. So the relying party establishes a shared secret with the identity provider directly and then the user is redirected to the identity provider to authenticate and similar to what we saw at SAML, they provide an indication somehow. And again, this could be more complex than the relying party wants to do itself. OpenID doesn't use cookies, so it just, it's took and goes back into content of each response. Sure. Well, I mean, the protocol-wise, they're conceptually similar, but OpenID is just an URL. And in this URL, it tells a lot of information about where to go to the IEP. You don't need to register the search provider with the OpenID provider, for example. Like in SAML, you have to exchange keys. OpenID does it on the fly. So you couldn't have like a rogue search provider in SAML, or it's centralized. You have to have a handshake. OpenID is not so much. So I can actually use my Fedora project to open ID anywhere I want within reason. You can accept. You have to accept OpenID and accept. Right. You can not trust other OpenID providers if you want. You can actually set up a chain of do I trust and do I don't. But for the best part, it's on the relying party. It's pretty friendly. Right. So the relying party, the consuming service in OpenID case, defines what central service needs to be trust and accept. And it can be anything that supports OpenID. Right. In SAML, you have a more control. It's like the IEP register, the register of the services. So one is the OpenID is more for collaboration between different services that are independent, while the several is more for the configuration between the services that are related. We know about each other. So what's Ipsilon? Halfway through the talk. Ipsilon provides OpenID and SAML as a service. So it consists of pretty straightforward installation scripts that set these things up for you. You know, this SAML and NIPs and OpenID are pretty easy to do. But there is some metadata to exchange and generate keys and things like that. So this greatly simplifies that. And it lets you figure like, so I talked about what attributes you can have. Man address, email, etc. You can control who sees what and sometimes even what is called, because different providers expect different names. There's a native GUI in our plugin framework, and IPA can be back in the identity. So this is what you see when you log into Ipsilon itself, pretty friendly, administrative GUI. I'll go over each of these. So each of these links basically is a major set of plugins. So each provider in that case is a Federation protocol. So we support SAML too. So SAML is a quite large specification, and they actually have a conformance document. Ipsilon is IDP light, which doesn't, it makes it sound like it doesn't do much, but it actually, it's about half the spec, the most used parts anyway, from our perspective anyway. Open ID, and it supports FAAS. So I assume everyone here's got a FAAS account, if so, you can use the Ipsilon for the last two weeks. So, and then Mozilla Persona is another provider that we support. It's an email-based, well, yeah, it's an email-based login system. It's not super interesting. So the login mechanisms that we support right now is just to save the I, which means you have Kerberos. There's form-based authentication, which uses, so Apache has got a whole bunch of modules. Mod, intercept, form-submit is the one that we use. So basically it intercepts the form, and then does the authentication for you within Apache, rather than submitting to like a WSGI and having it do the authentication. It can do that too. For backends, you can login via LDAP, PAM, or the door account system. And then information providers, this is where we get the attributes to fill in the information about you. So by default, the things available are like, the groups are in, down the list you have, things like that. We can get the data over SSSD. It's InfoPipe, which is a D-Bus interface. So if you have free IPA, and anything in free IPA is available as an attribute, in SAM or maybe. You can also get data by LDAP, which is almost the same thing as SSSD. It's just a little more complex to set up, and you need extra identities. Or you can just get it right at NSS, but you get your Gekos. It's about it. So, and I mentioned before, you can configure data visibility. So if you have a search provider, you don't want to know people's addresses, you can limit to, let's say, or name an email. Or some providers, there's interoperability differences between SAM providers and OpenID providers. Some might want email as an email address, and some might want mail as an email address, and so you can do mapping of actually names. So it's one thing to talk about it. Let me see if I can actually show you what epsilon looks like. So I'm going to install epsilon server with IPA as the back end, configuring the SSSD input pipe with all the form-based authentication, and I'm going to enable OpenID too. So SAM will, by default, is enabled. So it's going to look and say, I already have a key tab. This machine is enrolled as an IPA client, which also simplifies the certificates that we need. And that's it. We now have an IPA. So if I go to my browser, I have a controlling character. Okay, so I can authenticate. How's this showing? Oh, that's fine. So I can log in as my IPA administrator, which is the same name as the epsilon administrator. So it all just works. And I have my friendly page where I can flip through and I can show you. So we have OpenID and SAM configured. We have GSAPI because of IPA, form-based authentication. Test-off is not something that's interesting for most people. Yes, basically it's letting anybody in. And then SSSD is enabled. And then SSSD is disabled because you don't need them both enabled at the same time because they get the same information. So now it's really interesting that we have a service provider. So let's set up a SAML. So let me go over this. So the SAML ID key metadata, so this is basically saying, I'm setting up a service provider and this is where you can get the identity providers metadata. And then the SAML auth is where I'm protecting. And then I'm going to automatically register this SP with epsilon without having to do a lot of metadata exchange myself. So I basically just provide the password and it registers for me over a REST API. Do you need to have the client? I, you don't. No, the client doesn't because all the identity stuff happens on the IDP. I do because it makes us so easier so I can use IP to get certs for everybody. And then I don't have trust issues. You also don't even need to use generate standard SAML weather data in the change. Yeah, but the epsilon client install is convenient. But the question is, what are the requirements, right? Do you have to have IPA? No, you don't have IPA. Is it just this command, or do you have to do a lot of manual stuff for this command to work? It's basically just this. So I mean, if you think of SAML, a common case is somebody who had a throw my IP and they wanted to use some outside service, right? A, W, S, something like that. So the SP, very likely doesn't have access to the all that server, the active server, whatever is in the IDP environment that you might need to get it separated. So this case, exactly. I mean, you can't have it connected. I can't if you're in the same environment. Absolutely, if I'm not, you can get certain support or you can control access for administrators at that website, but it's not a requirement at all. So here's the SP test the provider just added. Let me explain why I have all my clients involved enrolled in IPA. So you can manually add a provider here too, so you can just give it some friendly name like, you know, Joe's. Now for the metadata URL, you know, probably want to, if you wanted to provide the metadata over SSL in, you know, HTTPS, blah, blah, blah, blah, blah, blah. Well, when you submit, it's going to open an SSL connection to that search provider. And if the CA trust isn't there, then things don't work so great. So that's why being in the same PKI is easy or use search that are issued from some well-known provider or is already in your search bundle. So what does it do? It connects to the SAML, to the modus malum effect. Right, right, but if it's protected by modus SL or mod NSS, then the TLS connection needs to be trusted too. And if you have, so if you install this using locally issued self-signed service everywhere, then it's not going to work out too well. Because you need to suit. You need a CA, right. So using IPA, you have a central CA as well. So it simplifies things. It's not mandatory. And this, you know, all these things are not a problem to overcome. It's just for demo purposes that was easier to do it this way. So how this is different. So you're now adding manually. This is the alternative way of installing the client, right? Yes. So if you use modus malum, you're pure just plain modus malum. And you, when it starts up, it generates its own metadata. And so once you have your search bar out of running, all you have to do is go in here and provide the URL to where that metadata is. And it'll just slurp it over the interweb. How trusted is that to get this? I mean, how we authenticate the first exchange. So the SP metadata is based, already has the IDP metadata. So it's signed by the IDP public. Can you read it? There are three ways there. Two of them are either you get a file on the machine and you upload it. So trust me this case, you are long enough that you mix them up. Or you copy and paste it the same. And the only one where you have some trusted issues is the metadata URL. And you really want to use the IDPS there because you really want to keep the correct server. And that's why you wouldn't have a CA. Absolutely rely on the certificates. In this case, you are. And then you rely on having the right to correct the A, just to show what the metadata is. Oh. Just go back to the National Certificate. Yeah, really the way you're trusting me is this is configuring Apache as a directive from a lot of people that says here's where the certificate is and I'm trusting you. So this is what, let me pull this down a little bit. This is what the metadata looks like. So it's basically the public key of the, this is a service provider. And then it's got a bunch of entries for the things that support. So it supports single logout, the assertion consumer service, which, and then the name I use supports. So in some of the SAML, you can actually, the name returned by the IDP doesn't have to be the name you log in with. So it could be any number of things. It could actually be the same thing. It could be your, your Kerberos principle name. It could be a random UUID, where it could be a random UUID that's always returned for you. And that way you can, you can link identities. And it could be number of other things. NT has one, X599 subject, some other things. So let's show it action. So if I go to the secret site, my laptop is not rolled on IPA. So when I, when I try to access the secret site, I immediately get redirected to the, to epsilon. I'm going to log in this geo, that authenticates me and hearing it back on my search rider. We can look in the environment. And we'll see these melon underscore names. These are basically the action reads that were in the SAML assertion. So we have my full name is GeoUser. The group I'm in, I'm going to group IPA users. My phone number, it's got my mailing address. And anything, any attributes that are allowed to be sent over will be listed here with the names. Now, the underscore zero bit, these are for multivalue. So if you were a bunch of groups, you would have group zero, group one, group two, group three, group four, so, and same for any other attribute. Now I can log out and I'll log back in. Of course, it's going to authenticate me. So I wanted to show single log out. So I'm going to install a client on my, my Ipsul on server as well. Just to, I didn't want to serve another VM for another search rider. So I'm going to log back in here and provide the right password. So now if I go to, this is the new SPS setup. And I just get right in because I authenticated over here. So I probably should have made them look a little different. So, all right. So if I look at the environment, it's exactly the same because it's the same assertion. Do you have alt close? Well, yeah. So, host will be in here only because a patch provides that information. Yeah, just to show that it's different types. You can see it up here. I guess. Yes, this is Ipsul on .example.com. This is that SP. And this is SP test .example.com. So, all right. So let me show you log out. So I logged in to SP, into the SP on this tab. I'm going to log out of the SP on this tab. So, it's like log out and I'm logging back out. Okay. So now I still have this, right? But if I just refresh the page, not authorized. So, pretty cool. All right. Now I also have an open ID provider. And this worked last night. Let's see if it works. So, this is just some example code I grabbed from another Ipsul on developer. So, this is my, that's him. This is my URL, which is rather long and awful. It's configurable. But so, the same thing I sign in. I'm going to be authenticated by Ipsul on. This is something you're familiar with fast. Okay. You get a little dialogue that says someone's trying to authenticate you. How long do you want to, you trust it and I don't have any data sends. So, if I allow it, I'm rude to write it back to this and it failed. Yeah, it's his fault. You can do my demo. All right. If you go back to the previous lines, you can just enter Ipsul on.example.com-hypedestero. That should be it. The only URL you need to enter on Ipsul on.example.com-hypedestero. It's it? Yes. I'm still authenticated. There we go. All right. So I went to run plate. Sorry about that. Now, notice that there's no name and email here, right? Because I didn't set it up within Ipsul. So, let's, no, open ID is full of extensions and those extensions do things like they're loading in the wrong place. So, if I go into open ID. So, these are the extensions available. So, we have, through our teams, yeah, it's really only relevant for FAS. So, if I, simple registration is, provides like username and email, HP Exchange allows a lot more. This is what the mapping looks like. So, we can actually map one name to another or modify with the list of attributes that one's allowed to send. So, now if I sign in again, we're doing the stage. So, it sees I'm still logged in as administrator. So, but now we have a name here. So, admin and IPA doesn't have a password or email address. So, let me log out and send it as jail again. So, now we have full name and email address as things they were consenting to send. Now, if you've ever used like OpenStack, their OpenID provider actually asks you for actually what you want to send. That's something we could talk about adding, but for now it's all or nothing. So, now jail and jail users are sent. So, that's open ID. I'm just going to wrap things up. So, this is where we're going. OpenID can be connected to interactive development right now. OpenID itself is kind of deprecated, not too many people are using it anymore. OpenID can act as based on it a lot too and like Facebook given a lot of other companies are pushing for it. We're working on the ID portal so you can go to the IDP and for example for SAML, every SP that's registered to it will show. So, if you have a company and you have all your internal sites protected with SAML, then you can list everything that each of you might want to go to and you can just click on it and be authenticated and go anyway or if you're already authenticated then you just go into a single sign on and everything's great. Right now the rest interface is only for registering search providers. We're going to extend that to be able to do more stuff over rest and then we're still working on additional SAML profiles so we can claim full performance. So, there's our website. If you want to hack on it, patches are accepted. We're using Paglar. It's kind of like GitHub Lite right now or it's GitHub clone and it's working pretty well for us, you know, for patch reviews and then we hang out with Poundix a lot on FreeNode. That's it, so many questions, let me know. Do you guys have a test with AWS generation at this point? No, no, we've, integration testing is another thing I didn't really put on there. So, it was a simple PHP SP we've tested with and there was a one other, there was a... I think Joe tested Shibuleth. What's that? Shibuleth. AWS and there are a couple different ways they can integrate the SAML. One of them initiated, there's Rob's diagram showed, you know, even in the portal case that we were just talking about, it really just sends you over to the SP and that starts the whole SAML and how you can initiate it is, you can go to your IEP and say, I'm about to access AWS, give me a walk, we'll send it and it'll start from the top. That is on the web app. Great, I mean that'd be what I want to use. Sure, right now I'm managing IPA realm and our AWS account and it doesn't get like this. No matter what, the healthness happens in this model and it's just the intermission that we're going to mess with. Yeah, that's one of the big things on SAML that people want to do is, it's not just internal sites. Again, the portal thing, it's external sites. They're not there like AWS or anything. Yeah, we're using one login for that right now, which is a product that I'm talking about. There's one login thing identity and there's a lot of people out there doing this. I see that you guys want to provide the same login experience and tiles for the third parties. As it stands right now, how brandable is the login portal? Not. Well, I mean it's all CSS and stuff, but it's provided by the RPM. So if you branded it and then... It's not branded though, it's not what it's... Right, but it's all known by the package. It's all known by the package. It's all known by the package. It's all known by the package. It's all known by the package. It's just about the package. It's just about the package. So you get... We're interplacing with you. It's not like... It's not nothing that's hard coded. So the only thing is that you use the battle fly. Yeah. So you need to know how that works. I mean, I could write my own for password reset. I could write my own for password reset for IPA. So... Well, Fedora, I'll have you. You might as well change Fedora, because Fedora needs to change the conversation. Yeah, we have a computable template record, so if you just create your own template to the other directory, you don't need to modify the RPM. Just add it to configuration to point to the other directory. Okay, great. We should have kind of taken that over. How would you create it? Yeah, I mean, I don't want to train my users to learn logging. You said that you don't know. Yeah, absolutely. That's the whole point. That's why we made it template. Right. I got it. So OTPs. They're really important. They're all for me. Yeah. Right. Yeah. Okay. Okay. So what about SPs that require multi-factor? Yeah. So like AWS has got policies and courses and multi-factor communication. Yeah. So that thing would require you to put an attribute in SAML when you log in to IDP that tells you the blocking possible. With two factors. You have a barrier. You have your application. Is the viral barrier not there? Yeah. That's how you do it. The problem is that we don't... We don't have anything that's not a logging problem. It's like, do the thing. Yes. If you have your own form is the application that you should have to log in. I guess what we need to do is to log in to IDP 7. Is it not hard to do but we don't send a deployment at this point? Yeah. So on the AWS side is the authorization on there. How are you enforcing that? They've got a full MFA management system where you can say if you're using what you're using on the third generation. I have that. So they probably just text on an attribute and they don't have to OK, cool. Because that's how you work in SAML. You have a bunch of assertions that you send and they probably sum them up with the user. And then they also tell that IDP is OK so you can do them and the others like this. But if you want to allow only the application that you're doing, they've got to find this group of inaturates. And if someone else in the company clicks on the thing because they're that application is OK, they've got a lot of time to do it. And that's on my speech side. Well, you could enforce it on the IDP side of the area but you don't really want to centralize this kind of access which on this instance, on the IDP necessarily is an application product. But then the application, it really knows what they want to do. And sometimes it's not just like a line. You know, sometimes like, oh, you've got an IDP, you're going to have access to the order stuff. If you have none, you can see that they're already, I don't know, all of them. So it's better to have an IDP. Is there going to be any sort of self-service in Ipsalon to do things or an attribute? Well, I have to identify what they do come back to. So, what about IPA, right? IPA, where they do self-service? We're still on to it. So I don't have that in the future. Yeah, so Ipsalon itself doesn't really own the idea. You can go directly back, but actually there should be preferences which is more of a seamless saying and maybe whatever you want to change. And that's stored with something that's specific to Ipsalon. That would be Ipsalon preference, but things like, you know, a lot of the exports are there. Well, we prefer that because it's more natural that it gives that information but I didn't provide it because I think that would be less profitable. You're right. I don't want to keep it there, but a lot of respect. A lot of the users who are like, what am I going to send to them? I'll send them. You can't allow that. You can't allow the user nobody can expect. And allow the user to say, well, when I go to that side, I don't want to displace a number because for some reason that's going to be forced from them. That allows you to do that. So the preference is that it should be overlapped without the real value. That's possible. So here's Joe logged in to Ipsalon. All he could do was log back out. So... I mean, I might have actually... Yeah. Right. But this is one nut out today that came too much. I mean, really, you know, if you log in with your IPA, you're going to be able to... Right. This is where you can see the portal itself. Right, right. So it would be a tile list of, you know, all the things, maybe a description off the breaking side, and click on any one thing up there. Cool. But an IP in this... So the question is, will IP be federated? And I don't think the IP would be a service provider. Yeah. Yeah. But it's not formally open a yield. No, but, for example, we know that... Ipsalon knows that IP is integrated, so we could, if we see that, just stick one up anyway, because we would have all the information. And one can be sent over there. Your credentials, your Ipsalon credentials, probably wouldn't let you do much at IPA unless you've logged in with Kerberase. So you may have to re-authenticate an IPA in which you aren't. No, because I actually probably have IPA in my queue and the other thing to get it from. Yeah, IPA depends on the Kerberase principle that we're eternally on. Right. You need the ticket, so only if you authenticate it and use it just to get it, seamless to get from one place to the other. Yeah. So you would have to detect an IPA if you have Kerberase infrastructure. And you logged in and you have an IPA somewhere and all we need to do to allow you to go back to Kerberase to check that that application was done to register with IPA. If it was done to that, otherwise it wouldn't. We should know whether we're using IPA or not because we can install Kerberase alone. There's an IPA option that they call for it. So, okay, whenever you're using IPA, configure GS and API. It has to find where the IPA server is. So that's a good point. It would be really easy though. But it's drawing already to have my users go to their IPA and try out the portal. Most users can't handle it. But if there was an IPA port and it was going to say, hey, here's all my attributes. Exactly. Why is that? Our level of confidence in technical terms is the full spectrum. I mean, down the people can't remember their password on the one page they're usually going to and they have a comfort there and a health test level education goes and says, here you go, this is how you use this. They might use it. But actually having to go look up an article on where to go to your IPA management and what needs to change at the level of success has been pretty long. It's more of a length than how complex you have to be at a page. So that page is a little complex. But if you want to be able to say, that is it. You can follow what's on the page instead of looking up. That's the idea of the IP portal. You learn to go to one place to do whatever is in the company and everything is linked there. It works. I'm just curious. What kind of organization it is? It's a global media and entertainment company. We've got about 500 employees globally. There's a lot of cultural discourse. There's just a lot of technical challenges and it's a global. So 50 plus companies run into one. So there's a lot of technology challenges there. I'm putting IPA out as a competitor to doing a global AD trust and that's why I'm so curious on how you guys are going to look at kind of what a portal like. The problem right now is AD and either won't log on and paint identity and this seems like it could be a very competitive... when I both form an IPA developer so we're keen on... Definitely help me save our IPA around multiple. Oh, okay. We started back with one and it moved everything forward since then. There's some pain points every once in a while though. Okay. Can I just stop? I'll clap. Thank you.