MHonArc v2.5.0b2 -->
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]