[Authentication] Solution to prompting and async operations
stef-list at memberwebs.com
Fri Nov 13 17:04:47 PST 2009
Michael Albinus wrote:
> I've played a little bit with the current code. Works fine for me so
> However, gnome-keyring registers itself for the
> org.freedesktop.Secrets.Prompt interface at the prompt object path, and
> starts its own GUI when calling org.freedesktop.Secrets.Prompt.Prompt.
> Is there a way to implement that method by my own client? This I would
> prefer, instead of seeing the GUI (which should always be the default).
> Note, that my client could also run in a non-X11 environment, where a
> GUI does not work.
The service displaying its own GUI is an integral part of the current
But that's an interesting problem. And if I'm understanding it
correctly, unfortunately not an easy one to solve. There are several issues:
1. Which DBus Bus
We'll be using DBus for the Secret Service API, and we would need to
somehow have DBus running in the non-X11 environment (like a user
running an app in an SSH session). There's discussion about a per-user
session on the dbus mailing list, that would sort of solve this problem,
but it's not currently implemented.
2. Describing Prompts
In order for an application to do the prompting it'll have to know
somehow what to prompt for, what text to use etc... The prompts can take
on many forms. In fact the Secret Service API specifically doesn't
mandate the use of passwords to unlock collections. This allows the
service implementors to use smart cards or other things.
But even setting aside future possibilities, right now as implemented
each different kind of org.freedesktop.Secrets.Prompt is very different.
Some instances of org.freedesktop.Secrets.Prompt unlock a set of
objects. Some of those objects will be unlocked without a real prompt
(if they're set to unlock automatically), and a single
org.freedesktop.Secrets.Prompt may generate multiple prompts in the UI
(for things like bad passwords, or multiple collections being unlocked).
Then the org.freedesktop.Secrets.Prompt that helps create a collection
would be different. Prompting for new credentials usually means double
checking them with the user (typing passwords twice). The prompt object
for changing collection credentials would have yet another interface.
So essentially there would need to be some sort of 'chat' process
similar to PAM that the client application is involved in.
3. Handling of Passwords
This is a far more minor issue. In gnome-keyring we try to keep user's
passwords, especially those that unlock keyrings out of pageable memory.
The GTK UI is also involved in this. This could be solved in several
ways, but is a departure from what we currently do.
So all in all, this is a big deal. I'm going to have to be honest and
come out and say that it's unlikely I'll have time to figure this out,
spec this out, implement and test it for our first version of the Secret
Service API. It could be added in an additional interface later, perhaps.
It's certainly a problem that needs solving in the long term. If we had
a lot more manpower or time in our projects, it'd be worth making more
of a priority.
But this discussion is a good one, and if anyone has anything further to
contribute now is a good time to brainstorm, even if those ideas can't
be implemented immediately.
More information about the Authentication