Re: [9fans] Multi-domain authentication?
> My internalized model of how this should work is AFS's ACL system (if that's > not a dirty word...) and the associated PTS group system. Between them, > they provide excellent ability to talk about users from remote cells and > allow users to create and manage their own groups. just use afs if that's what you want. - erik
Re: [9fans] Multi-domain authentication?
On Mon, Oct 20, 2008 at 10:29:17PM -0500, Eric Van Hensbergen wrote: > Good general problem, I'd also like to add my personal pain point that > only the file server knows about the relationship between groups and > users. It'd be nice to have a more general service to take care of > this, and include some ability to assign remote delegated user names > to local groups. > > I also like the idea of having "user-context" groups where users can > create their own groups and assign local and remote users to them for > the purposes of accessing file servers they "own". My internalized model of how this should work is AFS's ACL system (if that's not a dirty word...) and the associated PTS group system. Between them, they provide excellent ability to talk about users from remote cells and allow users to create and manage their own groups. --nwf; pgp8shDM38XJ5.pgp Description: PGP signature
Re: [9fans] Multi-domain authentication?
> Does that make sense? yes. very good explaination. however, i can't see how i could use this. while i do manage >2 auth domains (and growing), i still have the requirement that everyone have an @tld address, so the administration needs to be centralized, regardless. conversely, leaf nodes can't depend on the main auth server, since this would mean no work could be done if they can't contact the main auth server. perhaps i just lack imagination. - erik
Re: [9fans] Multi-domain authentication?
I wrote my own thoughts in a paper some time ago, though its a discussion document rather than a design spec. http://www.quintile.net/papers/xauth.pdf -Steve
Re: [9fans] Multi-domain authentication?
On Tue, Oct 21, 2008 at 4:29 AM, Eric Van Hensbergen <[EMAIL PROTECTED]> wrote: > Good general problem, I'd also like to add my personal pain point that > only the file server knows about the relationship between groups and > users. It'd be nice to have a more general service to take care of > this, and include some ability to assign remote delegated user names > to local groups. this would indeed be nice. i believe some of the stuff that forsyth was working on at one time to put SPKI into inferno could have helped in this context.
Re: [9fans] Multi-domain authentication?
On Mon, Oct 20, 2008 at 7:49 PM, erik quanstrom <[EMAIL PROTECTED]> wrote: > > the premise is that the local system, and thus i assume the local fs, has > no knowledge of the user. this task has been delegated to a foreign auth > server. so what are the mechanics of getting the local fs to treat an > unknown user as something other than none? > Good general problem, I'd also like to add my personal pain point that only the file server knows about the relationship between groups and users. It'd be nice to have a more general service to take care of this, and include some ability to assign remote delegated user names to local groups. I also like the idea of having "user-context" groups where users can create their own groups and assign local and remote users to them for the purposes of accessing file servers they "own". > > supposing this problem is solved, don't you need quotas or something > if you don't know who exactly to yell at for filling up the worm? > There are lots of different solutions here -- could be as simple as only using ramfs or ramdisk, could just require the user to use /mnt/term as his space, or be nice and provide cfs style semantics on top of /mnt/term to make it a bit snappier. In any case, I don't see any of this as a major barrier to the desire for multi-domain authentication. -eric
Re: [9fans] Multi-domain authentication?
On Mon, Oct 20, 2008 at 6:05 PM, andrey mirtchovski <[EMAIL PROTECTED]> wrote: > i hope to have relayed the original idea: give "friendly users" some > access to your resources. yes, there was a long running discussion of this with presotto, andrey, acki, me, who else? years ago. We never resolved the question of how to do it. We just know it's not done. ron
Re: [9fans] Multi-domain authentication?
On Mon, Oct 20, 2008 at 07:43:39PM -0400, erik quanstrom wrote: > > http://osdir.com/ml/os.plan9.nine-grid/2005-06/msg1.html is a proposal > > from some years ago from TIP9UG to do multi-domain authentication in a way > > somewhat reminiscent of Kerberos.[1] > > > > The only change to factotum, AFAICT, was the following addition: > >>if(_strfindattr(s->key->attr, "grid")){ > >> snprint(s->t.suid, sizeof s->t.suid, "[EMAIL PROTECTED]", s->t.cuid, > >> _strfindattr(s->key->attr, "dom")); > >> safecpy(s->t.cuid, s->t.suid, sizeof s->t.cuid); > >> flog("grid user: %s", s->t.suid); > >>} > > in the SHaveAuth case of p9skread. > > > > This seems like a good way to go about MDA, so I am curious why this change > > didn't get put back into the mainline code? Is there something > > fundamentally wrong? Was a different approach selected? Was the issue > > simply tabled? > > could you explain what you mean by multi-domain authentication? > > i authenticate from one plan 9 authentication domain to another > every day. the only thing that needs to be set up is that the hostowner > of the other auth domain's auth server needs to be in your /lib/ndb/auth. > (this is already done if you use bootes.) and you need a line with > auth and authdom keys added to /lib/ndb/local on the auth client's > machine. Here you are merely authenticating as a user in the remote domain; that you exist in the local domain is immaterial to the remote domain. The TIP9UG proposal above allows a domains to delegate part of its user namespace to another, by appending @delegatee to the usernames of all users logging in via credentials authenticated from the delegatee auth server. > is there something else you are looking for? Yes, something more like Kerberos. The question then becomes why... I want AFS (specifically PTS) style semantics for distributed resources, where I can create groups without having to pester my administrator and users from remote systems exist as local entities and can be included in groups as such. > > [1] I say similar to Kerberos in that it requires a domain A wishing to > > accept identities from domain B to have a key from B's authsrv. > > i don't understand this. which key are you talking about? I mean: This delegation is done by having the delegatee give the delegator a user account and the delegator having their perimeter machines' hostowners' factotums use that key in addition to their delegator-domain key. Being a little more concrete, suppose dom=example.com wants to allow dom=bell-labs.com users to be referred to as "[EMAIL PROTECTED]". Each domain's perimeter machines (e.g. CPU servers) are already given keys with speaksfor privileges against their local domain. To enable the cross-domain authentication, 0. bell-labs.com creates a key (user) for example.com, perhaps named "mda-example.com" and send the password to the example.com administrator. 1. The example.com administrator ... 1.0. ensures that bell-labs.com has the correct record in /lib/ndb/local 1.1. installs this key into their perimeter machines, which are running the TIP9UG factotum patch above. 1.2. The example.com administrator gives this key speaksfor= privileges for "[EMAIL PROTECTED]" 2. The bell-labs.com administrator ensures that /lib/ndb/local says to use the bell-labs.com authentication server, not the example.com one, when talking to example.com. 3. It is now possible for any bell-labs.com user to log in to the example.com domain without having asked example.com for a user account. Further, all example.com servers see the user as "[EMAIL PROTECTED]" and are not confused about who filled up the WORM. This is very similar to Kerberos's key exchange mechanism for cross-domain validation, except that AFAIK in Kerberos the KDCs are a little more in on the joke, whereas here that is not necessary. Contrawise, here, all perimeter machines need to have the delegatee key in their factotums' keyrings. Does that make sense? --nwf; pgp6hqVHA5p1Z.pgp Description: PGP signature
Re: [9fans] Multi-domain authentication?
> i'm not sure. what does "complete filesystem semantics" mean? let me > rephrase. honouring group and user permissions, instead of using a world-writable partition with everybody treated as "none". > the premise is that the local system, and thus i assume the local fs, has > no knowledge of the user. this task has been delegated to a foreign auth > server. so what are the mechanics of getting the local fs to treat an > unknown user as something other than none? i don't believe everything was thought-through very thoroughly before people became indifferent to the idea. one suggestion was to use "[EMAIL PROTECTED]" for figuring out "local" vs "remote" users (i.e., become "[EMAIL PROTECTED]" instead of "none"). > supposing this problem is solved, don't you need quotas or something > if you don't know who exactly to yell at for filling up the worm? access control lists? i'm afraid i don't know the answer and i'm certainly not prepared to dive into this any deeper. it's been quite a while :) i hope to have relayed the original idea: give "friendly users" some access to your resources.
Re: [9fans] Multi-domain authentication?
On Mon Oct 20 20:41:38 EDT 2008, [EMAIL PROTECTED] wrote: > > what kind of access would you give such users to the fileserver? > > in this specific example perhaps some minimal scratch space, but one > can quickly conceive cases where the complete file system semantics > are used, for example when you want to provide a data replication > service between sites without enforcing a global user namespace. > > was this what you were asking? some of those ideas came out of 9grid, > but i don't know whether anyone has pushed them further. i'm not sure. what does "complete filesystem semantics" mean? let me rephrase. the premise is that the local system, and thus i assume the local fs, has no knowledge of the user. this task has been delegated to a foreign auth server. so what are the mechanics of getting the local fs to treat an unknown user as something other than none? supposing this problem is solved, don't you need quotas or something if you don't know who exactly to yell at for filling up the worm? - erik
Re: [9fans] Multi-domain authentication?
> what kind of access would you give such users to the fileserver? in this specific example perhaps some minimal scratch space, but one can quickly conceive cases where the complete file system semantics are used, for example when you want to provide a data replication service between sites without enforcing a global user namespace. was this what you were asking? some of those ideas came out of 9grid, but i don't know whether anyone has pushed them further.
Re: [9fans] Multi-domain authentication?
>> is there something else you are looking for? > > say i have a plan9 compute cluster on which i want to allow tip9ug's > users to run jobs. i shouldn't have to add all their passwords to my > auth server, but i should still be able to say "i trust tip9ug's auth > server and will allow users from it to log in to my machines". what kind of access would you give such users to the fileserver? - erik
Re: [9fans] Multi-domain authentication?
> is there something else you are looking for? say i have a plan9 compute cluster on which i want to allow tip9ug's users to run jobs. i shouldn't have to add all their passwords to my auth server, but i should still be able to say "i trust tip9ug's auth server and will allow users from it to log in to my machines".
Re: [9fans] Multi-domain authentication?
> http://osdir.com/ml/os.plan9.nine-grid/2005-06/msg1.html is a proposal > from some years ago from TIP9UG to do multi-domain authentication in a way > somewhat reminiscent of Kerberos.[1] > > The only change to factotum, AFAICT, was the following addition: >>if(_strfindattr(s->key->attr, "grid")){ >> snprint(s->t.suid, sizeof s->t.suid, "[EMAIL PROTECTED]", s->t.cuid, >> _strfindattr(s->key->attr, "dom")); >> safecpy(s->t.cuid, s->t.suid, sizeof s->t.cuid); >> flog("grid user: %s", s->t.suid); >>} > in the SHaveAuth case of p9skread. > > This seems like a good way to go about MDA, so I am curious why this change > didn't get put back into the mainline code? Is there something > fundamentally wrong? Was a different approach selected? Was the issue > simply tabled? could you explain what you mean by multi-domain authentication? i authenticate from one plan 9 authentication domain to another every day. the only thing that needs to be set up is that the hostowner of the other auth domain's auth server needs to be in your /lib/ndb/auth. (this is already done if you use bootes.) and you need a line with auth and authdom keys added to /lib/ndb/local on the auth client's machine. is there something else you are looking for? > [1] I say similar to Kerberos in that it requires a domain A wishing to > accept identities from domain B to have a key from B's authsrv. i don't understand this. which key are you talking about? - erik
[9fans] Multi-domain authentication?
Hullo list. http://osdir.com/ml/os.plan9.nine-grid/2005-06/msg1.html is a proposal from some years ago from TIP9UG to do multi-domain authentication in a way somewhat reminiscent of Kerberos.[1] The only change to factotum, AFAICT, was the following addition: >if(_strfindattr(s->key->attr, "grid")){ > snprint(s->t.suid, sizeof s->t.suid, "[EMAIL PROTECTED]", s->t.cuid, > _strfindattr(s->key->attr, "dom")); > safecpy(s->t.cuid, s->t.suid, sizeof s->t.cuid); > flog("grid user: %s", s->t.suid); >} in the SHaveAuth case of p9skread. This seems like a good way to go about MDA, so I am curious why this change didn't get put back into the mainline code? Is there something fundamentally wrong? Was a different approach selected? Was the issue simply tabled? Thanks. --nwf; [1] I say similar to Kerberos in that it requires a domain A wishing to accept identities from domain B to have a key from B's authsrv. It differs from Kerberos in that users in domain B act as if B's authsrv was the authenticator for domain A. pgpSCoaiGCeDm.pgp Description: PGP signature