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