[RUS-WG] RBAC use case

[Rosario Piro]

Hi Xiaoyu! Hi all!

Here is my opinion:

On Fri, 6 Apr 2007, Xiaoyu Chen wrote:

> hello, RUS charters and everyone:
>
>         There is a very interesting (but problemmatic) use case for access control over RUS::modifyUsageRecords.
>
>         For a user who takes the role of both VO manager and Resource Manager, it is possible for the user to update VO informaiton and resource informatoin (urf:ProjectName) in a single XUpdate expression as following:
>
>        <?xml version="1.0" ?>
>        <xupdate:modifications version="1.0" xmlns:xupdate="http://www.xmldb.org/xupdate" xmlns:urf="http://schema.ogf.org/urf/2003/09/urf">
>            <xupdate:update select="/urf:UsageRecord/urf:Resource[@urf:description='VOName']">
>            CMS
>            </xupdate:update>
>            <xupdate:update select="/urf:UsageRecord/urf:ProjectName">
>            analysis
>            </xupdate:update>
>            </xupdate:modifications>
>
>        ps: this XUpdate statement has been tested on eXist new core successfully.
>
>
>        This statement is valid XUpdate expression, but resulting in the
> problem for RUS access control. Theoretically this update operation
> should
> succeed for the user, but involving 2 active roles at runtime. Also
> these
> two active roles should be used each for "sub-update" statement. How
> the
> RUS access control deal with this situation???? Any single role security
> policies cannot guarantee the success of this update, except using each
> role policy for each <update> statement. So this use case indicates two
> problem of existing RUS specificaitons:
>
>        * The RUS modification interface requires to be refined to avoid this situation ?
>        * The RUS access control model requires to be more flexible and advanced features to satisfy muti-active roles and intelligent role selection mechanism. And this should be clarified in the RUS specification?
>
>        How do you think ?

I don't think that this is an _interface_-specific question, but an
_implementation_-specific one. The RUS interface should NOT force
developers to use any specific access control model, it should instead
enable developers to use _whatever_ access control model they want. The
only thing that the RUS specification needs to make sure is that there is
a possibility to deny the access (RUSUserNotAuthorizedFault or however we
want to call it), but it should not define _when_ and _why_ access is
denied because that heavily depends on your Grid environment, on your
organisation of user groups, on the agreements between the participating
parties (institutions, VOs, etc). There are, for example, environments in
which VO Managers should not have any possibility to update records, so
don't force developers to grant them access just to be compliant to the
RUS spec, because that will lead to a situation where nobody will want to
implement our spec because it doesn't fit there use case).

Generally I think we should define _only_ the interface to the service,
NOT how the service itself has to work. That means in this case we
should just state that the modifyUsageRecords _can_ return a
RUSUserNotAuthorizedFault, not why and for what roles this is returned!
That's up to the implementation of the service and may differ from Grid
environment to Grid environment.

That's why I don't see any problem with your use case, you can
autonomously decide how you want to handle that, you will automatically be
compliant with the RUS spec, whether you grant access in this specific
case or not!

Cheers,

Rosario.


>
>        Cheers!
>
>
> School of Engineering and Design
> Mobile: Mobile: ++44(0)7871876894
> X. Chen
> --
>   rus-wg mailing list
>   rus-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/rus-wg
>