Re: [9fans] Multi-domain authentication? - Plan9

This is a discussion on Re: [9fans] Multi-domain authentication? - Plan9 ; > http://osdir.com/ml/os.plan9.nine-gr.../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")){ >> ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: [9fans] Multi-domain authentication?

  1. Re: [9fans] Multi-domain authentication?

    > http://osdir.com/ml/os.plan9.nine-gr.../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



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


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



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


  5. 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-gr.../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;

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkj9PLgACgkQTeQabvr9Tc/iOwCfbHrYMV69yTPW4fGuQCSeOr6Q
    KG4An0HijLXCV4tYIWRE05Nm28pkQgPp
    =pV7J
    -----END PGP SIGNATURE-----


+ Reply to Thread