[RUS-WG] RBAC use case

[Xiaoyu Chen]

hello Rosario and everyone:
 
       Many thanks for your timely response!
 
       Rosario's right. The problem is more implementation specific. Actually the reason i proposed the problem is because i was stucked by the use case when i am developing the RBAC authorisation framework of RUS toolkit. The authorisation framework is intended to be extensible for various Access Control mechansims with Core requirements for "POLP" (Principle of Least Privilege), which allows application or RUS implementations grant rights to users or roles. And more advanced features for hierachical role privileges and "Speration of Duties" (either static and dynamic even though i cannot see any relevant use case at the moment). 
 
      So could you please give me some advices on the use case i gave in the context of authorisation framework also?
 
School of Engineering and Design
Mobile: Mobile: ++44(0)7871876894
X. Chen

________________________________

From: Rosario Piro [mailto:piro at to.infn.it]
Sent: Fri 06/04/2007 08:35
To: Xiaoyu Chen
Cc: rus-wg at ogf.org
Subject: Re: [RUS-WG] RBAC use case



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
>