Okay, so the next speaker of the day is Ike Pedrosa and he's about to tell you how to
enhance palm communication.
So Ike?
Okay, hi everybody.
So it's a pleasure to be back here after a year.
So the topic I will be presenting today is related to the
feature that I was presenting last year which was focused on enabling
passwordless authentication through GDM and any other
graphical user interface.
So that time what I was presenting was more related to the
graphical user interface or the mocaps that we were developing.
And this time I will do a deep dive into the ease on base approach
that we have developed to enhance the palm communication.
So what am I?
My name is Ike Pedrosa.
I'm an engineer at Ike and I've been working here for the last five years.
My main focus is on identity management.
So I usually work on SSD, shadow and Linux projects.
Indeed, I'm one of the upstream antennas of the shadow project.
But I also have contributions to other projects.
So in the past, I used to work as a software engineer in the
automative industry.
More specifically with a telemetic control unit.
And then I moved to the 3D printing industries where I work with the
industrial 3D printing.
Well, indeed, more than one but you can get the idea.
So the agenda for today.
I will start with a small introduction on what is our current
problem and the solution that we have designed.
Then I will continue with the design, the actual design with a
sequence diagram that you will be able to see.
Later on, I will showcase a demo with some client application that I have
developed just for this presentation.
This is my writing in Rust.
It was quite fast to do compared to see at least.
Later on, I will move to show a little bit of this pump client code.
And I will finish with the conclusion.
So let's start with the problem.
So when the pump was created, there was just the authentication
with password or no password at all.
And this was given from just a given pump module.
But nowadays, we have a more than one authentication mechanism like
Ex90T provider or Pasky.
And they are all available from this same pump module.
In this case, PMSS, which is provided by SSD.
So what we want to achieve is that the user is able to select the
authentication mechanism that he wants to use during the authentication
from the graphical user interface.
On top of that, he follows a set of context tower prompts to
enter the credentials that he needs to enter to get the authentication.
And this way, he will enter into the system.
For that purpose, we need the pump module and the client
to communicate in some way to advertise the authentication
mechanisms and the prompts that are needed for it.
So let me show you a video.
I hope it's available.
So this is from my talk last year.
I will enter here the login name.
And right away, the user will be provided with a login interface
where he will be able to authenticate with an external identity
provider.
So there's a URL that he can follow or use the QR code.
And I'm going to offer this request.
On top of that, we have the login code, which is available there.
You just need to enter that and get up.
And with that, you are almost ready.
You need to click on continue and also write the request.
OK, so that's all.
And the user should be able to authenticate.
This is happening later on on the video.
And moreover, the user should be able to select the authentication
mechanism that he wants to use.
So instead of an external identity provider, if he wants to use
it, and this is available, he must be able to select it.
OK, T solution.
OK, so what we have here is that I created a JSON-based approach
to provide this information.
Well, because it provides enough detailed information
to authenticate the user.
And on top of that, you can customize it.
So in this case, I was taking into account that pass key,
external entity providers, smart cards, and passwords are possible.
But well, and we also need to provide the prompts
that are context hours.
So it's not the same to do a pass key authentication,
where you are requested to enter the pin,
or the external entity provider authentication,
where you just don't need to enter anything.
Just wait for the authorization to come from the external entity provider.
This is built with extensibility in mind, so that if at some point
we need to add additional prompts, or an additional
authentication mechanism, this is possible.
And well, all this information is encapsulated
in the pin binary prompt.
And I will speak about this a little bit later.
So let's talk a little bit about the design.
So here, you have this sequence diagram,
and I would like you to focus on the last part of the conversation,
which is happening here.
What do we have there?
Well, SSSD formats IE some message with the authentication mechanisms
that are available for this user,
and it encapsulates all these information
in the pin conversation through the pin binary prompt.
GDM provides this information to the user,
and the user just needs to select the authentication mechanism
that he wants to use, and input the credentials.
Later on, GDM generates the JSON message with the answer,
which will contain the authentication mechanism that has been used,
and any credentials that are used for this authentication to happen.
And this returns back here in the pin conversation,
so that SSSD has the information to process this request.
If you want to know more about this,
there's a link here, which did the same page.
So, what is the use of message that we have generated?
On the one hand, we have the request, which is here on the left side.
It contains all the authentication mechanisms that are available for this user,
and on top of that, and on other words,
like the name, the role, whether it's selectable or not,
and additional prompts or instructions that the user needs to follow
to authenticate this request.
And on top of that, we have the priority.
So, in this case, we, or SSSD,
refers to use the first, the second role,
as the priority, as the mechanism for authentication,
instead of the first one.
You can use whichever you want, or the user can use it,
but the priority is there.
And the reply contains the authentication mechanism status,
which, whether the information was correctly input or not,
the mechanism that was used,
and additional data that may be necessary for this to happen.
It's kind of abstract, so I'm giving you some examples here,
which are, I guess, our better.
So, in this case, we have a mechanism which is the password one,
and we have the name, the role, and whether it's selectable.
This three attributes are our present in all the, on the only mechanisms.
And on top of that, we have the prompt.
So, for the password, case, it's password.
Yes, for the user to enter the password in the field, which would require it.
For external entity providers, we again have name,
raw and selectable, and then some additional prompts,
like they in a prompt, which is the login,
that there was a button that you had to put,
to get the external entity provider case to login.
On top of that, you have an additional message,
which is login online with another device.
And finally, you have the UI and the code.
These are necessary for the authentication to happen.
In the case of Pasquille, we have name, raw, and selectable again,
and then a set of prompts and information that are necessary for this.
So, we have, like, insert security key,
because you will need to insert the key to authenticate,
whether you are requested to enter the pin or not,
because some users, or some organizations,
may decide not to use the pin request,
the number of pin request left.
So, fiddle to devices, you shall have a number of eight attempts,
and in case you enter incorrectly the pin eight times,
it gets blocked and you lose all your access to everything.
So, we need to inform the user, in this case,
that this may happen, and that they need to be aware of it.
And finally, you have the ping prompt and the touch instruction,
like security key pin and this touch device.
And finally, we also have the priority.
In this case, Pasquille is the most priority authentication mechanism,
but the user can use another one.
And finally, the user, in this case, for this reply,
it has decided to use Pasquille as an authentication mechanism,
and the pin is present here, like one, two, three, four, five, six.
Yeah.
So, now, let's show you a little demo.
Let me go back here.
So, can you see this screen correctly?
Okay.
So, this is the Pumhurst client application that I created.
We will try to authenticate the user.
You see this authentication protocol.
In the back end, we have SSSD managing everything.
And before I continue, I need to, sorry, to connect the device.
Okay.
So, we are done.
I will run the application.
First thing we need to enter is the login name.
And now, the Pumhurst client application has received the following JSON message.
Where we have the password mechanism available, and also a smartcard.
We solved the information that is necessary for them to happen,
plus the priority, which in this case is Markard or Password.
The JSON message was successfully passed,
and we are requested to select the authentication mechanism that we want to use.
So, I will select a smartcard.
I am requested to enter the smartcard.
As it is already entered, I will just press enter, enter the pin.
And that's all.
So, the application sends back this JSON message with the smartcard mechanism
and then the authentication information that it is necessary for it to happen.
The authentication successfully finished, and the session was open.
So, if I check it, I am eager, which is the user I try to use.
Now, let's try again, but this time we will use Passwords.
So, we again receive the JSON message with all the information.
Probably this is the same message that we received before,
because in this case everything is the same.
I will select Password.
I am requested to enter the Password.
And that's all.
So, the pump price client application sends the information that Password was selected
and the Password that I input here.
So, if I check it, I am eager.
That's correct.
Just in case, you want to check this or use this application.
I import you that I didn't follow any security measure, and it leaks.
So, I will then use it in a production environment.
So, now let's move to the following slide.
Okay, a little bit of the pump client code.
So, this JSON message is generated in a following way.
We have a parse function that takes care of everything.
It just you input the information and it generates the message.
Sorry, it deciralizes the message.
And the code is quite small, because we take care of this thread that already deciralizes
and serializes the data, the data.
If you create the correct data structures in the JSON application.
So, nothing else is needed.
Just that.
And for Martin, the message with the reply.
I think I could have improved this and of the message so that I just had four or five lines of code.
But I didn't have the time because I was in a rush.
So, what I decided was that I would generate one message per authentication mechanism.
So, first we check whether this is password or pass key or smart card authentication.
And then there's a function that generates the message, which is available right here.
And it contains, well, the authentication mechanism that was used.
And whether, well, in this case, it was password.
The password that you need to input for the user to authenticate.
Well, some additional information.
I just de-pump rangering prompt message to encapsulate all this information.
And I had a hard time understanding how it worked.
So, I had to, well, there wasn't much information available on the internet.
Or I wasn't able to find it.
So, I had to understand it by the ascending messages from one side to the error.
And what I found is that, well, we have first and structure with a header, which contains the length.
It's a UI in 32.
A chart with a tie and another chart with the data.
And we also have a string with the protocol name, which is 64 bytes long.
An end with the version and a pointer to the JSON message.
So, in my machine, which is x8664, this translates to the following, which is first length with four bytes of data.
In big and the, this is important information because my machine is little and everything is in this and darkness,
but not the first part, which is the length.
Then I'm assuming there are two bytes for data and another two bytes for the type.
I'm not completely sure because these fields were empty, my request so I couldn't verify them.
Then we have the protocol name, which is 64 bytes length.
Then we have the version with another four bytes, a padding of another four bytes,
and a pointer to the JSON message, which is eight bytes long.
In total, it took 88 bytes to pass all the information.
And, well, let's finish with the conclusion.
So, we are using these JSON-based messages to communicate the desired information from the PAM module to the PAM client application.
We build this with the accessibility mind so that if at some point a new feature comes where we want to have additional problems or a new authentication mechanisms,
we can do it quite easily without breaking our head.
And the idea is to have the lowest possible effort from the developer site so that well, this is kind of easy to understand.
The JSON messages have been here for years and they are kind of understand that.
Some reference links before I finish my presentation.
The first one is the SSD GDM interface design that I spoke out previously.
This contains not just the diagram and the JSON messages that I have been showing you during this presentation,
but also some background on why we are doing this.
Moreover, there's a blog post I wrote specifically for this presentation, which contains some of the background that I explained here.
It was small one because what I wanted to specifically explain in this blog post is how to replicate this environment.
It contains some information with all the repositories that you need to use.
They are also available here and I will mention them, but I would recommend you to follow the blog post.
So I created a copper repository with the SSD update, but if you don't want to use it, you can also use the SSD development branch.
On top of that, as I mentioned before, I also brought a PAM class client application and the repository is available there.
And finally, I was using some API bindings for the PAM in Rust.
And what I found is that the PAM binary prompt wasn't implemented there, so I had to implement it myself.
I opened up a request until yesterday it hadn't been approved or even reviewed.
So, whenever it comes that you want to test this, you may need to install the PAM Rust API bindings from my repository.
And well, that's all. Thank you everybody for coming and I hope you enjoy it.
So, is there any question from anyone?
Yeah, yeah, anything.
So, PAM binary prompt is not widely used.
And the way it used is that in the PAM module there is something and in the client is something there talking the same protocol.
So, the question is, at what point do you need this JSON extensibility?
And how do you tell whatever site needs this, what API you're actually providing as a PAM module for the client?
Otherwise, we use JSON in the first place.
Okay, so what we want to achieve here is that we are going to use this for graphical user interface.
And we need rich exchange of messages between the PAM code, the PAM module and the PAM client.
In order to do that, we need to provide a lot of information.
And the best way to achieve that is using the JSON message.
So, we could have done this with a simple PAM conversation.
But we could have, we would have need several conversations to happen sequentially.
And this could be a little bit, how to say.
And knowing for the user to wait until all the information is transferred in order to process the information.
So, that's what we do is just create one conversation between the PAM module and the PAM application.
We don't need to create like four to five different conversations.
Yes, because instead of using the full mechanism, you just want to use another one.
I don't know if I answered your question.
We have a little bit of time. So, is that any other question?
Oh, yeah. Okay, coming over.
Did you try or think about it to add this functionality to PAM itself, not to add just another layer on top of PAM.
For example, also to support terminal lockings.
Can you repeat the question?
So, did you think about adding this functionality of being able to, for example, support pass keys to PAM itself to the protocol and not to just to add another layer of complexity?
Yeah, this would be possible, but we would be coming back to the old way of doing things where we had just one authentication mechanism for a user provided by just a PAM module.
But in this case, what we want to achieve is that we have a PAM module providing several authentication mechanisms.
So, in reality, it's already possible which what we have currently without any change to do pass authentication.
But you would be able to do that just that, pass key.
So, you use the graphical user interface and you will be requested to input the pass key data.
And you are not able to change that.
So, if you have another mechanism available, like pass work or external entity provider, you are not able to change it to this other mechanism.
Any other question?
Okay, so, look at that.
Thank you very much.