Thank you. There we go. I don't want to. So, my biggest was on work at Red Hat for cockpit project.
I have three main cones, which I'll show a picture of soon. I live in the North Pole, Sweden, where it's very cold, like minus 30 years of times.
I should post a lot of Federer, so if you're going to look at the slides, there's a link there. I'm going to upload the slides after the talk.
And last but not least, transfer it to human rights. So, just that other way. And there's the cats themselves. So, we have Luna, Lisa, and it's all there.
So, what is cockpit? cockpit is, according to the website, an issues integrated, glanceable, open web-based interface for servers.
So, you have a few different ways of authenticating currently. We prefer to use pan modules, because pan modules is like the default login for servers.
And we just want to rely on that, which makes cockpit a bit unique, and that we are a web-based education.
But you can also use different authentication protocols, like single, sign-on, covers, and public keys.
Although, there's a bit of an asterisk with public keys, because you can't really use that in the browser, like with the SSH agents.
But that's where we have the cockpit's client, which is just a flat packet application, so that can just access its no problem.
So, just a screenshot on how cockpit looks. There's just a basic login page.
And we can see an overview on your authenticated, where you can see some security updates, the usage, and stuff like that.
We can see accounts, we can see groups, we can see the networking, and that's there.
There's software updates, and what's been changed, and what CVs are being fixed, and storage virtual machines.
We don't have, like, containers, and stuff like that.
But passwordless login.
You don't have to remember password with that, which makes it so much more secure.
And in most cases, you can just take it with you, other with the SSH key, if you want to do that, or using a pass key, which is, I think, a lot better.
The SSH keys do count as passwordless login. It's just not what we can do with the browser.
So, web authentication, fiddle two, and pass keys are way to solve all the issues, but what is it?
Web authentication is, like, how you can use it in the browser.
The fiddle two is, kind of, like, encompassing of pass keys, and, sorry, of web authentication, and something called CTAP2, which includes, like, discoverable keys, user replication, user presence, and paid verification features, because it's direct access to the hardware.
And pass keys are just the actual way of authenticating the user.
So, that's sort of the differences between us, between us all.
And linking it both, that's going to be this tricky part, because of the modules, I think.
Since it is the preferred way for us to authenticate, I wanted to look around at what is available, and there is something for, by you, because, called, the Pan-U2F module.
And that one has great documentation, it works well with fiddle two, but it currently doesn't work with web authentication, which is a bit frustrating.
But it uses a very well maintained, and great underlying library called lib fiddle two, which is also something that free IPA and SSD uses.
It is also made by Ubico, so there's a lot of interconnecting code and just great tools to, like, help get the tokens you need, the authentication, assertion, and so on.
And you can also use specific tools to authenticate with, instead using Pan modules, like cockpit currently supports SSD, and so using that is probably preferable if we need to go in the way of some special tools.
And with free IPA and SSD, both having task is important at this point, that makes it a lot easier, especially since they use the underlying lib fiddle two library, just like Pan-U2F, which can support web authentication quite well.
You can register it without direct hardware access, because when we're doing something in the browser, the actual server part where we're going to call all the commands, it won't have access to the hardware, so we need to provide it through the web browser and provide all the data we get there to the backend, and that's where the issues might come.
But luckily both Pan-U2F has a manual mode, free IPNSD have a way to add keys, but actual authentication haven't looked it up yet, it's a bit unclear, but it's something we should look into for free IPNSSSD, if we can actually authenticate without having direct hardware access.
So things to keep in mind when we're authenticated in this, since all of these features have a very, very strong fiddle two focus, how can we actually make use of that with web authentication, because fiddle two is very focused on terminal, we have to use the manual mode, we have to configure it in a way that doesn't cause issues, which are getting a bit more soon, because those issues are very relevant to what we are doing.
We may get issues with the relying poppy, especially on console SSD and 380A, because those are using the realm, whereas you might have a different host name or a different domain that you use in cockpit on, so you might have the domainexample.com with the port 1991, and then you have the realm, which is serveridmexample.com.
And if those two aren't matching in a good way, you're going to have some issues with actual authentication, the response that you're sending to Pam or SSD, and there is a thing to actually help with this, which is the well-known web-authent domain.
And that's sort of just, I think it's a JSON array where you can put in all the origins that is being supported through this domain.
So if you're on example.com and you want to authenticate with a different line party, such as the serveridmexample.com, then you would add the example.com within the serveridmexample.com slash well-known slash web-authent.
But it can be a bit tricky, especially if the realm itself wouldn't support providing this.
So, bit tricky.
The best way would be for us to use it like a custom relying party, where we actually provide what we want to the variation, either dynamically or statically just for cockpit itself, just we can sort this out without getting some issues.
But I think the Pamutf is going to be a lot simpler than the SSD implementation.
And then we actually have to think about how do we actually get it compliant with web authentication specification or like what we need to do to make it work.
So, Pamutf, since this is a Pamut module, it is preferred way to do it, because we want to use Pamutjol's to authenticate.
It doesn't support the limited authorization algorithm, which is the client data JSON verification from the webauthent specification, which can be a bit of an issue, because it currently uses the client data hash as a challenge.
So, it kind of collapses both the challenge and the client data into one, just made it simpler, because it doesn't really have to care about anything else, since they're not doing webauthent, they're doing field to so they can skip some step.
And it also relies on CO2, which is a binary encoding format.
So, making that work in the browser, currently, it doesn't work but defaults, you have to either use library or add one yourself, or we can do something on the backend, which I think, live field or two, will actually support or does actually support.
So, we could use that in the backend somehow.
But yeah, as I mentioned, it's always watch a webauthent workflow, so this will be fairly easy.
And I know that Mika, from the Susan's cockpit team, is actually working on making this possible on Pamut 12.
So, it is somewhat easy, in terms of what changes are needed, since live field or two supports it, it just needs some tests and we need to go through some edge cases and stuff like that, but it is going forward.
Just like I walked through on how we would use this on the web browser.
When we're creating a pesky, you typically have a challenge that's gotten from the server itself.
And this challenge is how it can verify that the actual request that you're sending to server and verify that the server is the one that is expected.
You provide the relying party, and this is going to be the ID, which is going to be the domain in our case, and then we're going to have a name, which we can probably hot code to cockpit, although I haven't fully checked it out.
We have a user, we will provide an ID that's either randomly generated or unique, at least in some way, which else is going to be some array of binary array.
I'm going to have the name of the user that we want to authenticate, and then just some display name in this case, I just took admin admin, because why not.
And since Pamut 12 is very strongly attestation, they're actually authorizing everything with the public key.
You need some sort of attestation to actually make sure that you cannot authenticate, otherwise this wouldn't work.
So you can use direct, or you can just, I think, interact, direct includes a lot of the public key stuff that is provided through the browser, although I haven't fully checked it out yet, I'm not sure.
We set the time out on 60 seconds, just have something, we add some authenticated selection, where we say, we don't want to rest in the key, but also not discoverable key, because I haven't done it yet.
And we don't want user verification where the user has to touch the device and stuff, just make it simpler.
And then we just provide, okay, what actual algorithm we support, and we put in the three that is supported by Pamut 12, which is the ES256, EDDSA, which you have seen from SSH logins, you're shooting, and then RS256.
Then you just call, call this to the browser with the public key, we just created, we get the credential back.
We decode the actual attestation object that we receive, so that we can get to public key that is expected from, or on the Pamut 12 side, because they have, like, a fiddle to kind of way of doing it, so I have to use the C-board encoding on decoding.
And we're basically just getting a public key object, which is just offset in the attestation object, and then that is, includes, at least for ES256, an X and Y value, and some other stuff of, like, what it is, and then we just add it to, like, a 64 bit, a 64 bit array, just because that's what's expected from Pamut 12.
We then called the raw ID to basics 4 and the raw ID is just way of identifying the key from the server, so in the server we stored raw ID, and then when we're authenticating, the server is going to send, okay, here are all the keys, again, use, and your browser will basically say, okay, we're going to look and see if you find this, this key, so if you do, then you cannot authenticate with it, quite easily.
And we're sending it to server, we use the concatenated public key, which is created, we send the ID, and we send the algorithm.
And then on backside with Pamut 12, we stored it in this way, which is the user, column, and then all the different pastkeys that you've created, so you have the ID, the identifier, the public key, that's going to verify the attestation.
You have which algorithm is being used, which is one of the three options, at this point, at least, hopefully we can get MLD safer, like the post-contom encryption, although it's not necessarily needed.
And then flags, which could be plus uf, sorry, plus up, plus uv, or plus pin application, I think.
The picture of the exact naming, but one is like, you have to touch the device, the other one is you have to use the biometrics, to actually check that you have the right finger print and so on, and the other one is just to enter in the pain to unlock the device and so on.
That sort of, like, how we store it and use it, and then when we communicating it's your copper shell, we can actually execute commands directly to the server using web of them, sorry, using web sockets, and that can be any command we want, essentially, that makes it possible to modify files and so on, so in this case, I've just taken something from the existing code, we have records, force regenerate all, and we just send this from the front end to the back end and it executes.
So that's how we will actually modify the file, instead of like that, and it is very easy, I think.
The authentication that's going to be the difficult part.
So we have a default authentication flow in written in C, that is being run through cockpit session, which can provide where you can also provide, you can also provide different authentication flows in a like a config file if you want.
And it will look for specific authorization headers, so currently you have like basic, you have better, you have.
I don't know what else.
I don't think of the other ones, but you can basically have anything you want there, you can have also reshesion table if you really want to have something special.
And then there we just say, okay, which command do you want to use, and as long as it is something can execute in shell, and ideally communicate with Pam or something else that you want to use, then you can use it.
So Python is fine, C is fine, so on.
So the actual work I managed to get so far due to some limitations with the Pam you have module and just UX workflow stuff that I'm going to come through yet.
I managed to get the use name password together with Paskey 2.5 to work.
So we enter in the username password, hit login, and then we get a new screen where we have a login with Paskey button.
And then get that case, we're off the button to challenge, so all we need to do now is click the button and then you can login.
But it's not ideal.
Ideally, you just want the one button to click and login, but we'll get to that.
So with the username and password, we're going to use the authorization basic, which can be a basic for data with username password.
We're going to converse with the Pam stack, and we're going to get more inputs.
That is being sent to the server, being sent from the server to the browser, and then we're going to display that depending on what it is.
So if you have a TOTP, like to factor authentication, TOTP token that you have to enter in, we'll show that on the browser.
If you have Paskey, then we'll show the button, and so on. So it's fairly easy to modify for us.
So we're going to show demo where we're going to put in the username and password, and then we're going to get a new screen where we're going to use the Paskey as 2.5.
I'm using the Chromium virtual environment, the authentication environment, because it makes it easier just to not have to click a physical device.
It's just almost instant.
And unfortunately, we have to add it manually to it to see you have mapping, because it's not something added.
So it can access that in the login.
So, oh, yeah, almost there, but not really.
So, here we have the virtual environment, and see what I've created.
If you see TOTP 2, I created Create Paskey where we get something in the console, which is the ID, the public key, the ES2,
the 6, and then the flags, which in this case is none.
It is for the admin user, and we added to the mapings.
Then just look at the logs.
Following the logs, you see what happens.
I click Login with the username and password, and then Login with Paskey.
And after it selects the actual Paskey and you authenticate, then you're just login.
And here you can see that you have Pam, SC authenticate with success.
So everything worked.
You can see all the outputs that we got, and the signature that we sent to the server.
So, everything just works.
So, the hard work is done.
Now, it's just like the user experience that we have to improve and actually also get the PR at Pam, you have to be merged and so on.
But the one thing that everyone uses is Pam, is the one click login.
And that is, you're going to have a credential that's discoverable and not discoverable.
The discoverable one, you don't need to input a username.
And it's the preferred way to do it.
If you look in GitHub or other applications, you click hit the long-length Paskey.
And usually that's just, you select the Paskey.
You want to authenticate with and then it just works.
Unfortunately with the hardware that you use,
you're only going to have a few limited slots.
So, with Ubiquit 5 is 25, sookies, 50, and then with nitricade, depending on the firmware and a model.
And it's going to be 35 to 100 slots, which is quite a lot.
If you're not discoverable, the credential is going to store an infant mount,
but then we need to provide actually username.
So, how we do that is a bit of a UX challenge,
because we kind of want to have the username password,
but also it would be kind of weird to not provide the password.
But then click the, but then provide the user field.
And so, use the name.
When you log in with Paskey, we're going to provide,
we're going to get the challenge.
We're then going to parse the data given from PEMYTF.
We're going to send that to the allowed credentials,
because in this case, it's a normal discoverable case.
So, we have to use, we have to provide the username ourselves,
and we get all the keys that works.
And then we'll just send that over to the browser.
We get back a lot of stuff that we just send back to PEMYTF,
which in this case, we're going to plant it at JSON.
We're going to be RPID, which is because they don't have the line-party currently.
Since there's an client data hash, instead of JSON, we have to provide it.
But that's something we might change.
We'll see if we're allowed.
We see, we're in code, the authentic data.
We send a signature, and then the user handle, and then it should just work.
Also, in this case, I don't think we need the user handle since we already have.
No, yeah, we need the user handle, because this is supposed to be a discoverable key.
It's a bit of a mix, I think it made something wrong there.
What's left, there's a lot of stuff.
We have to get the WebAscent implemented in PEMYTF.
We're going to add some stuff to the cockpit, to support the pass key.
We're going to add a model to the cockpit shell when you're logged in.
So you can add in the lead pass key, so I deal with some sort of naming.
So you can name all the pass keys.
And we're going to have a new line support in cockpit payload.
So that we can send one request instead of many requests when authentication.
Authenticating, because PEMYTF expects multiple inputs, which is a bit unfortunate.
And then we're also going to follow with SSSD and free IPA.
Just we can figure that out since we're going to have SSSD implemented in cockpit.
We want to get that working with pass keys, just because we're all to don't have to work.
So it should be fairly easy.
So we're going to go through this a bit fast and running at the time.
So the general timeline, based on my guess, is that we're going to have some sort of working prototype this month.
We're going to get PEMYTF PR merged, hopefully this month.
Since most of that is prepared, we just need to create some tests to make sure it's okay.
And we're going to clean up some basics before URL, conversion, whatever.
We're going to get a functional pass key login.
So you have the one click login.
And then early March, I hope we have gotten the registration.
And in that case, we can do a full review.
But we'll see.
Q3, we're hopefully going to extend that to SSSD and free IPA.
But time will tell.
It depends on the priorities and stuff.
So thank you to the new case for me.
The others are what we normally made all the icons,
Meika for implementing stuff.
And you can find the slides on this link and cockpit on that link.
I'll also provide it in the actual first them page itself.
So you can find it there.
But I'll do that after we talk sometime.
So thank you.
Thank you.
We have one minute or less.
But one question.
Any questions?
Yeah.
So we have to set out some components.
I can create.
But then you have to envision that they're making a lot of blood,
but they can close, right?
What do you want to do?
I'm sure.
I'm just like different.
Can you take some views?
How does that look?
Can you do this?
It doesn't matter.
If you mean, like, authenticating with, for example,
TLTP and Pasquise and so on, like, in the same stack?
Yeah.
How does it mean that you can take some views?
Like, if it works, there's a lot of money.
We might not have to be enough for it.
Yeah.
The question is, like, how can we, this, like, figure out if Pasquise alone
will be enough to authenticate?
Is that right?
Sort of.
It is a bit unclear for me as well.
I'm not sure how we can, like,
the login with Pasquise button showing,
in a way that makes sense.
Because, like, ideally, we can detect whether or not we have
the live feed or two in PAMUTIF and able somehow.
And then we'll just show that in the login page.
But then we'll probably need to have some code to detect that.
We actually have this in the next game.
You have an installer.
Yeah.
But it's, it's a bit tricky for us,
since we kind of have a static login.
So we'll see.
Like, we can add some sort of C code and stuff like that
to make sure it works.
But, yeah.
Does that answer your question?
Sort of.
Yeah.
Maybe you've got more of it.
Yeah.
Thank you.
APPLAUSE