|
|
|
Xiaoyu Chen: 07/12/2007 11:27 PM EDT
|
| |
Comment: |
About _RUS::listAssignedRoles_
The interface is defined according to the configuration informaiton defined in section 4 (version 1.7 and version 1.9). As both documents clarified,
the access control model for RUS should be role-based. The operation is then used to return configuration information to the client about assigned
roles by RUS internal access control model. The roles defined here differentiate from ones defined in VOMS, but could be same depending on project-
specific role configuraiton and allocation mechanism.
It is interesting to know the RUS should not restrict on role-based access control model. Then the configuration (section 4.1) should be removed as
well?
I generally agree on this operation has nothing to do with RUS logics. But i got an interesting use case here which contributed to this definition:
A Portlet-based RUS client, that automatically filters unauthorised portlets for client-side interactions. Then the operations can be used to query
assigned roles to a particular user, and only display related portlets in a single Web portal.
Anyway, this operation can be custom defined within an implementation.
cheers!
|
| |
Action: |
Update
|
|
|
Xiaoyu Chen: 07/12/2007 10:20 PM EDT
|
| |
Comment: |
Rosario wrote:
>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.
I total agree one step evolvement at one time based on current version 1.7. However, if looking into the details of version 1.9, the main changes are
mainly based on version 1.7 as what proposed on removing RUS-UR as first step. Since RUS-UR being removed, then a lots of context notes should be
modified accordingly as well as service interface definitions.
First of all, the chapter 5 (version 1.7) should be removed or modified to a few words saying the specification is based on OGF-UR format instead of
RUS-UR. Then section 6.1.2 (version 1.7) should be changed as well. The RUSRecordId element of RUSRecordIdList should be "urf:recordId" as xsd:string
type.
Then coming into the details of Service Interface Definitions:
Extraction SIDs:
1). RUS::extractRUSUsageRecords is intended to be redefined as "RUS::extractUsageRecords" with output as URF elements.
2). RUS::extractRUSRecordIds should be changed into "RUS::extractRecordIds" as well. Besides, i cannot see any reason for defining this operation in
version 1.7, except being used as an auxiliary operation for client-side to obtain relevant usage record identities. But how these usage record
identities can be used (Just because it is mandatory element defined in RUS-UR or OGF-UR?)
3). based on above context, the version 1.9 proposed RUS::extractSpecificUsageRecords allowing the client side to query usage records with a set of
record identities.
So as you can see, the version 1.9 is total evolved from version 1.7 with agreed changes except for additional faults with well-defined fault
framework. Maybe version 1.9 should not be named as version 1.9, 'cos it is actually a mantenance of version 1.7 and should be version 1.7 as well.
If you all agree on this, then i will modified version 1.7 accordingly without changes on faults framework. But additional RUS::TooComplexFault should
be added which has no effects on operationResult element. That is because the operational result aims at giving fine-granularity operational result
for batch processing, which is out of the scope of "TooComplexFault" definition.
|
| |
Action: |
Update
|
|
|
Gilbert Netzer: 07/05/2007 10:12 AM EDT
|
| |
Comment: |
I added the part 2 from the last comment from Xiaoyu Chen to the WS-Enumeration tracker (artf5887)
|
| |
Action: |
Update
|
|
|
Xiaoyu Chen: 07/05/2007 9:50 AM EDT
|
| |
Comment: |
Hello, everyone:
It's great to get your comments finally. I got some problems when composing OGF-RUS specification version 1.9. There are some points:
1). Rosario said, we should concentrate on some changes agreed based on version 1.7 with agreed comments, such as removing RUS-UR wrapper. But the
main difference for version 1.9 is targeted removing RUS-UR. Do you mean leaving the RUS operations as what they are? If it is the case, then i will
update the version 1.7.
2). Regarding RUS operations, the reason i got stucked somehow is an important signal from stakeholders about query operation.
"The RUS specificaiton is hard to be conformed only if the query operations providing reliable extraction of usage records based on following contexts
:
first of all, as a specification, it should gives implementation guides to solve potential problems and makes reliable recommendataions. Which means,
the specification should protect the RUS server from being crashed when returning large amount of data."
We agree to propose a "RUSTooComplexFault". However this never really solves returning huge-data to the client. Some implementation strongly requires
a "steam" type return for stateful connection to the database. They request the complex queries always return what user asked even taking longer time.
However, this would not work through Web service, which is stateless essentially and will throw session out error if taking too long time to get SOAP
response message back.
So i reviewed OSGA-DAI, WS-DAI, WS-Enumeration, WS-Context and other relevant specification and implementations. There is still no satisfiable
solutions for this issue from the perspective of service interface definitions. OSGA-DAI provides an implementation-specific service interface, which
is more or less like the operation defined in the WS-Enumeration specification:
GetFully Operation
Inputs:
The name of a session known to a data service resource.
The name of an open output stream known to the session.
The session name and stream name are expected to be conjoined with a colon (:).
Outputs:
Data - a string, a chunk of valid XML or a byte array.
GetNBlocks Operation
Inputs:
The name of a session known to a data service resource.
The name of an open output stream known to the session.
The session name and stream name are expected to be conjoined with a colon (:).
The number of blocks of data to be retrieved.
Outputs:
A block of data - a string, a chunk of valid XML or a byte array.
Gilbert proposed the WS-Enumeration, and define a new operation for returning "wsen:EnumreationContext" type. That could be a solution. However, how
to integrate the WS-Enumeration datatype and operations into RUS operations is another issue.
* import WS-Enumeration WSDL within the RUS WSDL?
* define a new context data type for enumeration context within the RUS WSDL?
|
| |
Action: |
Update
|
|
|
Rosario M. Piro: 07/05/2007 8:12 AM EDT
|
| |
Comment: |
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.
|
| |
Action: |
Update
|
|
|
Gilbert Netzer: 07/05/2007 6:18 AM EDT
|
| |
Comment: |
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.
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.
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.
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)?
Comments please!
I also added the text to the GridForge tracker so that we can keep track of
this thread.
|
| |
Action: |
Update
|
|
|
|
