[RUS-WG] Do we need RUS::ListAssignedRoles?

[Rosario Michael Piro]

Hi,

Gilbert Netzer wrote:
 > Hi everybody,
 >
 > I just have a short question about a part of the tracker artf5934
 > (https://forge.gridforum.org/sf/go/artf5934?nav=1) concerning the new
 > RUS::ListAssignedRoles operation:

I've read through the proposals on the tracker, but so far I didn't have 
the time to answer. Here's my opinion on the RUS::ListAssignedRoles.

But first let me say: I think we shouldn't work contemporarily on two 
versions of the draft (17 that went through public comment and 19 that 
is a proposal of which some things have already been discussed and 
agreed, but many changes are not "approved"). I would suggest to port 
the proposed changes that have been accepted to version 17 and let that 
evolve step by step. For example: the removal of the wrapping RUS-UR and 
an additional extractRecordHistory.

But now to RUS::ListAssignedRoles:

I don't think we should go that much into authorization. I still believe 
that authorization is an implementation issue, not an issue if the 
interface to the service. We should not force anybody to use Role-Based 
Access Control (RBAC). If an implementation wants to use some other 
mechanism that should be perfectly compliant with the interface 
specification.
And even for those implementations that have an RBAC mechansim, I 
honestly don't see the need to give role information back to a client. 
Each user should/would know what it's role is and no user should be able 
to find out what another user's role is. So the method would most 
probably give back only role information for yourself ...
If there is really a stong wish in that, than _at least_ the faults that 
can be returned upon a RUS::ListAssignedRoles call must include 
RUSUserNotAuthorizedFault (retruned for example if user X tries to find 
out the role of user Y).
And then: have such an explicit method for getting roles does make sense 
above all if there well-defined roles that can be recognized by all 
clients. That however means to even more restrict implementation choices 
by forcing developers to support specific roles (that maybe don't even 
exist in their grid enviornment ...)


> Maybe I got confused here, but should not the user/client specify which
> role she wants and then either provide the RUS server with some assertion
> from a third party (e.g. an attribute certificate) or have the server check
> with this party (some sort of pull mode) to get such an assertion? Is not
> the whole point of roles that the same user/client (the same identity) can
> at one instance be a normal user with restricted privileges and at another
> instance be an administrator with much greater privileges.
> 

I think there is a misunderstanding with the roles here. I guess Xiaoyu 
meant roles regarding the RUS server (ordinary user, RUS admin, ecc.) 
while you (correctly) refer to roles specified in the certificate (VOMS 
roles/groups for example), i.e. VO-related roles. Those are essentially 
different things and I suppose Xiaoyu meant the method to retrieve the 
user DN and the (VO-specifc) role to provide a mapping to the 
RUS-internal role (what can you do with that specific VOMS certificate 
proxy?)

> In any case, the users identity should be established by the transport
> layer during the authentication phase and not be given a input parameter.
> The operation would have to check anyway that you are not trying to look at
>  the roles of another user.

Yes, what I thought as well. But in theory if your an admin of the RUS 
server than you might be allowed to see all user's roles. But then: why 
would you need to use a remote SOAP call to get the information when you 
already got it under your hand. That's why I don't see the need for the 
method: the admin already has the information and ordinary users would 
only get information about themselves (info they most probably already 
know). At the same time we're restricting implementations to using a 
role-based authorization procedure.

> 
> Another question concerning this is how you would manage some session state
>  if the roles are not transported with the request. In this case the RUS
> server would have to remember the user roles for some time or ask for an
> assertion to get all the roles during each request, and how would you
> choose the role in this case.

If the (VO-)role is already "hard-coded" in the VOMS certificate proxy, 
then the RUS server will get it with each request and won't need to keep 
a session state. It can just map the VO-role to a RUS-role for each 
single request. But again, I think that's an implementation issue, not 
an issue of an interface that is meant to store and retrieve information 
(and not define how the service itself has to work).

> 
> In the end I am also wondering if this role assignment would not be queried
> using another service interface like the VOMS interface and should they not
> already have such a operation (or is it an API call to extract it from the
> credentials)?

Yes, and VOMS is only one possible choice, what about environments that 
use something else? Should we force everybody to use VOMS just to store 
some usage records?

Cheers,

Rosario.


> 
> Comments please!
> I also added the text to the GridForge tracker so that we can keep track of
> this thread.
> 
> Best Regards
> Gilbert Netzer
> PDC
> 
> 
> --
>   rus-wg mailing list
>   rus-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/rus-wg