[RUS-WG] RBAC use case

Rosario Piro piro at to.infn.it
Fri Apr 6 03:40:05 CDT 2007 

Hi!

Sorry, I didn't know your were interested in suggestions for your RUS
toolkit (that can also bo considered an implementation, although it should
of course be more flexible than any specific implementation).

I would always consider contemporarily both active roles for evaluating
XUpdate statements (if the user has that much "power", why not allow him
to wield it? :o). But even if you do so, there is another problem: do
you always consider the entire <modifications> statement which means that
if one (sub-)<update> statement is invalid you refuse all modifications,
or will you evaluate each <update> statement as single actions and
eventually grant some while rejecting others (so doing only a part of the
modifications requested).

Both approaches are possible and compliant with the RUS spec, but I
personally would opt for refusing all modifications, since in some cases
the single <update> statements might have a logical connection that the
RUS service can hardly know (for example, it might not make sense to set
ProjectName to analysis if you're not allowed to set VOName to CMS). It's
safer to refuse the entire modification and let the user know why this has
happend (through a fault message, as you suggested in you proposals). The
user can then, if he/she still wants the possible modifications, take
another try without the <update> statements that have been rejected.

Cheers,

Rosario.

On Fri, 6 Apr 2007, Xiaoyu Chen wrote:

> 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
> >
>
>
>
>
>

More information about the rus-wg mailing list