OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  Preliminary review of WS-XACML

    Posted 06-19-2008 06:20
    At the last XACML TC mtg, Jun 5, I agreed to raise my concerns
    about WS-XACML to the TC list about pushing XACML policy
    expressions to the periphery in the sense that they would appear
    within WS-Policy assertions.
    
    In the process, I have reviewed the spec again and have a number
    of detailed comments to make about it, but have not yet had the
    time to assemble everything together in a cohesive fashion, so in
    the interest of keeping things moving, I will provide a summary of
    my findings here.
    
    As a result of this recent review, I have revised my thinking considerably
    about this spec. In particular, I believe in my early reviews of the 
    material
    I had underestimated the scope of what the spec is trying either explicitly
    or implicitly to accomplish. At one level, I can now see it as a serious
    attempt at a "grand unification theory" of XACML and WS-Policy.
    
    The first major factor that the spec addresses is an abstraction of 
    WS-Policy,
    itself. In particular, by representing assertions as combinations of 
    Requirements
    and Capabilities, the spec makes explicit the structure of WS-Policy 
    which is
    somewhat lost in the extremely abbreviated assertion representations found
    in specs such as WS-SecurityPolicy. (Note: there are background refs, which
    include a representation of WS-SP using the same constructs used in 
    WS-XACML,
    which I have not reviewed yet, but does promise to be interesting.)
    
    The 2nd major factor the spec addresses is the notion of vocabularies, 
    where
    a vocabulary is associated with a policy domain, such as authorization,
    privacy, or system-specific policy domains. In each vocabulary is a 
    mechanism
    for expressing constraints on the variables within the vocabulary. The 
    constraints,
    themselves, are abstracted so that basically any policy domain can be mapped
    into a XACML policy domain, and theoretically the client and server can
    determine dynamically whether their respective Requirements and Capabilities
    are mutually acceptable. Generally, the client does the evaluation of 
    its own
    assertions vs the assertions it obtains from the server's wsdl.
    
    A 3rd major factor that is only lightly touched on is the notion that 
    the "advertised"
    or "published" policy (i.e. that which appears as assertions in 
    WS-Policy) MUST
    be a subset of the "internal" or enterprise policy used by the policy 
    publisher
    for policy evaluation. There is a brief section (10) that talks about 
    "managing"
    policies and how segments of internal policy might be tagged for 
    external publication.
    
    A 4th significant factor is the list of supported constraint functions 
    in Appendix A.
    These are clearly a subset of the more general xacml function set. Some 
    information
    needs to be elaborated as to where the lines are drawn between 
    core-xacml and
    ws-xacml functions and any significance there is to that boundary.
    
    It becomes quickly apparent that when we model the whole situation we have
    possibly 4 or 5 familiar actors involved in the overall process:
    
        - the service, itself, with its advertised wsdl
        - the client, with its own internal capabilities represented as 
    assertions
        - the PEP, that intercepts the client request and is responsible for 
    constructing
           a XACML authorization request based on the request and other 
    available
           context.
        - the PDP, that processes the authorization request against its set 
    of policies.
        - an admin entity that specifies the policy that is used by the PDP 
    and the
           advertised policy that is published by the service.
    
    This is a broader model than that which is envisioned in the original 
    xacml core
    spec, particularly the domain of advertised policy which until now has been
    pretty much the exclusive domain of WS-Policy.
    
    My basic conclusion is that the spec appears to be quite sound in 
    concept and
    detail. However, the breadth of its scope is such that a significant 
    amount of
    additional analysis is needed to determine if the abstractions are 
    optimal for the
    overall problem space being addressed or whether they carry the inherent
    complexity and capabilities of xacml out to a space where a less complex
    expression mechanism would be more appropriate.
    
    It seems appropriate to me that the TC might want to spend some cycles
    addressing the high level problem space that WS-XACML is addressing
    and determine if we think this spec is worth promoting for the broad
    purposes that it appears capable of addressing.
    
        Thanks,
        Rich
    


  • 2.  Re: [xacml] Preliminary review of WS-XACML

    Posted 06-19-2008 13:28
    Rich,
    
    I still dont understand why there is an interesting use-case for 
    combining WS-Policy and XACML.
    
    Why would an entity advertise its authorization policies using 
    WS-Policy? An example would probably help folks like me who have a 
    superficial
    understanding of XACML.
    
    - prateek
    > At the last XACML TC mtg, Jun 5, I agreed to raise my concerns
    > about WS-XACML to the TC list about pushing XACML policy
    > expressions to the periphery in the sense that they would appear
    > within WS-Policy assertions.
    >
    > In the process, I have reviewed the spec again and have a number
    > of detailed comments to make about it, but have not yet had the
    > time to assemble everything together in a cohesive fashion, so in
    > the interest of keeping things moving, I will provide a summary of
    > my findings here.
    >
    > As a result of this recent review, I have revised my thinking 
    > considerably
    > about this spec. In particular, I believe in my early reviews of the 
    > material
    > I had underestimated the scope of what the spec is trying either 
    > explicitly
    > or implicitly to accomplish. At one level, I can now see it as a serious
    > attempt at a "grand unification theory" of XACML and WS-Policy.
    >
    > The first major factor that the spec addresses is an abstraction of 
    > WS-Policy,
    > itself. In particular, by representing assertions as combinations of 
    > Requirements
    > and Capabilities, the spec makes explicit the structure of WS-Policy 
    > which is
    > somewhat lost in the extremely abbreviated assertion representations 
    > found
    > in specs such as WS-SecurityPolicy. (Note: there are background refs, 
    > which
    > include a representation of WS-SP using the same constructs used in 
    > WS-XACML,
    > which I have not reviewed yet, but does promise to be interesting.)
    >
    > The 2nd major factor the spec addresses is the notion of vocabularies, 
    > where
    > a vocabulary is associated with a policy domain, such as authorization,
    > privacy, or system-specific policy domains. In each vocabulary is a 
    > mechanism
    > for expressing constraints on the variables within the vocabulary. The 
    > constraints,
    > themselves, are abstracted so that basically any policy domain can be 
    > mapped
    > into a XACML policy domain, and theoretically the client and server can
    > determine dynamically whether their respective Requirements and 
    > Capabilities
    > are mutually acceptable. Generally, the client does the evaluation of 
    > its own
    > assertions vs the assertions it obtains from the server's wsdl.
    >
    > A 3rd major factor that is only lightly touched on is the notion that 
    > the "advertised"
    > or "published" policy (i.e. that which appears as assertions in 
    > WS-Policy) MUST
    > be a subset of the "internal" or enterprise policy used by the policy 
    > publisher
    > for policy evaluation. There is a brief section (10) that talks about 
    > "managing"
    > policies and how segments of internal policy might be tagged for 
    > external publication.
    >
    > A 4th significant factor is the list of supported constraint functions 
    > in Appendix A.
    > These are clearly a subset of the more general xacml function set. 
    > Some information
    > needs to be elaborated as to where the lines are drawn between 
    > core-xacml and
    > ws-xacml functions and any significance there is to that boundary.
    >
    > It becomes quickly apparent that when we model the whole situation we 
    > have
    > possibly 4 or 5 familiar actors involved in the overall process:
    >
    >    - the service, itself, with its advertised wsdl
    >    - the client, with its own internal capabilities represented as 
    > assertions
    >    - the PEP, that intercepts the client request and is responsible 
    > for constructing
    >       a XACML authorization request based on the request and other 
    > available
    >       context.
    >    - the PDP, that processes the authorization request against its set 
    > of policies.
    >    - an admin entity that specifies the policy that is used by the PDP 
    > and the
    >       advertised policy that is published by the service.
    >
    > This is a broader model than that which is envisioned in the original 
    > xacml core
    > spec, particularly the domain of advertised policy which until now has 
    > been
    > pretty much the exclusive domain of WS-Policy.
    >
    > My basic conclusion is that the spec appears to be quite sound in 
    > concept and
    > detail. However, the breadth of its scope is such that a significant 
    > amount of
    > additional analysis is needed to determine if the abstractions are 
    > optimal for the
    > overall problem space being addressed or whether they carry the inherent
    > complexity and capabilities of xacml out to a space where a less complex
    > expression mechanism would be more appropriate.
    >
    > It seems appropriate to me that the TC might want to spend some cycles
    > addressing the high level problem space that WS-XACML is addressing
    > and determine if we think this spec is worth promoting for the broad
    > purposes that it appears capable of addressing.
    >
    >    Thanks,
    >    Rich
    >
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  You may a link to this group and all your TCs in 
    > OASIS
    > at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    


  • 3.  RE: [xacml] Preliminary review of WS-XACML

    Posted 06-19-2008 13:37
    Prateek,
    
    The use case is for advertising and matching more fine grained access control and privacy policy requirements than provided by WS-SecurityPolicy.
    
    For example, WS-SP can say "Use a SAML Assertion". With WS-XACML you can say "access subject must have a Group attribute with the value of Administrator".
    
    WS-XACML also provides a more fine grained matching mechanism which is still syntactic in nature and does not require understanding of the semantics of the individual elements of the policy.
    
    WS-XACML uses syntax from XACML as well as P3P to meet these requirements. The use of XACML is not a goal, simply an implementation choice.
    
    Hal
    
    > 


  • 4.  Re: [xacml] Preliminary review of WS-XACML

    Posted 06-19-2008 14:35
    This seems an incredible amount of effort to reach some very modest goals...
    
    As Ramana points out, there are existing SecurityPolicy extensions and 
    extension points  that could support the required functionality
    
    I dont see the use-case where fine-grained Az needs to be advertised 
    across enterprise or other boundaries; again, this seems an interesting 
    project but I dont see a lot of folks asking for this...
    
    - prateek
    > Prateek,
    >
    > The use case is for advertising and matching more fine grained access control and privacy policy requirements than provided by WS-SecurityPolicy.
    >
    > For example, WS-SP can say "Use a SAML Assertion". With WS-XACML you can say "access subject must have a Group attribute with the value of Administrator".
    >
    > WS-XACML also provides a more fine grained matching mechanism which is still syntactic in nature and does not require understanding of the semantics of the individual elements of the policy.
    >
    > WS-XACML uses syntax from XACML as well as P3P to meet these requirements. The use of XACML is not a goal, simply an implementation choice.
    >
    > Hal
    >
    >   
    >> 


  • 5.  RE: [xacml] Preliminary review of WS-XACML

    Posted 06-19-2008 15:29
    All --
    
    " I dont see the use-case where fine-grained Az needs to be advertised 
    across enterprise or other boundaries; again, this seems an interesting 
    project but I dont see a lot of folks asking for this..."
    
    Fine-grained Az across enterprise and across enterprises is precisely
    what we are looking for, for consistent application of privacy and
    security policies in national shared space for law enforcement,
    counter-terrorism and public safety.  I expect the same will be needed
    for Health-IT and for compliance (e.g., SARB-OX) applications.
    
    Martin
    
    
    Martin F Smith
    Chief, National Security Systems Branch
    DHS
    
    


  • 6.  Re: [xacml] Preliminary review of WS-XACML

    Posted 06-19-2008 15:55
    Prateek, All,
    
    Wasn't this issue opened up precisely because users had asked Hal that 
    it should be brought up to a higher level towards a standard because 
    they were using it? Correct me if I am wrong.
    
    I cannot vouch for how many would want to use it since I am no expert on 
    WS-Policy, but if users are asking for it, I am in favour of making it 
    more than just a working draft.
    
    There is one technical issue which needs to resolved: the recent changes 
    to xpaths in 3.0 means that it needs to be updated.
    
    And, I don't understand one issue: when a service posts a privacy 
    requirement, how does the client become bound to the requirement? I sent 
    an email to Anne asking for clarification. It might be just that I have 
    misunderstood the proposal, or there is a mode of policy exchange which 
    I am not aware of.
    
    Regards,
    Erik
    
    
    Prateek Mishra wrote:
    > This seems an incredible amount of effort to reach some very modest 
    > goals...
    >
    > As Ramana points out, there are existing SecurityPolicy extensions and 
    > extension points  that could support the required functionality
    >
    > I dont see the use-case where fine-grained Az needs to be advertised 
    > across enterprise or other boundaries; again, this seems an 
    > interesting project but I dont see a lot of folks asking for this...
    >
    > - prateek
    >> Prateek,
    >>
    >> The use case is for advertising and matching more fine grained access 
    >> control and privacy policy requirements than provided by 
    >> WS-SecurityPolicy.
    >>
    >> For example, WS-SP can say "Use a SAML Assertion". With WS-XACML you 
    >> can say "access subject must have a Group attribute with the value of 
    >> Administrator".
    >>
    >> WS-XACML also provides a more fine grained matching mechanism which 
    >> is still syntactic in nature and does not require understanding of 
    >> the semantics of the individual elements of the policy.
    >>
    >> WS-XACML uses syntax from XACML as well as P3P to meet these 
    >> requirements. The use of XACML is not a goal, simply an 
    >> implementation choice.
    >>
    >> Hal
    >>
    >>  
    >>> 


  • 7.  Re: [xacml] Preliminary review of WS-XACML

    Posted 06-19-2008 13:50
    Hi Prateek,
    
    Briefly for the moment, but more later:
    
    Use case:
    
        Administrator designs policy to protect resource that
        requires attributes: x,y,z
    
        x,y are available internally or from user authentication
        context/ldap etc, however, attr z must be obtained
        by user and accompanied by request.
    
        Therefore, admin wants to advertise "z" and include
        it somehow in ws-policy so user client can work w
        user to obtain z before submitting request.
    
    That's all I can say in this short time.
    
        Thanks,
        Rich
    
    
    Prateek Mishra wrote:
    > Rich,
    >
    > I still dont understand why there is an interesting use-case for 
    > combining WS-Policy and XACML.
    >
    > Why would an entity advertise its authorization policies using 
    > WS-Policy? An example would probably help folks like me who have a 
    > superficial
    > understanding of XACML.
    >
    > - prateek
    >> At the last XACML TC mtg, Jun 5, I agreed to raise my concerns
    >> about WS-XACML to the TC list about pushing XACML policy
    >> expressions to the periphery in the sense that they would appear
    >> within WS-Policy assertions.
    >>
    >> In the process, I have reviewed the spec again and have a number
    >> of detailed comments to make about it, but have not yet had the
    >> time to assemble everything together in a cohesive fashion, so in
    >> the interest of keeping things moving, I will provide a summary of
    >> my findings here.
    >>
    >> As a result of this recent review, I have revised my thinking 
    >> considerably
    >> about this spec. In particular, I believe in my early reviews of the 
    >> material
    >> I had underestimated the scope of what the spec is trying either 
    >> explicitly
    >> or implicitly to accomplish. At one level, I can now see it as a serious
    >> attempt at a "grand unification theory" of XACML and WS-Policy.
    >>
    >> The first major factor that the spec addresses is an abstraction of 
    >> WS-Policy,
    >> itself. In particular, by representing assertions as combinations of 
    >> Requirements
    >> and Capabilities, the spec makes explicit the structure of WS-Policy 
    >> which is
    >> somewhat lost in the extremely abbreviated assertion representations 
    >> found
    >> in specs such as WS-SecurityPolicy. (Note: there are background refs, 
    >> which
    >> include a representation of WS-SP using the same constructs used in 
    >> WS-XACML,
    >> which I have not reviewed yet, but does promise to be interesting.)
    >>
    >> The 2nd major factor the spec addresses is the notion of 
    >> vocabularies, where
    >> a vocabulary is associated with a policy domain, such as authorization,
    >> privacy, or system-specific policy domains. In each vocabulary is a 
    >> mechanism
    >> for expressing constraints on the variables within the vocabulary. 
    >> The constraints,
    >> themselves, are abstracted so that basically any policy domain can be 
    >> mapped
    >> into a XACML policy domain, and theoretically the client and server can
    >> determine dynamically whether their respective Requirements and 
    >> Capabilities
    >> are mutually acceptable. Generally, the client does the evaluation of 
    >> its own
    >> assertions vs the assertions it obtains from the server's wsdl.
    >>
    >> A 3rd major factor that is only lightly touched on is the notion that 
    >> the "advertised"
    >> or "published" policy (i.e. that which appears as assertions in 
    >> WS-Policy) MUST
    >> be a subset of the "internal" or enterprise policy used by the policy 
    >> publisher
    >> for policy evaluation. There is a brief section (10) that talks about 
    >> "managing"
    >> policies and how segments of internal policy might be tagged for 
    >> external publication.
    >>
    >> A 4th significant factor is the list of supported constraint 
    >> functions in Appendix A.
    >> These are clearly a subset of the more general xacml function set. 
    >> Some information
    >> needs to be elaborated as to where the lines are drawn between 
    >> core-xacml and
    >> ws-xacml functions and any significance there is to that boundary.
    >>
    >> It becomes quickly apparent that when we model the whole situation we 
    >> have
    >> possibly 4 or 5 familiar actors involved in the overall process:
    >>
    >>    - the service, itself, with its advertised wsdl
    >>    - the client, with its own internal capabilities represented as 
    >> assertions
    >>    - the PEP, that intercepts the client request and is responsible 
    >> for constructing
    >>       a XACML authorization request based on the request and other 
    >> available
    >>       context.
    >>    - the PDP, that processes the authorization request against its 
    >> set of policies.
    >>    - an admin entity that specifies the policy that is used by the 
    >> PDP and the
    >>       advertised policy that is published by the service.
    >>
    >> This is a broader model than that which is envisioned in the original 
    >> xacml core
    >> spec, particularly the domain of advertised policy which until now 
    >> has been
    >> pretty much the exclusive domain of WS-Policy.
    >>
    >> My basic conclusion is that the spec appears to be quite sound in 
    >> concept and
    >> detail. However, the breadth of its scope is such that a significant 
    >> amount of
    >> additional analysis is needed to determine if the abstractions are 
    >> optimal for the
    >> overall problem space being addressed or whether they carry the inherent
    >> complexity and capabilities of xacml out to a space where a less complex
    >> expression mechanism would be more appropriate.
    >>
    >> It seems appropriate to me that the TC might want to spend some cycles
    >> addressing the high level problem space that WS-XACML is addressing
    >> and determine if we think this spec is worth promoting for the broad
    >> purposes that it appears capable of addressing.
    >>
    >>    Thanks,
    >>    Rich
    >>
    >> ---------------------------------------------------------------------
    >> To unsubscribe from this mail list, you must leave the OASIS TC that
    >> generates this mail.  You may a link to this group and all your TCs 
    >> in OASIS
    >> at:
    >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php