Skip to content

Commit 3675076

Browse files
ikerexxeikerexxe
committed
design pages: Passwordless-GDM integration
Passwordless authentication from the GUI. Signed-off-by: Iker Pedrosa <ipedrosa@redhat.com>
1 parent dd73964 commit 3675076

File tree

2 files changed

+255
-0
lines changed

2 files changed

+255
-0
lines changed

‎src/design-pages/passwordless_gdm.rst

+243
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,243 @@
1+
Passkey authentication Kerberos integration
2+
=======================================================
3+
4+
Related ticket(s):
5+
------------------
6+
* https://github.com/SSSD/sssd/issues/7069
7+
8+
Problem statement
9+
-----------------
10+
Passwordless authentication is becoming increasingly popular. SSSD and FreeIPA
11+
already provide several authentication mechanisms which make use of it:
12+
`Smart Cards <https://sssd.io/design-pages/smartcards.html>`__,
13+
`External Identity Providers <https://freeipa.readthedocs.io/en/latest/designs/external-idp/external-idp.html>`__ (EIdP)
14+
and `Passkeys <https://sssd.io/design-pages/passkey_kerberos.html>`__.
15+
Unfortunately, the integration of these mechanisms into the graphical interface
16+
leaves much to be desired. Some of them may work in a degraded mode, while
17+
others can’t be used at all.
18+
19+
SSSD and the GUI should be better integrated to make all these authentication
20+
mechanisms effortless for the user. This would increase the overall security of
21+
the system, by providing the benefits of these authentication mechanisms, i.e.
22+
passwordless, MFA, etc.
23+
24+
SSSD and `GDM <https://wiki.gnome.org/Projects/GDM>`__ are working together to
25+
provide a set of interfaces that can be used to enable these authentication
26+
mechanisms in Linux’s GUI. While the initial work targets SSSD-GDM integration,
27+
the objective is that these interfaces can be used by any other desktop
28+
environment.
29+
30+
The use of new tools to authenticate users, such as 2FA, U2F and FIDO2, is
31+
becoming increasingly popular. Currently SSSD provides local authentication of
32+
a centrally managed user with passkeys, but it doesn't provide any way to
33+
authenticate remotely to a system. This diminishes the value provided by SSSD
34+
in some environments like big companies and governments, where remote
35+
authentication is a common pattern.
36+
37+
Use cases
38+
---------
39+
* As a centrally managed user, I want to choose the authentication mechanism
40+
to login from the graphical interface so that I can select the one that best
41+
suits my needs.
42+
43+
* As a centrally managed user, I want to use an external identity provider
44+
(IdP) to login from the graphical interface so that the user interface is
45+
easy to use and consistent across all authentication mechanisms in the
46+
distribution.
47+
48+
* As a centrally managed user, I want to select the smart card identity to
49+
login from the graphical interface so that the authentication is performed
50+
with the correct credentials.
51+
52+
* As a centrally managed user, I want to use a passkey to login from the
53+
graphical interface so that the user interface is easy to use and consistent
54+
across all authentication mechanisms in the distribution.
55+
56+
* As a centrally managed user, I want to get notified when the passkey
57+
authentication has been performed locally so that I am aware that the user
58+
experience might be affected.
59+
60+
Solution overview
61+
-----------------
62+
The objective is to provide usable workflows for users to authenticate in the
63+
graphical interface using passwordless authentication mechanisms. To do this,
64+
we first need to design a communication protocol between SSSD and GDM.
65+
66+
The APIs can be implemented in two ways, either by implementing them in
67+
`D-BUS <https://www.freedesktop.org/wiki/Software/dbus/>`__, or by extending
68+
the PAM conversation to include the new authentication mechanisms. There
69+
doesn’t seem to be any advantage in using D-BUS, whereas a PAM-level API would
70+
give other desktop environments the ability to offer similar features. For this
71+
reason, the GDM PAM extension has been selected.
72+
73+
GDM already provides an interface in ``/usr/include/gdm/gdm-pam-extensions.h``
74+
that SSSD supports. Unfortunately extending this binary interface is hard, so
75+
a JSON based protocol is used. It’s easier to extend and manage, making it
76+
easier to adapt the different packages involved. The previous implementation
77+
will continue to be maintained for backward compatibility.
78+
79+
As for the workflows, they have to provide the user with a way to interact
80+
(i.e. insert the hardware token or enter the PIN), while allowing communication
81+
with the device or the external provider. Each authentication mechanism needs
82+
its own sequence diagram definition, which will be explained later in this
83+
document.
84+
85+
Implementation details
86+
----------------------
87+
88+
Sequence diagram
89+
****************
90+
The communication between SSSD and GDM is explained in the following sequence
91+
diagram.
92+
93+
.. uml:: ../diagrams/passwordless-gdm-auth.pu
94+
95+
* GDM prompts the user for their username.
96+
97+
* The user initiates the login procedure by entering their username.
98+
99+
* GDM starts the PAM conversation.
100+
101+
* GDM starts the authentication process in SSSD.
102+
103+
* pam_sss communicates with the PAM responder to resolve the user.
104+
105+
* PAM responder resolves the username and obtains, among other things, the
106+
available authentication methods and the prompting strings.
107+
108+
* PAM responder prepares the JSON message with the available authentication
109+
mechanisms, the prompts and the user credentials to be requested
110+
(check format in :ref:`data`).
111+
112+
* PAM responder returns this information to pam_sss.
113+
114+
* pam_sss wraps the JSON message in the PAM conversation.
115+
116+
* GDM prompts the user for the user credentials, and at the bottom of the
117+
screen it shows the available authentication mechanisms. If the user selects
118+
another method, GDM already has all the information needed to request the
119+
user credentials for this authentication mechanism.
120+
121+
* The authentication workflow continues, but varies depending on the selected
122+
authentication mechanism. This will be explained separately for each
123+
mechanism.
124+
125+
.. _data:
126+
127+
Data
128+
****
129+
In addition, the messages exchanged follow the JSON standard. SSSD provides the available authentication mechanisms in the following message:
130+
131+
.. code-block:: json
132+
133+
{
134+
"auth-selection": {
135+
"mechanisms": [
136+
{
137+
"$mech1": {
138+
"msg1": "msg1"
139+
},
140+
}
141+
{
142+
"$mech2": {
143+
"msg1": "msg1",
144+
"msg2": "msg2"
145+
},
146+
}
147+
]
148+
}
149+
}
150+
151+
GDM answers with the result for the previous JSON message processing:
152+
153+
.. code-block:: json
154+
155+
{
156+
"auth-selection": {
157+
"code": "$code",
158+
"message": "$message"
159+
}
160+
}
161+
162+
Examples for the two messages are defined in the following lines.
163+
164+
Password
165+
++++++++
166+
.. code-block:: json
167+
168+
{
169+
"auth-selection": {
170+
"mechanisms": [
171+
{
172+
"password": {
173+
"prompt": "Password"
174+
}
175+
}
176+
]
177+
}
178+
}
179+
180+
EIdP
181+
++++
182+
.. code-block:: json
183+
184+
{
185+
"auth-selection": {
186+
"mechanisms": [
187+
{
188+
"eidp": {
189+
"init_prompt": "EIdP login",
190+
"link_prompt": "EIdP login",
191+
"uri": "short.url.com/1234",
192+
"code": "1234"
193+
}
194+
}
195+
]
196+
}
197+
}
198+
199+
Password and EIdP
200+
+++++++++++++++++
201+
.. code-block:: json
202+
203+
{
204+
"auth-selection": {
205+
"mechanisms": [
206+
{
207+
"password": {
208+
"prompt": "Password"
209+
}
210+
},
211+
{
212+
"eidp": {
213+
"init_prompt": "EIdP login",
214+
"link_prompt": "EIdP login",
215+
"uri": "short.url.com/1234",
216+
"code": "1234"
217+
}
218+
}
219+
]
220+
}
221+
}
222+
223+
GDM reply
224+
+++++++++
225+
.. code-block:: json
226+
227+
{
228+
"auth-selection": {
229+
"code": "0",
230+
"message": "Ok"
231+
}
232+
}
233+
234+
Smart card
235+
++++++++++
236+
237+
Passkey
238+
+++++++
239+
240+
Authors
241+
-------
242+
* Iker Pedrosa <ipedrosa@redhat.com>
243+
* Ray Strode <halfline@redhat.com>

‎src/diagrams/passwordless-gdm-auth.pu

+12
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
@startuml
2+
actor User
3+
participant GDM
4+
box SSSD
5+
participant pam_sss
6+
participant "PAM responder"
7+
end box
8+
9+
GDM -> User: Login prompt
10+
User -> GDM: Input username
11+
12+
@enduml

0 commit comments

Comments
 (0)