afs pts schema?

[Lyle Seaman]

Lyle Seaman wrote:

> Marcus Watts wrote:
>
> >         You'd have to provide a pt RPC (rx) interface, including
> >                 especially getcps and friends.  That's what
> >                 all the cache managers currently deployed expect,
> >                 so if you want to play, you have to provide it too.
> >         Not sure how openldap performs under load.  Performance
> >                 could be an issue.
>
> CMs don't talk to pt servers.   klog/login do, but don't have to, it's just for
> user-friendliness. Fileservers do, and must.  If you can change the fileserver
> getcps / gethostcps code, you're fine.

Oh, this reminds me.  You might turn the whole thing on its head, instead.
Especially if performance is an issue. I proposed this once a long time ago, but
it was never really important.  Maybe if you want to use LDAP it starts to be
useful?

1. break the fileserver -> pts relationship.  no more direct fileserver - ptserver
communication.
2. Make the authentication client (login/klog) get the groups data from the
authorization service (presently ptserver, but could be ldap or whatever).  The
groups data should be signed by the ptserver, and then preserved by the cache
manager.
3. when the fileserver needs the authorization data (ie, when establishing a new
connection, or whenever it has discarded the existing groups data), it calls the
cache manager, instead of the ptserver as it used to do.
4. alternatively, you could save one round trip by putting the authorization data
in the rxkad challenge response.

This is more scalable than the present scheme, and signing the authorization data
makes it secure.
I believe this is similar to what the DCE and then later, Microsoft, eventually
did.