Last week me, Jakub and Stef discussed a design for a candidate for a
FreeIPA&Gnome keyring related thesis:
Apparently, there was a misunderstanding when crafting the topic proposal, it
is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about
storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by
SSSD on user log on even in non-password authentication case (like SSO).
With SSO, Gnome keyring cannot grab the long term secret to unlock the keyring,
the keyring also cannot re-encrypt itself when the long term password changes
on the server (this is no problem locally as Gnome keyring is hooked to PAM
password change module). Thus, there is the idea to store the master
key/AUTHTOK centrally on the server.
Given the sensitivity of the password, it would be best to store it in the
upcoming FreeIPA Password Vault/KRA:
However, here comes the problem with how to authorize the operation on SSSD
level. To make it working, SSSD, host/client.example....@example.com would need
to be able to retrieve and decipher a key from (any) user's Vault, which is
probably not what we want to allow. We may add S4U2Proxy rules so that
host/client.example....@example.com can get
vault/server.example....@example.com for the client, but then SSSD could grab
any user's secret when he logs in.
Are there any ideas how to overcome this issue? Otherwise, it seems that the
Vault idea is not the right way. Maybe centralizing access to Gnome keyring is
not a good idea at all, we will see.
Martin Kosek <mko...@redhat.com>
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
Freeipa-devel mailing list