OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Use case to demonstrate the need to publish, exchange, process andmatch access control policy information


Consider a scientist who needs a supercomputer to crunch on a large amount of 
test data, and who uses a computational grid to achieve this.

Within this grid, there are a number of resources, like super computers, disk 
farmes, big network pipes. Each of these resources may be owned by a different 
owner with its own access control policy that is enforced.

The scientist is also part of an administrative domain, and is subject to its 
policy.

To help the scientist, specialized scheduler services can go out to match the 
scientist's compute-job requirements with the availability of the different 
resources on the grid.

For example, this scheduler has to match the availability of CPU cycles on a 
certain supercomputer with the availability of diskspace for the pre- and 
post-processed data and the availability of network bandwidth to move data in 
and out. The scheduler should take many more things under consideration, like 
privacy policies, service level guarantees, etc. The end result should be a 
reservation for the use of a set of matching resources that meet all the 
requirement on size, availability, etc., with the ultimate submission and 
processing of the job.

Access control policy is an other important part of the scheduler's matching 
process, because if the scientist would not have access to one of the resources 
under consideration, the whole workflow of the job in progress could be aborted 
in progress, which could be an expensive consequence.

In other words, the access control policy of both the resource and the 
requester, and the associated authorization attribute values of both requester 
and resources, are important components for the scheduler to find the right 
matches and to make the appropriate reservations for the job's resource use.

The publishing, exchanging and sharing of access control policy information are 
sensitive operations by itself, and should be subject to access control policy - 
the scheduler has to be "trusted" by the resource owners with that policy data.

To make it more concrete with an example:

   "A resource owner's policy states that only requesters can invoke operations
    if they present a 'trusted-3rd-party-requesters' group membership assertion
    that is issued by a 'trusted-grid-admin-identity'".

   "the scientist's domain's policy states that only resources are to be used
    that can present a 'trusted-3rd-party-resources' group membership assertion
    that is issued by a 'trusted-grid-admin-identity'".

Note that in practise, the access control policies will be much more complicated 
and will most probably use all the features offered by the available 
authorization policy language and admin tools.

In order for the scheduler to do its work, it has to be entrusted with the 
scientist's authorization policy statements concerning the access of resources, 
as well as the relevant scientist's authorization attribute assertions.
Furthermore, the scheduler needs access to the authorization policy statement 
for each resource that is considered in the job matching process together with 
that resource's relevant attribute assertions.
Lastly, the scheduler has to evaluate the authorization policy statements with 
the attribute assertions to end up with results that determine whether the 
resource should be included or excluded from the further matching process.


--------------------------------
XACML and WS-Policy implications

When the access control policy in all domains is expressed in xacml, it may make 
sense to publish, share and exchange the authorization policy information in 
xacml-policy statements and xacml subject and resource attributes. Furthermore, 
the authorization policy matching would probably be greatly facilitated by the 
use of an xacml-processing engine on the scheduler.

Please note that for the use case, the scope has been carefully narrowed down to 
"pure" access control policy matching. Hopefully, this avoids any discussions 
that deal with the "scope" of xacml and its perceived overlap with ws-policy.

If I understand it well, then ws-policy-* is to be used to publish policy in a 
declaritive way, and does not address the matching process of capabilities to 
policies.

It is unclear how the ws-policy-* is to be used exactly to address the 
requirements associated with the use case.
Should xacml policy-rule statements be translated into ws-policy-langauage 
statements?
Or could ws-policy statements carry xacml-policy statements in a framework fashion?
How about the format for subject and resource attributes?


Suggestions and comments are most welcome!

Enjoy, Frank.


-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]