WEBVTT 00:00.000 --> 00:12.200 It's good to be back here in Brussels for for them today we are going to present 00:12.200 --> 00:18.440 a journey how the possible result indication in GDM feature that we are currently working on. 00:18.440 --> 00:24.440 So let's start with myself so my name is Iker Pedroza I'm a senior software engineer working 00:24.440 --> 00:31.900 at Red Hat my main identity is about identity management and well I work in 00:31.900 --> 00:38.240 projects like SSD shadow and Linux pump I also maintain shadow upstream and well now 00:38.240 --> 00:45.880 John will present himself so hello everybody I'm John this is my first time at first 00:45.880 --> 00:53.440 then I work at Red Hat in the desktop team and I work in GDM which is the login screen 00:53.520 --> 01:01.120 and also no remote desktop and related stuff one thing about me is that last year I started 01:01.120 --> 01:12.520 playing commander the magic the gathering TCG and I love it okay so let's take a look 01:12.520 --> 01:17.440 at the agenda we will start to speak in about Gotis pass was there authentication I'm given 01:17.440 --> 01:22.840 a little bit of an introduction then we will move on about the GDM authentication and how 01:22.880 --> 01:28.880 it works currently we will explain the limitations and the solution that we are working on 01:28.880 --> 01:37.000 and we'll find finish with a conglash so regarding partners authentication what it is 01:37.000 --> 01:43.480 well it is a way to authenticate a user without using a password okay that makes sense 01:43.480 --> 01:49.120 it usually involves multifactor authentication like appearing a figure print or fashion 01:49.120 --> 01:56.560 recognition and singers I know it extrinses the security and improves the user experience 01:56.560 --> 02:03.040 by relying on public cryptography instead of user brains to retain hundreds or even thousands 02:03.040 --> 02:11.360 of secrets and these reduces the risk of adaptable rich and reduces the fees interests so in 02:11.360 --> 02:17.360 free API and SSD we currently support three different mechanisms for passwordless for 02:17.440 --> 02:22.720 centrally managed users the first one is pesky or the fiddle to token that you see there 02:22.720 --> 02:28.400 the second one is a smart card or PIV and finally we have a standard ID providers that we provide 02:28.400 --> 02:34.400 through the of two protocol so now I will give the floor to John who will explain the current 02:34.480 --> 02:50.640 situation so GDM authentication so what's GDM so GDM is the 02:50.640 --> 02:56.320 GNOME display manager and is the program inserts of authenticate in the user graphically 02:56.320 --> 03:03.040 and a starting user session so usually when you use it you would do a password authentication 03:03.040 --> 03:11.040 as you see here but it can also do a smart card authentication if you enable it in GDM settings 03:11.040 --> 03:15.920 and map a smart card certificate with a user you might be able to get these certificates list 03:15.920 --> 03:22.880 insert your pin and authenticate and also it allows to do finger print authentication the same thing 03:22.880 --> 03:30.160 you have to enable it in GDM settings you map a fingerprint with your username and then you see 03:30.160 --> 03:34.480 this little message there that is saying that if you place your finger on the reader you might 03:34.480 --> 03:40.560 authenticate with your fingerprint so now probably most of the people here is wondering 03:40.560 --> 03:47.760 and how does GDM authentication so well I'm going to explain it now so what you see here actually 03:47.760 --> 03:54.480 is the GNOME cell the GNOME cell is the program that renders stuff and shows it on the display 03:55.200 --> 04:01.120 and this is a special GNOME cell is the greeter GNOME cell that is running as an 04:01.120 --> 04:07.680 GNOME privilege user called the GDM greeter user so to authenticate we need some permissions 04:07.680 --> 04:15.600 that the GDM greeter user doesn't have so how does it do the authentication well obviously 04:15.600 --> 04:23.840 communicating with GDM so GDM for its greeter GNOME cell is going to create to 04:23.920 --> 04:30.240 private debug servers one to communicate with the GNOME cell and the other one to have a 04:30.240 --> 04:35.360 panconversation and it's private because some sensitive information is being exchanged 04:37.120 --> 04:43.920 so now moving on the GNOME cell site so in this private debug server GDM is going to expose 04:43.920 --> 04:52.640 a user verifier interface and it's going to be used by both sites so usually when you are going to 04:53.600 --> 04:58.000 authenticate your select your user and then the GNOME cell is going to call the 04:58.000 --> 05:04.960 Inverification method with the authentication the pan service that is going to be used if 05:04.960 --> 05:10.720 you are doing password authentication it will pass GDM password and pan service but if it was 05:10.720 --> 05:20.320 using a smart authentication it would use the GDM smart car pan service then GDM is going to send 05:20.320 --> 05:26.960 some signals for instance secret info query is the signal that makes non-cell like display this 05:26.960 --> 05:33.920 entry asking for the password but it could also send the signal info to show some extra information 05:33.920 --> 05:40.960 on the display now once the user insert the password and press this enter then non-cell is 05:40.960 --> 05:48.640 calling answer query with the password and then if it succeeds GDM is sending verification complete 05:48.640 --> 05:54.560 and a new user session will be started now moving on the other side the pan conversation 05:55.600 --> 06:06.000 so GDM to do a pan conversation it for its pan service that is using is going to spawn 06:06.640 --> 06:15.120 process that is called GDM session process so GDM is communicating with this process 06:15.120 --> 06:23.760 through the private divorce server that created before and in this case the session worker is 06:23.760 --> 06:33.200 exposing a worker interface and GDM is exposing a worker manager interface so usually for the 06:33.200 --> 06:39.600 pan conversation GDM is going to call different methods to start the different stages of a pan 06:39.680 --> 06:47.200 conversation so it would call initialize and authenticate, authorize, establish credentials 06:47.200 --> 06:53.280 and open and at the same time the worker is going to set up a handler to receive the pan messages 06:54.160 --> 07:00.480 so it could receive a message like pan text info which is making the session worker call 07:00.480 --> 07:06.160 the info method which is going to make non-cell and meet the info signal that is going to make 07:06.160 --> 07:14.000 display this extra info text and it could also receive the pan prompt echo off message 07:14.000 --> 07:20.160 that makes the session worker call secret info query that makes GDM send the signal 07:20.160 --> 07:25.520 secret info query in the non-cell site that's the one that is asking for a password and then 07:25.520 --> 07:30.480 was the user and says the password and answer it the password would be return it in this method 07:30.480 --> 07:34.720 and then the pan conversation should go on and succeed or fail 07:40.000 --> 07:44.160 okay thank you John so now let's speak about the current limitations 07:45.360 --> 07:51.600 well the problem the core problem here is that GDM is blind it reads every authentication request 07:52.400 --> 07:58.720 as a text exchange that's fine for username and password but not for other authentication mechanisms 07:59.680 --> 08:04.640 we also have that some pan modules like SSD support different authentication mechanisms 08:04.640 --> 08:10.880 like passkeys or external entity providers and they require a special request one of them is 08:10.880 --> 08:15.200 does the device or a web view well currently GDM doesn't support them 08:16.400 --> 08:21.440 then at on top of that in-bcore organizations you can authenticate yourself through different 08:21.440 --> 08:27.920 methods like smart cards or passkeys but GDM doesn't advertise these mechanisms so the user 08:28.480 --> 08:33.680 is prompted for a mechanism and they need to use this they cannot choose the one that they would 08:33.680 --> 08:40.080 prefer to use in addition some mechanisms are functional but the UX is very limited in the case 08:40.080 --> 08:46.480 of the passkey mechanism well part of the test is not shown on the screen because the level is not 08:46.480 --> 08:54.720 big enough and finally without supporting new methods that require extending the UI it is impossible 08:54.800 --> 09:00.560 to support a serial trust architecture and this is our equivalent for us to support so now I'm 09:00.560 --> 09:04.160 giving back the floor to John that will be a speaker or the solution 09:09.200 --> 09:15.840 so here there was some things that need to be improved so some work has been done to try to 09:15.840 --> 09:26.160 improve this situation so it's been defined a new pen extension message so Pum has a message type 09:26.160 --> 09:31.840 that it's called Pum binary prompt and this is just a stream of bytes so if the Pum module that 09:31.840 --> 09:41.440 is sending message and the handler agree on specific format they can have an extension message 09:41.440 --> 09:48.240 so in this time it's been defined a new extension message that it's called custom JSON which 09:48.240 --> 09:58.320 just allows to send and receive JSON messages so now go in back to the conversation where 09:58.320 --> 10:04.880 the session work is having with GDM then it could receive a message of type Pum binary prompt 10:05.520 --> 10:11.520 and then the worker might parse it and detect that this is an extension message of type 10:11.520 --> 10:16.880 custom JSON and that's making the session worker called the new method called custom JSON 10:16.880 --> 10:23.760 request which is just sending the JSON message to GDM and at the same type GDM is exposing 10:23.760 --> 10:30.160 another interface that is the user verifier custom JSON interface that emits the request signal 10:30.160 --> 10:36.640 so now norm cell has this JSON message that's whatever you have to do and then it's going to 10:36.640 --> 10:43.440 reply with the JSON message yeah like a different JSON message for the reply which would be 10:43.440 --> 10:48.880 return it in the method and then the workflow would be the same and it could see it or fail 10:50.960 --> 10:57.520 so what supports this custom JSON extension message so it's supported by SSSD and LD 10:58.400 --> 11:04.800 to use it with SSSD you would have to use the GDM suitable of Pum service and for LD 11:04.800 --> 11:13.440 there's the GDM of the Pum service now if you use SSSD the JSON message format would be something 11:13.440 --> 11:19.200 like this so the Pum module is going to send a request with the JSON message that is like 11:19.200 --> 11:26.080 saying the authentication mechanisms that are available for a specific user then norm cell 11:26.080 --> 11:32.480 gets that information and does the thing and then answer visualization message which sets the 11:32.480 --> 11:38.800 selected authentication mechanism and the extra parameters required for authenticate and this is 11:38.800 --> 11:44.080 great because in the past we had different Pum services for different authentication mechanisms 11:44.080 --> 11:49.840 and now with one single Pum service we can handle different authentication mechanisms which is great 11:50.080 --> 12:01.040 now this result of these are some UI changes so now the mechanisms are selectable so in the 12:01.040 --> 12:08.720 past you could select your session type now you can also select the mechanism that is supported 12:08.720 --> 12:16.960 by the user that you selected also for a smart authentication the UI has been improved because 12:16.960 --> 12:23.040 the content of the certificates was in 15 properly in the buttons so now the buttons have been 12:23.040 --> 12:29.040 increased and they provide a better UI to display the organization the common name of the certificate 12:32.000 --> 12:38.080 also new pesky mechanism now it supported graphically so I'm not going to explain 12:38.080 --> 12:48.400 about it because a few tags already have expanded very well and also we support the external 12:48.400 --> 12:56.640 identity provider it's called he weblogging so through through a link you access to a website 12:56.640 --> 13:01.360 and you authenticate externally with this identity provider and once you're done you click on 13:01.360 --> 13:10.800 done and the workflow authentication goes on and the last change is the fingerprint it's been 13:10.800 --> 13:18.080 disabled disabled in the login screen and it's only enabled in the login screen and also now 13:18.080 --> 13:27.760 if display a nice icon to inform when the fingerprint sensor is being active and I'll go into try 13:28.640 --> 13:30.480 life demo 13:51.360 --> 13:55.520 well I wasn't expecting this way of seeing the things 13:58.240 --> 14:06.800 but I'm going to try so I have a pesky inserted so I can select the pesky user that has enabled 14:06.800 --> 14:16.800 pesky and then well I'm not sure because from here it's not going to work but well I can insert the 14:16.960 --> 14:33.040 pin and then it's requested me to touch it and succeed and I could throw it no I'm not going to try 14:33.200 --> 14:41.920 nothing else because it worked okay so 14:50.720 --> 14:57.280 so somebody told us this week that this room was curved well we suffered the curse so now regarding the 14:57.360 --> 15:08.000 concussion okay the availability of this feature well we recently released SSD2.12.0 it is available there 15:08.640 --> 15:16.560 and then we are trying to get it into nom if 50 we have two merge requests that are pending review 15:16.560 --> 15:21.760 so we are waiting for some love and feedback there if you have it please go ahead 15:22.400 --> 15:24.080 yeah I'm not looking at anybody here 15:27.920 --> 15:35.040 so regarding the future announcements to this feature so the first one is that we want to add an embedded 15:35.040 --> 15:41.360 web view to the login interface so that the user can authorize the request from the same 15:41.360 --> 15:49.760 system that they want to login in addition the standard pump conversation is very read and we are 15:49.760 --> 15:55.520 thinking that by using a private file the scriptor we can pass complexiation objects 15:55.680 --> 16:02.880 or multi-step challenge responses without hugging the existing pump interface and finally 16:02.880 --> 16:10.400 now that XOR is being removed some of the GDM bits are being moved into system D like starting 16:10.400 --> 16:16.320 stopping the graphical interface or graphical session sorry or doing the authentication well as part 16:16.320 --> 16:22.640 of these changes we are also looking to move all these design into system D so that other 16:23.200 --> 16:30.720 packages like KDE, poll kit or of the can use it and we can have a common interface for all 16:30.720 --> 16:36.880 these software this will probably become a warning but we are still in early stages if you 16:36.880 --> 16:43.440 have any feedback just click on the link and you will be able to see the GitHub discussion 16:45.920 --> 16:52.560 so some reference links here the current SSD GDM interface is available in SSD.i 16:53.120 --> 16:58.640 it's the first link there I also brought a blog post last year for my presentation here where I 16:58.640 --> 17:04.160 explain the enhancements that we are doing through the pump conversation and finally there's a 17:04.160 --> 17:10.800 cover repo that you can use to download the latest updates for SSD, NOMI and other related packages 17:10.800 --> 17:18.960 to make this feature work so some great it's here the first one is to ray a stroke 17:19.120 --> 17:25.360 who has started working on this feature with me he moved to another project and John came to help me 17:25.360 --> 17:32.080 so we would like to thank him and also Marco Trevison or Trevino who is available here in this room 17:32.080 --> 17:39.200 who is doing part of the reviews so thank you very much for joining us here and if you have any 17:39.280 --> 17:41.200 question now this is the right moment to do it 17:41.200 --> 18:11.120 so the question was about if you authenticate with Pascal with Password the Password 18:11.440 --> 18:19.280 the keywing is unlocked and if we authenticate with a different method the keywing might not be unlocked 18:19.280 --> 18:25.760 so how do we handle that and the answer for that is that I don't have experience with the keywing 18:25.760 --> 18:29.680 so I don't have an answer but maybe someone here in the room might know better 18:41.120 --> 18:45.600 the system which creates secrets which are independent of the integration system which is something 18:45.600 --> 18:51.040 we don't know yet we don't have yet we need some kernel world we have lots of stuff after 18:51.040 --> 18:56.800 you need more of that yeah so the answer is for the moment keep it locked but this current work 18:56.800 --> 19:03.280 to find this solution to get it unlocked in different ways 19:11.120 --> 19:21.840 is that something you guys want to do with the question with the spiffy I don't know what 19:41.440 --> 19:59.200 so the first question is about whether the identity provider is external or internal to the 19:59.200 --> 20:05.600 system so the answer is external FAPA supports several different external identity providers 20:05.600 --> 20:12.960 as long as they support of two protocol we can go with them so we use that and it's external 20:12.960 --> 20:15.680 and the other question I didn't get it sorry maybe you can repeat it 20:20.880 --> 20:31.520 increase the attack surface for the login manager so you say if the login manager what does 20:31.520 --> 20:42.640 with the surface it's exposing more attacks I guess I guess so but I don't know about them 20:47.360 --> 20:56.560 when we add the web view at some point we'll need somehow to block some of the requests 20:56.560 --> 21:03.360 because some people might use the system for malicious uses before logging into it so yeah we need 21:03.360 --> 21:09.680 to find a way to block this request that are malicious or that come from people that don't want 21:09.680 --> 21:15.920 to actually log into the system since the main problem here is about integrating the web view 21:17.120 --> 21:22.320 you know a web browser into the login interface first we need to solve that and then we need to 21:22.320 --> 21:27.200 think about how we can block those requests 21:41.760 --> 21:47.520 so the question is whether we use any of these systems when we are at home the answer for me is 21:47.520 --> 21:53.680 no currently I use you know you I have local user so I don't use any of these mechanisms this is 21:53.680 --> 22:00.160 for central human as users but probably soon in several of the organizations where I take part 22:00.160 --> 22:06.160 of we'll move to passwordless because this is our requirement for what for the company I work for 22:06.160 --> 22:12.320 for Red Hat because it's coming from the US government so at some point very soon I hope we'll move to them 22:17.600 --> 22:22.480 but you mentioned if I got it correctly that you removed the fingerprint option from the 22:23.120 --> 22:30.880 as an application of only as a look screen yeah so the the question was we removed the 22:30.880 --> 22:36.320 fingerprint authentication from login screen and it's only enabled in lock screen why and yeah 22:36.320 --> 22:43.920 the answer is because it's using some biometric sometimes it's not like if it's not working 22:44.880 --> 22:52.480 completely fine and sometimes if it's not completely secure for the moment so we've decided to 22:52.480 --> 22:57.360 use it only for the lock screen which other oasis I think use it as well 22:57.360 --> 23:17.040 so I want to kind of reflect on the question about is it making the GDM login less security 23:17.040 --> 23:24.240 we expose external identity provider authentication so there are two ways of using it the one that 23:24.240 --> 23:32.560 was shown on the screen with the QR code so it's no different from the way how you login with 23:32.560 --> 23:42.000 the passport in terms of exposure for the GDM because all you see isn't as a picture right all the 23:42.000 --> 23:49.280 operation happens on the other device that scans this picture and launches their browser so they 23:49.280 --> 23:57.520 suffer meaning your phone is on that tag but it's on that tag anyway if you're forced to use the 23:57.520 --> 24:08.000 identity provider to login when the embedded web view gets there the problem is yes you have to 24:08.960 --> 24:18.560 block certain requests answer from Microsoft developers they failed so they try it and fail 24:18.560 --> 24:26.960 and fail they gain so people will happily watch videos by going to the let's say Google identity 24:26.960 --> 24:32.960 provider and then press and links and go into the main Google site and then select in YouTube and 24:33.920 --> 24:40.880 in during their life without being registered this is one of the examples where a technical solution 24:40.880 --> 24:48.640 might be done but it will fail because there's also an organizational solution that has to be in place 24:49.360 --> 24:57.680 policies exist not because they have to exist because they cover for places and for the 24:58.320 --> 25:04.160 things that technical solutions might not be able to cover completely so it's a combination of 25:04.160 --> 25:12.960 operations in any operating environment where IT organizations work policies exist for a reason so 25:14.640 --> 25:22.320 of course you can spend you can spend years fixing these kind of problems but there will be 25:22.320 --> 25:29.440 people who will get through them sometimes at some point you have to stop and think about maybe 25:29.440 --> 25:38.480 better interfaces and better ways of providing it and in many cases the external IDP is a stop gap 25:38.480 --> 25:45.600 simply because we don't have a better hardware to or availability of a better hardware to do the 25:45.600 --> 25:53.200 passport list authentication things like we're described in the previous talks about using the 25:53.200 --> 26:03.680 NFC or BLA to negotiate communication with the hardware tokens without insert and them and the 26:03.760 --> 26:15.520 USB these are one type of solutions for those so it's in fact it's a huge huge topic but 26:15.520 --> 26:22.400 that goes into a completely non-technical area yeah and I'm taking time from myself 26:28.880 --> 26:29.680 thank you guys 26:33.680 --> 26:36.160 you