[RUS-WG] RBAC use case

Fri Apr 6 04:18:53 CDT 2007

Hi, Rosario:

     Many thanks again :)

    I think both solutions you proposed are feasible, and both have advantages and disadvantages.

    1). for simple refuse
    It is simple to be implemented as well as ensure service performance by ignoring decomposition of each XUpdate task.

    2). for decomposition
    It gives more flexibility for both security privilege definitions and RUS service logics but with extra performance costs. 

    Just a little background for the RUS toolkit. The RUS toolkit is basicaly composed of three individual components: the Authorisation Framework, Command Framework, and Data Access Framework. All these elements share a common configuration framework. 

   Authorisation Framework is based on RBAC models [http://csrc.nist.gov/rbac/draft-rbac-implementation-std-v01.pdf] but in the context of RUS. For example, the RUS permission/policy should at least provide two functionalities, "authorise user's role against requested command" and "authorise request context against requested command on a particular usage record". The core access control is based on POLP (principle of Least Privilege), which grants rights to individual users iteratively. Advance features (if necessary for RUS) inculde like hierachical role policies, static seperation of duties (SoD) and dyanmic seperation of duties (DoD). 

   Command Framework is based on factoy design pattern that only specifies RUS core interfaces but extensible for advanced features of RUS. With the command framework, a RUS implementation can simple implement a interface by providing its own insert/update/aggregate/ ... logics. The command framework contributes to a easy-implemented framework for RUS developers as well as conformantive implementations to both RUS core and advance specifications. 

   Data Access Framework provides a dynamic data sharing for RUS. the RUS specification does not care about how usage records are to be shared (database or filesystem, centralised or distribute storage). For example, the usage records shared in DGAS come from RDBMS (MySQL in particular) and distributed in HLRs. In this case the Data Access Framework should provide ability to support various data sharing models and provides administrative interfaces (Command framework) for these usage storages. 

  Configuration Framework is intended to be used for runtime configuration of implementations of aforementioned components. Oberverable pattern can be optionally "switched" on for changes of configurations. 

  That's the basic idea of the RUS toolkit, and I will keep the information updated to RUS team. If anyone is interested in the toolkit, i am pleased to know your use cases and advices. Also may be we can collaborate on the development. 

  Many thanks to RUS charters again (especially for Rosario).

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 09:40
To: Xiaoyu Chen
Cc: rus-wg at ogf.org
Subject: RE: [RUS-WG] RBAC use case

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