OASIS eXtensible Access Control Markup Language (XACML) TC

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

  • 1.  Use case to demonstrate the need to publish, exchange, process andmatch access control policy information

    Posted 08-14-2003 19:52
     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]