if i understand correctly, the basic issues you're trying to solve (beyond authentication), are "delegation" and "authorization". because you're targeting non-plan9 environments, my comments will be focused on those environments.

any decent IT with heterogeneous OS environments will have a Kerberos+LDAP (most likely embodied in ActiveDirectory) setup to do this. all sharable resources (services) will be located on servers which can authenticate and authorize users.

the rest of my comments are inline:

On Sat, Nov 29, 2014 at 11:46 AM, Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net> wrote:
On 18.11.2014 09:22, Skip Tavakkolian wrote:

<snip>

thanks folks ... seems I need to think through all of this more deeply.

If I'm not completely mistaken, factotum can also handle various
authentication protocols, and may be the only one who really knows
the actual secrets.

One scenario I'm thinking about is replacing the password-stores in
certain browsers by an factotum (maybe it could also be useful for
cert handling ?)

A really cool feature, IMHO, would be able to connect my local factotum
to remote ones easily, so I'll get a similar feature like eg. lastpass
is doing for the web. For example, somebody like to give me access to
some remote application, but for some reason can't add my pubkey there
(eg. it doesn't even support such things), but doesn't want to give me
cleartext passwords, he could set things up in his (publically
accessible) factotum instance, which then handles all the auth stuff
for that application.


delegation would require some sort of initial trust relationship. for example, Kerberos includes the ability to setup trust relationships between different realms. once trust is established, a user vouched for by a KDC in one realm can be authenticated and authorized to receive service in another realm.  what you've described above would be like having two realms (yours and the other person's) each having a KDC (factotum) that handles a single identity.

btw, Plan 9's authentication in similar to Kerberos. auth server is the KDC, and factotum is the client side (but factotum can also talk other protocols and can keep secrets).  because all things are files in Plan 9, delegation between parties in the same realm can be accomplished by importing factotum's file system.  cross-realm delegation might be possible with some changes but in practice it is more convenient to give factotum the credentials for all authdom's and let it deal with them.

 
By the way, that leads me to another topic, which is annoying me
for quite some time: policykit.

For those, who have been spared of it:

It's an invention of the freedesktop folks (or should I call them
"Lennartists" ? ;-o), some kind of proxy, which routes certain dbus
calls (based on certain policies) between several users (and root).
This way, eg. unprivileged users can still be given access to system
level stuff, like network-manager. And that's exactly the point which
regularily hit me (eg. some day my primary account suddenly wasn't
able to choose wireless networks anymore, and even the old fashioned
way via unix groups didn't help either).

So, I'm thinking about a cleaner solution - obviously not dbus, but 9P.

If i understand it correctly, in 9P, the server is in charge of handling
all the access control. So, I can't just write some simple 9P server,
mount it anywhere and magically expect it working just by file
ownerships (by the way: do they have any practical meaning at all ?).

Obviously, the server needs to know who the calling user is and whether
he shall be allowed to access certain items - more precisely whether he
is in the right role right now. And these things could be depending on
other parameters (defined by other parties), eg. when reboot shall only
be allowed when logged-in locally, and no other blocking parts (eg.
important tasks) currently running.

as pointed out above, a shared trusted authority between the user and the service has to exist.  once authenticated, authorization can then be handled by other means (e.g. unix or ldap group membership, etc).  examples of this in plan9 are things like consolefs' /lib/ndb/consoledb (and because the root filesystem is served from the fileserver there's no need for ldap).
 

Pretty clear, that these things shouldn't be implemented in each single
service separately, and not every service that might have an influence
here shall have to talk to everybody else.

So, how would a Plan9 solution for these usecases look like ?

In fact, I intend to rewrite network-manager to some 9p-based solution,
so I'd like to discuss this carefully before starting to lennert up
something stupid.


cu



--
Enrico Weigelt,
metux IT consulting
+49-151-27565287