[Authentication] project ideas

[Ben Kibbey]

On Wed, Feb 24, 2010 at 10:03:21PM +0100, Michael Leupold wrote:
> The concept used in the Secret Service API is a bit different but can
> in some ways achieve similar things. Secret items in the API are
> usually not stored and retrieved by name ("isp", "exim", ...) but by
> attributes. This basically means that you wouldn't store an imap
> account's password using the name "isp" as its identifier but would
> attach attributes likes "server=imap.myisp.com:993" or "type=email"
> which would enable the item to be found by several applications.

How would multiple accounts on the same server be handled?

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

> There's already some (afaik non-public) KDE API for storing secrets
> using the current KWallet through the means of the KConfig system. I
> don't believe merging configuration and storage of secrets is that
> good an idea. I'd like to keep the two separated. Especially since I
> fear the result might get so complicated we might face a problem
> finding someone to maintain it - after all configuration systems and
> password management daemons don't seem to be among the top 10
> "projects I'd like to maintain".

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?

> Do you think there's a real need for offering "your own" secrets to a
> different user account? Shouldn't actually the other applications run
> under "my account" if they want to use my precious secrets?

Most desktop users probably need an MTA which requires authentication
details. I was thinking of something equivalent in the Secrets Service
to pwmd's "target" attribute. There are probably other uses too. But it
still can be controlled with SO_PEERCRED and/or ACL's.

> Yeah, fresh ideas are always welcome.

Cool, thanks.

-- 
Ben Kibbey (bjk) @ FreeNode/OFTC