[Authentication] Solution to prompting and async operations

Michael Albinus michael.albinus at gmx.de
Sat Nov 14 04:00:50 PST 2009


Stef Walter <stef-list at memberwebs.com> writes:

> The service displaying its own GUI is an integral part of the current
> design.
>
> 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.

I'm following the discussion there. Yes, a user/machine bus would make
sense for the secret service.

People using my client library in a shell environment know, that they
have to call dbus-launch first. So the session bus would be sufficient
in my case, for the time being.

> 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.

In fact, org.freedesktop.Secrets.Prompt includes several
functionalities. It might be worth to distinguish between "asking the
user something" (prompting), and "doing something with the answer". And
obviously, I only need the question/answer part to hook in with my own
handler.

The GVFS interface offers a similar functionality, where I could
register with an own handler:

<interface name='org.gtk.vfs.MountOperation'>
  <method name='askPassword'>
    <arg name='message'        type='s' direction='in'/>
    <arg name='default_user'   type='s' direction='in'/>
    <arg name='default_domain' type='s' direction='in'/>
    <arg name='flags'          type='u' direction='in'/>
    <arg name='handled'        type='b' direction='out'/>
    <arg name='aborted'        type='b' direction='out'/>
    <arg name='password'       type='s' direction='out'/>
    <arg name='username'       type='s' direction='out'/>
    <arg name='domain'         type='s' direction='out'/>
    <arg name='anonymous'      type='b' direction='out'/>
    <arg name='password_save'  type='u' direction='out'/>
  </method>
  <method name='askQuestion'>
    <arg name='message' type='s'  direction='in'/>
    <arg name='choices' type='as' direction='in'/>
    <arg name='handled' type='b'  direction='out'/>
    <arg name='aborted' type='b'  direction='out'/>
    <arg name='choice'  type='u'  direction='out'/>
  </method>
</interface>

Something like this I would like to have in org.freedesktop.Secrets.Prompt :-)

> 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.

Yes, this is an issue. And it must also be ensured, that the password
sent over the bus is encrypted (askPassword returns clear text!).

> Cheers,
>
> Stef

Best regards, Michael.


More information about the Authentication mailing list