[Authentication] project ideas
Michael Leupold
lemma at confuego.org
Wed Feb 24 13:03:21 PST 2010
Hi Ben,
Nice to see a new face on this list.
Am Mittwoch, 24. Februar 2010 03:20:59 schrieb Ben Kibbey:
> One of the main reasons for writing pwmd was the use of the "target"
> attribute in an XML element path. This lets the client share the same
> data with another application although located somewhere else in the
> document. Similar to XML entities and the HTML "target" attribute. So if
> I have an application (Mutt MUA) that needs server configuration details
> it requests an element by a configured element path then pwmd returns
> that elements content. With the use of the "target" attribute another
> application (Exim MTA) that requires the same data as another (Mutt in
> this case) can get the same data although located in another element.
> The XML document looks like this:
>
> <root name="isp">
> <username>someuser</username>
> <password>somepassword</password>
> </root>
> <root name="exim" target="isp"/>
> <root name="fetchmail" target="isp"/>
> <root name="isync" target="isp"/>
> <root name="mutt" target="isp"/>
>
> This way I only need to update the "isp" data for all applications that
> use it. If there is a way to have the Secrets Service do this that would
> be cool.
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.
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).
> It would be cool to see gconfd (not sure what KDE uses for configuration
> management) and the Secrets Service merged into the same server. Maybe
> a flag in a configuration data that requires the client to authenticate
> before retrieving it.
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".
> A way to connect to the DBus server as another user. pwmd uses a local
> socket that any user can connect to. Since it's a unix domain socket,
> file permission (ACL) and SO_PEERCRED based access work fine. I'm
> thinking about Exim support in the example above.
This might well be possible using peer2peer D-Bus (basically not a bus but a
socket connecting a client and a daemon directly). Making an application that
already speaks the API communicate like that might be trivial but I don't
really know enough about possible security implications or the likes.
Currently only the session-bus is part of the spec. It might be interesting to
see if the API could be used like that as well. I can't tell you if this is
something keyring and kwallet would support though (haven't given it any
thought up to now).
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?
> Also require as few dependencies as possible. Nothing GUI related since
> this may bloat non-GUI related apps.
The basic idea behind a daemon implementing the secret service is that the gui
is completely up to the daemon which would eg. ask for a password if that's
required to unlock the collection of secrets. So no gui is needed for the
client part.
> Just some ideas. I hope the Secrets Service can use some of them. You
> can find pwmd at http://bjk.sourceforge.net/pwmd/.
Yeah, fresh ideas are always welcome.
Kind regards,
Michael
More information about the Authentication
mailing list