Re: [9fans] Multi-domain authentication?

Re: [9fans] Multi-domain authentication?

[erik quanstrom]

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

[erik quanstrom]

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

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

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;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] Multi-domain authentication?

[Steve Simon]

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?

[roger peppe]

On Tue, Oct 21, 2008 at 4:29 AM, Eric Van Hensbergen <ericvh@gmail.com> 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?

[Eric Van Hensbergen]

On Mon, Oct 20, 2008 at 7:49 PM, erik quanstrom <quanstro@quanstro.net> 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?

[ron minnich]

On Mon, Oct 20, 2008 at 6:05 PM, andrey mirtchovski
<mirtchovski@gmail.com> 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?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 4177 bytes --]

On Mon, Oct 20, 2008 at 07:43:39PM -0400, erik quanstrom wrote:
> > http://osdir.com/ml/os.plan9.nine-grid/2005-06/msg00001.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, "%s@%s", 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 "...@bell-labs.com".  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 "*@bell-labs.com"

  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 "...@bell-labs.com"
     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;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] Multi-domain authentication?

[andrey mirtchovski]

> 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
"user@authdom" for figuring out "local" vs "remote" users (i.e.,
become "user@authdom" 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?

[erik quanstrom]

On Mon Oct 20 20:41:38 EDT 2008, mirtchovski@gmail.com 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?

[andrey mirtchovski]

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

[erik quanstrom]

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

[andrey mirtchovski]

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

[erik quanstrom]

> http://osdir.com/ml/os.plan9.nine-grid/2005-06/msg00001.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, "%s@%s", 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?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

Hullo list.

http://osdir.com/ml/os.plan9.nine-grid/2005-06/msg00001.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, "%s@%s", 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]