[Authentication] project ideas

[Ben Kibbey]

On Thu, Mar 11, 2010 at 05:32:19AM +0100, Michael Leupold wrote:
> Hi Ben,
> > How would multiple accounts on the same server be handled?
> 
> You'd introduce an extra identifier. Either make the mail address or the 
> username an attribute or - if you want to keep that private - introduce an 
> extra identifier property (guid, integer).

This seems simple. pwmd's database is an XML file so email addresses
can't be parsed as a valid XML element. Although it would be easy to
change the way elements are stored to be an element attribute. Which is
the way it should have been done to begin with. I recently ran into this
problem while making a patch for Psi. The workaround is to use a profile
name as the parent element for the username and password child elements.

> > > One major difference is that the daemon itself doesn't actually parse
> > > the secret data. It's just treated as a binary blob. Of course this
> > > makes refering to elements inside some hierarchy pretty much
> > > impossible. As I don't know how pwmd is used I don't know if that's a
> > > must-have feature though (I'm trying to imagine how that would work in
> > > an application's gui but can't really figure out how it would be
> > > used).
> > 
> > pwmd doesn't really parse the data either. It only stores it at some
> > location in the XML document. So to retrieve some data associated with
> > something the client needs, the client sends an element path using the
> > GET protocol command: GET isp<TAB>username. The XML might look like
> > this:
> > 
> > 	<root name="isp">
> > 		<username>someuser</username>
> > 		<server>some.server.com</server>
> > 		<port>993</port>
> > 		...
> > 	</root>
> > 
> > It's different that it's not a binary blob like the Secrets Service but
> > it can be base64 en/decoded by the client before storing and after
> > retrieving if binary data is needed.
> > 
> > Haven't really thought about the GUI of applications for pwmd much. The
> > way it works for most of the patches I have for apps (all but one are
> > daemons or console apps) is that an application or service element name
> > is created in the XML document and the children of that element are
> > settings for the service or application. So the client/app only needs to
> > know what it wants although no standard/specification of the root
> > element or element attribute names has been thought up.
> > 
> > For a GUI app only a root element path and data filename to open would
> > be needed. The rest of the data that the app needs is retrieved/stored
> > from the app-configured root element path. I suppose a GUI tree widget
> > of the document structure for selecting the root element would be nice.
> > This can be gotten with the LIST/DUMP/XPATH protocol commands.
> 
> Does that mean the client parses the XML as well to get to other
> applications' root elements? Or does pwmd do that?

The client can retrieve whatever data it wants. There really isn't any
protection against one application retrieving anothers data and I don't
really understand a need for any. Although it can be done by encrypting
the elements contents if needed, or by using another (encrypted) data
file entirely.

How a pwmd client retrieves the data is done by either parsing the
output of the LIST, DUMP or XPATH commands like mentioned before. Or by
following some specification that doesn't exist (yet?).

I've started working on a widget for Qt that can create an element tree
from the pwmd XML document. I've only finished parsing the output of the
LIST command to create a QTreeWidget out of it, but the rest should be
easy to do: add/remove elements and attributes, etc. The same can be
done for Gtk or NCurses or whatever.

You mentioned in a previous post that the Secret Service would be a
solution for both Gnome and KDE but the daemon would need to have GUI
dependencies. Just wondering what GUI dependencies? I don't think Gnome
users would be too happy about requiring Qt and vice-versa since they
use different toolkits. pwmd is only daemon without any GUI. The only
GUI that is needed is for password retrieval via pinentry which has
versions for Gtk, Qt and NCurses. A client GUI can either be configured
by patching or by creating a specification that it should follow.

I seem to be talking more about pwmd than the Secret Service. But it
seems like it's a duplicated effort. Maybe you could make a list of
pros and cons? Other than the protocol? Is application separation what
concerns you most?

> > What would be complicated about it? It only stores the data right? It's
> > up to the client what it does with it. Or maybe the attributes are
> > hard-coded? Is that what you mean?
> 
> No, I mostly meant that the more features you cram into it the harder it gets 
> for someone working on it to figure it out and improve it :-) Keeping things 
> simple makes it easier for others to help and fix bugs.

I think if there is some specification and a standard way of storing and
retrieving the data it doesn't seem like it would matter. I mean,
there's only so much you could do to improve something like this. What
was the last major update to KConfig, gconfd or KWallet, etc? Seriously,
I don't know because I don't use any of them. :)

-- 
Ben Kibbey
Jabber: bjk AT thiessen DOT org - (bjk) FreeNode/OFTC