Well, as Alexander was mentioning, this is kind of a continuation of the talk I had before.
The previous one was about pass keys.
This time it's not only about pass keys but about other passwordless authentication mechanisms.
So now I have more time so I will present myself correctly.
So my name is Sikar.
I'm a software engineer at Red Hat.
I work in the identity management world, more specifically for the SSSD, Shadow and Linux PAM projects.
I'm the upstream maintainer for Shadow.
So if you want to contribute there, we are welcoming new patches and fixes.
In the past, I also worked as a software engineer but in the automotive sector first
and then in the 3D printing world for HP doing their industrial 3D printers.
And something that I didn't mention here is that I like swimming so if you are a swimmer, we are in the same team.
So regarding the agenda, I will have a little introduction about passwordless authentication
and then I will deep dive into the actual status of the pass key.
Smart Car are external entity provider authentication mechanisms in the graphical user interface.
I will also provide some, well, something, the vision that we have right now,
including some mock-ups and even a demo.
And finally, I will give up a conclusion.
So let's start with passwordless authentication.
So what is passwordless?
It's a way to authenticate a user without using a password.
Well, that's kind of a common ground.
It usually involves multi-factor authentication and also single sign-on.
And on top of that, it strengthens the security by, well, you are using a public key instead of a password.
You are not reusing it.
And you are not vulnerable to a data breach because whatever the attacker takes from the server
where you are storing this data, it's just a public key.
They have no knowledge of anything else.
And on top of that, it improves the user experience because, well, they don't have to remember so many passwords.
They just go there and try to authenticate with passwords.
So currently, the passwordless authentication mechanisms that we are providing in FreeAPA and SSSD
are the PASCII, SMARCAR, and external identity providers.
So for the PASCII, we are using FIDO2 in SMARCAR,
this is one of our internal Spanish national identity numbers.
And then we have OAuth2 for external entity providers.
So now let's see what's the current status of PASCII in the graphical user interface.
So first of all, you enter your username and you arrive to this screen where we can insert your PASCII, then what?
I can't tell you. It's then press Enter.
But it's because I know it.
Nobody else would know.
I mean, you can kind of guess, but you wouldn't then be sure.
On top of that, that's a textbook.
You are supposed to enter some data in a textbox, but we don't need any data there.
So we are just informing you that you need to insert the PASCII.
Nothing else.
Second, if you press Enter there, you would arrive here.
It's asking you for a pin, but it could be that you don't need a pin.
You don't have an extra user verification.
So why request for a pin when you don't need it?
If you don't need it, just press Enter here and you would continue the process.
But who knows it?
And finally, you are requested to touch the PASCII.
The LED is usually blinking, so you just touch it and you are authenticated.
So our proposal.
Two different things.
So if you don't need a PASCII, sorry, a pin, you will be requested to insert the security key.
You will insert it, insert it, press Enter, and then you are done.
But if you are required to enter a pin, well, you have a textbook where you need to enter a pin.
As you can see, it's kind of better understood what is suspected from the user.
On top of that, I didn't mention it before.
When you are doing PASCII authentication, you can do it either locally or remotely.
If you are doing it remotely in the server, you will get a Kerberos ticket.
But what happens if you are doing it locally?
How do you know that you don't get the Kerberos ticket?
Well, you need to inform the user somehow.
And we are still trying to figure out how to inform the user that it will not get the Kerberos ticket.
It will not be able to do the single sign-on and, well, to inform it.
OK, next one, smart cards.
So the state here is kind of better.
You have the available users.
You select a smart card, and then you come here.
You are requested for the pin, and that's all.
OK, this one was easy, but maybe not so easy.
What if you have more than one certificate for the user?
So you select the user, you come to the second screen, and we have the same problem as with PASCII.
There's lots of tests here, and it doesn't fit in the same box.
So maybe you know which one to choose.
Maybe you don't.
You come to the next screen, choose one, and you are requested for the pin.
We also need to improve this.
The user needs to know which certificates to select and why it's selecting this one.
So currently, I don't have any proposal for this.
We are still working on it.
I will show you later on where we are proposing the OS mo-cups.
OK.
Last one, external identity providers.
So I will show you the current state in the command line interface.
So you try to log in with Sue, and it says authenticate with pin.
It provides some pin at a web page, and then it requests you to press enter.
So if you go to this web page in a browser and you input the code that is there,
you press on continue, then you come to the next screen where you are requested to
authorize this request.
Because, well, maybe it's somebody else that is trying to be you, and it's not really you.
So you authorize it, you press enter, and you are authenticated.
Nice.
And what about the graphical user interface?
It's not possible.
You cannot use it.
And here comes the application.
And here comes the first demo.
Yeah.
So I will input my username here.
OK.
You see.
You have your username here, and then the login button.
If you press it.
You are shown a QR code, a URL, and the login code.
So this QR code will redirect you to this web page.
And on top of that, we haven't finished this yet, but we will provide also our embedded
web browser alongside this, where you will be able to provide the login code and authorize
the request.
Thing is that, well, first of all, you are embedding a web browser inside the login screen,
which is maybe not a good idea for security reasons.
And then you also need to take into account that it's not easy.
So we are still working on it, and it's, you know, a thing to do.
So if I were to follow the workflow here, I enter the code.
OK.
I press and continue.
Now I need to authorize the request.
I'm requested for the PIN, for the password, sorry.
OK.
Now you are supposed to press on enter, and it will work.
Well, I will tell you we have a bug here.
A problem.
I haven't been able to solve it before the presentation, so it will fail, and it will
show you another screen.
But in reality, that would be all.
So you press done, and then you are authorized, and you are logged in inside the computer.
So what more?
OK.
So we currently have several authentication mechanisms.
But how do you select them in the graph?
How do you select them in the graphical user interface?
It's not possible.
There's no way.
So you are prompted for either the pass key or the smart card, and that's all.
You cannot select it.
No way.
But we already have a proposal for that also.
So I will come back again here.
I will need, OK.
You have the web login here, and you have this small key.
And this user, apart from the web login, also has the password authentication option.
So you can press it, and you are requested to enter the password.
You can come back again, say, OK, I don't want the password.
I want the web login.
And it takes some time, but it comes back.
On top of that, you are a user.
You authenticate the first time with a given method, let's say pass keys.
You log out, and the next time that you come back to the same login screen, it will ask you for the pass key, not some other method.
It will remind that you try to authenticate using the pass key and that you succeeded so that the next time the graphical user interface will ask you for the same example.
For exactly the same method.
Of course, you can change, but so that you don't have to start changing the method every time because there's some priority that always tries to do the same authentication method.
So in conclusion, we have here the software design.
It's more or less that GDM prompts the user for the login prompt.
The user will input the username and GDM will start upon conversation.
So when SSSD has already resolved the username and obtained the available authentication methods and all the data related to them, it will generate a JSON message and send it back to the GDM.
So GDM already has all the information for all the available methods and the prompts that it needs to provide.
The user will provide the information and GDM will come back and will generate another JSON message informing SSSD which method to use and which data the user input.
So if you want to know more about this topic, here you have a web page.
This is the design that we are currently writing.
It's still working progress, but for external IDPs, it's kind of more or less done, so we don't expect to change it much.
As a wrap up, so these are the high level requirements.
The user should be able to select the authentication mechanism.
It also should be able to use the previously mentioned authentication mechanism to authenticate.
On top of that, the previous attempt should be remembered so that the next time that the user comes, it's prompt for the same authentication mechanism.
And finally, the user interface shouldn't get in the way, so it should be easy and simple.
We don't need to start doing strange things.
The user needs to feel comfortable and it should follow the same workflows that he's used to follow in other applications or in the web browser.
So last slide, reference links.
So the first link is the design mock-ups that the NOMI team has prepared.
You have there almost everything except for the two or more smart card certificates.
This is still working progress.
On top of that, the second link is the link to the SSSD EDM interface that I mentioned previously, like two or three slides ago.
And finally, you have a copper repository if you'd like to test it.
We are building it for federal road height, so if you want to test it, well, I would wait one or two weeks more until we stabilize everything here, especially for external entity providers, but then you should be able to test it.
So that's all. Thank you, and do you have any questions?
Okay, so you are asking what happens if you are not connected to the Internet and, well, you try to authenticate.
Well, if you try to do an external entity provider authentication, you will not be able to do it because you don't have to enter.
Is there a way that I can connect to Wi-Fi?
You can.
Yes?
You mean in the login interface?
Yes, in the login interface.
No, I don't think so.
Uh-huh, no, yeah.
Good idea, yeah.
But maybe you can use another method that doesn't require Internet connection.
Yes, but then what's the point of even having the Internet login?
Like, if I need to remember my password and I have the ability to use a password which is less secure, then I just make the entire system even less secure by adding another way of logging in.
Yeah, but.
Well, not actually improving anything.
Okay, so you want to know.
I'm trying to criticize.
Yeah, yeah, yeah, yeah.
So I get your point here that, okay, you enabled the Web Login and you don't want to use another authentication method that is less secure just because you don't have Internet access there.
Then I would recommend you to use pass keys or smart cards because usually the user is cached there in the.
And is there like no network manager access in the login interface?
No, I don't think so.
Because that would make it like work.
We can discuss it.
Yeah, it's a good feedback.
I mean, there are certain potential issues with network manager like network manager also has access, for example, to VPN configurations.
So you would have to create a special interface for network manager that didn't expose secret information.
Yeah.
So this is actually a common problem that exists for quite some time.
And I've been talking about this at FOSDM in 2016 already when the, how they call these in hotels they have portals.
Yeah, yeah, before you connect to VPN, but you cannot connect to VPN before you go online and you need to be online to and then solve first this portal challenge.
So it's still the same problem.
You need to run browser effectively before.
So running network manager with the access to you potentially user private information before authenticate and then identify the user is another problem.
Yes.
We are not looking at that problem specifically within the context of this one, but solving ability to run the browser before the login will help us to solve some problems.
And I know that at least three major distributions are working on these set of problems, but it's question of prioritizing.
Yeah, I think that it should be solvable to run the browser securely.
Yeah, I think so.
Yes.
I mean, we have stuff to work in, but we'll take a while.
Yeah.
Right.
Yeah, first thanks for working on this.
Clearly, there's a lot of work to do.
Have you done like accessibility review like on this?
I mean for disabled people, especially and actually connected to that is, for example, I noticed that when you shown like the UI.
It was a bit far off from what people expect when they go to a website.
For example, like, for example, you shown like to select the factor notification factor was a small.
And the bottom right with the key icon, right?
It's not really what people are used to like when they go to websites.
So why is that essentially and indeed like how is that connected to an accessibility.
Okay, so the question here is whether we took into account the access to these ability people.
I'm more specifically when you are about to select the authentication mechanism that the icon is kind of a small and it's on the right side.
So I know there's been some people from the UX team working on this and I'm quite sure that if you go to the first link there and you provide your feedback there, they will take it into account.
Yeah, there's like going to no issues in the design team section.
There are actual these mocaps.
Yeah, so you can add your.
Yeah, yeah, and you can follow it and you know provide further feedback if you don't like it.
Yeah, we are still working on this.
So everything is like working progress as much feedback as we can get the better because we'll provide a better product for our customers to use.
I just want to make good that was more than a criticism.
No, no, no.
Search for rationale.
I'm not part of the UX team.
So I don't have the exact details.
Thank you so much.
Okay, sir.
First of all, thank you very much for your work as well as the presentation.
There was a picture of logging with security that looked like mocaps.
Are they already available or no, no, I guess you mean this one?
I guess you mean this one, right?
Yeah, it's still a mock-up and we'll work on it.
So we started with external entity providers
and we'll continue with the other two methods.
So I don't know when this will be available,
but we are working on it.
Philip.
Thank you.
Sorry, go ahead.
So of course you're primarily implementing,
integrating this first into a GDM course
because that's what you're working on.
But will you implement it in such a way
or when it is finalized and solidified,
can people who have different display managers
or even implement it all be able to implement that?
Because otherwise we'll be forced to either use GDM
or maybe SDDM.
OK.
So the question was whether other login providers,
like I guess KDE or some other one.
Like GDM maybe.
Yeah, if they will be able to provide this authentication
mechanism, the answer is yes.
They just need to follow this design.
So the PAM conversation is part of the LIPPAN,
which is kind of a standard nowadays.
And the JSON message, it's defined here in this design page.
So the graphical interface just needs to follow this
to be able to implement it.
It's not implemented, but if somebody
wants to already start implementing it,
we are fine with it.
I mean, we don't have any problem.
We are providing Nomi because we are using that in Fedora.
But anybody else can come here and implement their part.
So they're going to have that tight level of integration
where you need to have it?
No, no, no, no, no, not at all.
We just need a PAM conversation there happening
and to follow this diagram.
That's all.
OK.
Thank you.
Yeah.
Go ahead.
I wonder if, for example, I have a laptop set up
with both password authentication and a second PAMD
module for Trezor, which is like this USB thing.
And I can click the button and I can log in.
And that allows me to choose whether I type in my password
or I press the button on the Trezor.
And you have it so that you have two different flows
for the authentication.
Do you think it would be possible to set it up
so that you could either type in your password
or tap your smart card to have it win a single flow
without the user selecting the flow?
If you have a smart card reader of an NFC device
on your laptop, then when the password prompt is showing,
it would potentially be possible for the user
to tap their smart card even though the password
prompt is showing without the user having to click on it.
I'm like, I can type my password or log in
to have a think of it.
Yeah.
It's the same on your phone.
You can make your symbol or you can just use your fingerprint
scanner.
You don't need to choose what you want.
This is a bit more complicated than the case of GNOME and GDM
because GDM uses different PAMD stack configuration
for cases when it detects a smart card.
And it uses GDM smart card.
Yeah.
And that one explicitly includes expectation
that smart card is engaged.
So it will not use the one that uses just the password
in that case.
Your device, if it's supported by a separate PAMM module,
yes.
Then it will work in the stack of the normal password
basis authentication.
It will work with this one.
This one will just be skipped completely
because your module will handle it.
That's how PAMM works.
So the whole concept here, depending on PAMM,
basically being used for everything.
So time's up.
Andreas, do you want to say something like that?
Yeah.
Do you plan to extend the PAMM conversion of how
to talk to PAMM because that's still very limited?
And one problem, for example, if you have multiple domains
and have one to have the selection,
that the user is able to select this domain,
that's the problem to present.
So you actually would need to extend the PAMM conversation
actually to the first.
So you can use this to start your life.
We can use the same JSON format.
It already allows you to do that.
Yeah.
Can I define a primary plausible which is part of PAMM
that's not fully linked?
And so they can go to that.
So it's not a classic on multiple terms.
OK, time's up.
I think we can continue this discussion outside.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.