[AFS3-std] Re: [OpenAFS-devel] Proposal for new ptserver RPC: pr_WhoAmI

[Jeffrey Hutzelman]

Discussion of protocol issues should go to afs3-standardization.
I have copied this message there.


On Tuesday, June 26, 2007 12:15:12 PM -0400 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> My proposal is to add a new RPC:

Yeah; that sounds reasonable.



> struct prwhoami {
>   afs_int32 flags;
>   afs_int32 id;
>   char name[PR_MAXNAMELEN];
> }
> typedef struct prwhoami prwhoami;
>
> WhoAmI(
>   OUT prwhoami *who
> ) = NNN;
>
> The server will return to the caller the name that would be looked up in
> the database plus either the actual assigned AFSID or ANONYMOUSID.
>
> This new RPC is intentionally old-style.  In much the same way that we
> will need to add pr_CreateUserEx() in order to support multiple name
> types, we will need to add pr_WhoAmIEx() to support multiple name types.

I don't think so.  In the new world, PTS entries don't have multiple types 
of names; there is still just the one name.  What they have is one or more 
authentication names, possibly of different types, possibly of the same 
type, which map to that entry.




> The pr_WhoAmI RPC would be used to solve the pts registration problem as
> follows:
>
> * aklog would obtain a token
> * make a call to pr_WhoAmI to obtain the name and id from the ptserver
> * if the id is ANONYMOUSID then it would proceed to call pr_CreateUser
> with the name provided by the server.
>
> Comments?

Please make use of the flags to indicate whether the user is registered 
and/or should try self-registration, rather than inferring that from the 
returned ID.  I say this for a couple of reasons...

First, there may not be any name the client can self-register.  The 
ptserver maps authenticated principal names to pts entries by first looking 
for explicit mappings, then applying one or more transformations to turn 
the principal name into a PTS entry name, which it then looks up(*). 
Clients can self-register when...

- there is no explcit mapping (else it would be registered already)
- one of the transformations applies, but...
- produces a name which is not currently in the database

In that case, the ptserver can tell you what name to register.  But if no 
transformation applies, then there is no name you can self-register, and so 
there is no name for the ptserver to return in a whoami response.  In this 
situation, the ptserver should return ANONYMOUSID, no name, and indicate 
(via flags) that the client is not registered and cannot self-register.

Second, it is possible that the client can self-register, but the ptserver 
does not know in advance what name the client may use.  For example, it may 
be that a client is allowed to register using an enterprise-wide name 
assigned to him, where there is a directory that allows mapping such a name 
to all the principals that belong to it, but not the reverse.  A bit 
far-fetched, perhaps, but possible.  In this case, the ptserver should 
again return ANONYMOUSID and no name, and should indicate that the client 
is not registered but may self-register (if it can figure out the right 
name).

Thirdly, it is possible that the ptserver may grant otherwise-unregistered 
principals access according to some shared ID identified by a pattern.  In 
this case, the returned viceid should be the shared one, but flags should 
still indicate that the client is unregistered and may self-register.


In fact, I'm beginning to think the result should separately indicate:
- the viceID currently used for that client (possibly ANONYMOUSID)
- the name currently used for that client (possibly system:anyuser)
- the name the client may self-register with (possibly empty)
- whether the client is registered
- whether the client may self-register


Comments?

(*) Note that in the current ptserver, there is no way to set, represent,
    or store explicit mappings, so all lookups are done by transformation,
    and there is one fixed transformation for each auth name type (krb4
    and krb5).  It's actually slightly messier than that, since krb5 names
    are sometimes transformed to krb4 names outside the ptserver, but that
    isn't relevant here.  The important thing is that today's behavior is
    consistent with the new model plus some constraints.


> This is OpenAFS RT ticket 64147
> http://rt.central.org/rt/Ticket/Display.html?id=64147
>
> Jeffrey Altman
> Secure Endpoints Inc.