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