RE: [xacml] New Issue#61: WS-XACML: How are the contents of XACMLAuthzAssertions represented in the base XACML Policies

+1

abbie

 

From: Anthony Nadalin 
[mailto:] 
Sent: Wednesday, December 20, 2006 10:12 
AM
To: 
Cc: Rich Levinson; 

Subject: Re: [xacml] New Issue#61: 
WS-XACML: How are the contents of XACMLAuthzAssertions represented in the base 
XACML Policies

One thing that bothers me (well I have several), 

1) is why is this 
called WS ? as I'm not seeing a tie to web services, just to WS-Policy
2) 
missing the tie to WS-Security, as SAML is not the only assertions that are 
used, this effort should be able to tie into the claims used in 
WS-Security
3) there are 2 sides the requestor and receiver, each should be 
able to represent policy, not seeing this clearly in this proposal 

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
" 
src="gif00040.gif" width=16 border=0>Anne Anderson - Sun 
Microsystems <>

  
  

    
      
        
          
            Anne Anderson - Sun Microsystems 
              <> 
              
12/20/2006 08:23 AM 
              
                
                

                  
                    
Please respond 
                    to


    
      
        
        

          

            
To

          
Rich Levinson <>

        

          

            
cc

          


        

          

            
Subject

          
Re: [xacml] New Issue#61: WS-XACML: How are the contents of 
            XACMLAuthzAssertions represented in the base XACML 
        Policies

      
        
        

          
          

Hi 
Rich,

The problem to me with having WS-XACML policies integrated with 
other 
policies is that it is not possible in general to extract an isolated 

<Apply> statement from a normal policy - that <Apply> might be 
in the 
middle of an "...:and" function, for example, that requires it to be 

associated with other constraints.  Or it might be in an "...:or" such 

that it is not necessarily required to be true.

That was why I 
suggested that WS-XACML policies be contained in a 
top-level separate 
PolicySet.  The policies in that set can be "AND"ed 
with the remaining 
policies using an appropriate combining algorithm. 
Then during evaluation of 
the remaining policies, if you know the 
WS-XACML policies have already 
evaluated to "true", then you don't have 
to re-evaluate the WS-XACML 
PolicySet.

<PolicySet PolicySetId="all:policies"
    
        
PolicyCombiningAlg="ordered-deny-overrides">

    
<PolicySet PolicySetId="ws-xacml:policies"
        
    PolicyCombiningAlg="deny-overrides">

    
     <!-- These don't have to be re-evaluated if you know 
they
              must have been 
satisfied in order to get this far -->

        ... 
WS-XACML Assertion Requirements,
            
written as <Policy> elements ...

    
</PolicySet>

    <PolicySet 
PolicySetId="other:policies"
            
PolicyCombiningAlg="deny-overrides">

        ... 
Remaining policies, which can assume
          
  the WS-XACML Assertions have already
        
    evaluated to "true"/"permit" ...

    
</PolicySet>
</PolicySet>

Another idea is to use the 
WS-XACML policy constraints to partially 
evaluate the remaining policies. 
 For example, if you know that a 
WS-XACML policy requiring "role" to be 
a subset of {"manager", 
"auditor"} must evaluate to "true" before other 
policies are evaluated, 
then you can go through the remaining policies and 
replace any 
predicates that require "role" to be a subset of {"manager", 
"auditor"} 
with "True".  But I don't think it is worthwhile pursuing 
this: when 
there are multiple WS-XACML policy alternatives, you don't know 
which 
one will be the one that evaluated to "True", the cost of determining 

the intersections with every predicate in the other policies is high, 

and in many cases the intersections can't be fully evaluated (e.g. a 

predicate that says "role" must be a subset of {"manager", "individual 

contributor"}).

I misspoke yesterday when I said the Capabilities 
could be included in 
the overall XACML policies as "or"ed constraints. 
 The "Capabilities" 
are things the issuer of a policy is willing and 
able to do for the 
other party and, as such, play the role of an XACML 
Request to the other 
party, and not an XACML Policy that the other party 
must satisfy.  So 
above I said to write the only the Requirements as 
Policy elements in 
the WS-XACML 
PolicySet.

Regards,
Anne

Rich Levinson wrote On 12/19/06 
19:46,:
> Hi Anne,
> 
> I guess I have not been thinking along 
the lines of  "WS-XACML" policies
> as being a distinct class of 
xacml Policy, but that the info in this 
> profile would
> be worked 
into existing xacml Policy structures, but maybe the analysis
> below 
might be interpreted from either perspective.
> 
> Basically, the 
point of view I am looking at this from is that I see 
> that web
> 
service access is now effectively a 2 step process, whereas before 
> 
WS-Policy
> was introduced, it was essentially a 1 step process where one 
just 
> submitted one's
> request, for example using WS-Security, 
and hoped for the best.
> 
> It is clear the 2 step process has the 
advantage that in step 1, the 
> client is
> now formally told in 
advance, what the reqts are to successfully submit
> the request. Then, in 
step 2, based on the input from step 1, the client
> can construct a 
request that should be in compliance with the policy
> requirements that 
will be applied by service infrastructure when the
> request is 
submitted.
> 
> So, from my view, step 2 doesn't change that much 
from what currently
> exists today (except for new features such as the 
privacy obligations
> that are currently being included in this profile - 
I think the 
> "Capabilities"
> are also new, but I see them more 
relevant in step 1 than step 2 - i.e.
> if the client doesn't like the 
service capabilities, then it probably never
> gets to step 2).
> 

> Bottom line is that my expectation is that many XACMLAuthzAssertions 
that
> are supplied to the client will, in general, reflect aspects of 
existing 
> policies
> that are in current operation. For example, 
maybe a service requires 
> that a client
> submit a valid "gold 
club member number" in some element of the request 
> and this
> 
element is evaluated as part of authorization.
> 
> Now, in order to 
make the service more readily accessible by users, the 
> service
> 
provider decides to put a XACMLAuthzAssertion in the WSDL that will 
specify
> this constraint.
> 
> If you agree that the above is 
a possible or typical az type of 
> scenario, ...,
> then it appears 
to me the next logical concern is that: somehow, in the 
> Policy
> 
that contains the "gold card member number" constraint,  a "flag" of 
some
> sort would be appropriate to apply to that constraint in order that 
a 
> service
> provider would know by reading the Policy for that 
resource (presumably
> thru some TBD policy access/distribution 
mechanism). Possibly the 
> constraint
> could be a 
VariableDefinition that could be referenced in the main az 
> 
policy
> and a separate Policy segment for use in constructing 
XACMLAuthzAssertions.
> 
> My sense is that something would be 
useful in the WS-XACML profile that
> would advise on how to construct new 
policies and adapt existing policies
> to address this issue (i.e. issue 
61).
> 
> I think the profile identifies 3 major classes of 
info:
> 
>     Requirements of the az type - i.e. 
constraints that are typically
>        found in 
existing policies.
> 
>     Requirements of the privacy 
type - i.e. constraints that bind the 
> user as
>     
   to how the resource is used once acquired (these may be 
considered
>        just another az type in general, 
but they are "new" in the sense 
> that
>       
 they are things the user has to "agree to" and as such the user 
> 
needs
>        to know what is being agreed to, and 
how in the request to represent
>        the fact that 
the agreement is accepted). As such these reqts
>       
 may lend themselves to be separable off in a separate Policy or
> 
       PolicySet.
> 
>     
Capabilities in general - the service is simply adding info to be 
> 
presented
>        to users indicating things the 
service is willing to commit to, 
> and as such
>     
   would seem to be properly considered part of the Policy governing 

> the
>        publication and use of this 
service by the Provider organization.
> 
> Another path that might 
make sense would be to model these XACMLAssertions
> as xacml:Obligations, 
whereby the "obligation" would be to inform the user
> of this Policy 
info, which could be presented directly thru PEP access, 
> if, 
for
> example, the request was denied because something was missing that 
might
> be in this category of info (i.e. this would allow the info to 
provided 
> either
> in advance via WS-Policy or on the spot in a 
"1-step" manner).
> 
> I think the above or parts of it might be 
considered guidelines for a 
> possible
> proposal and explanatory 
context for what might be considered to be added
> to the profile, but it 
probably needs to be shaken out a bit, assuming that
> you and/or others 
think it's valid subject matter for this profile.
> 
> Also, I think 
it is possibly in synch with your proposal. i.e. it looks 
> to me like we 
are
> generally on the same path - ex. where you pointed out section 3.2 
for 
> containing
> Apply elements, I was considering those to be 
the az-type requirements, 
> and your
> site-specific naming 
convention looks like it might be similar to the 
> "flag" I 
suggested
> to apply to items in existing policies.
> 
> 
    Thanks,
>     Rich
> 
> Anne Anderson 
- Sun Microsystems wrote:
> 
>> Hi Rich,
>>
>> 
Thanks for the endorsement.
>>
>> As for identifying WS-XACML 
policies, I had not considered the 
>> problem, but it sounds like 
proposals might be useful.
>>
>> What occurs to me is to have 
all WS-XACML policies collected into a 
>> special PolicySet that is 
combined with other internal 
>> PolicySets/Policies so all are 
evaluated if necessary to reach a result.
>>
>> The WS-XACML 
PolicySet could have an identifier that uses a special 
>> 
site-specific naming convention: e.g. 
>> 
urn:somecompany:...:xacmlauthzassertion:policyset:20
>>
>> 
Isolated <Apply> elements don't occur in normal XACML, so for 
>> 
Requirements, they should be expressed as a Policy in the form 
>> 
described in Section 3.2.  For Capabilities, they should be expressed 

>> as a similar Policy, except using ...:function:or rather than 

>> ...:function:and to combine the <Apply> elements (I will add 
this 
>> equivalence to the next Revision).  Again, a 
site-specific naming 
>> convention could be used to notify the 
XACML...Assertion builder that 
>> the <Apply> elements from that 
policy MAY be extracted: e.g.
>> 
urn:somecompany:...:xacmlauthzassertion:requirements:25
>> 
urn:somecompany:...:xacmlauthzassertion:capabilities:25
>>
>> 
Requirements and Capabilities that "go together" could be put into 
>> 
individual PolicySet instances inside the "WS-XACML 
PolicySet".
>>
>> That certainly isn't a complete solution, 
and I need to think more 
>> about using Capabilities in a standard 
XACML policy, but maybe this is 
>> a start.
>>
>> 
Regards,
>> Anne
>>
>> Rich Levinson wrote On 
12/15/06 16:57,:
>>
>>> Hi 
Anne,
>>>
>>> I just want to mention that I think the 
profile is a great document
>>> and a really valuable example of how 
XACML can be applied.
>>>
>>> I quickly looked over your 
suggestion and I think I must not have
>>> expressed my point 
clearly.
>>>
>>> What I am thinking is that these 
XACMLAssertions,  both the
>>> XACMLAuthzAssertion and the 
XACMLPrivacyAssertions are
>>> elements that can be included in a 
ws:Policy elements and used
>>> in wsdl and other policy containers 
to express the requirements
>>> to clients as to what they need to 
do to successfully access the
>>> web service. I think we probably 
agree on that, and, if so, then
>>> I can get to what the issue is 
that I am considering.
>>>
>>> I would expect (correct 
me if I am wrong, but this is what I am
>>> thinking) that it is 
perfectly reasonable, if not likely, that these
>>> XACMLAssertions 
will be part of an overall xacml architecture
>>> in various 
enterprise environments. As such, it is likely that
>>> there are 
one or mores PDP out there in the enterprise that are the
>>> home 
of a collection of xacml policies, as well as being the decision
>>> 
points handling PEP requests.
>>>
>>> It is also my 
expectation that this PDP (or at least the people who
>>> adminster 
the PDP) will likely consider the Web Services to be
>>> Resources 
that its policies in general will cover.
>>>
>>> So, I 
put myself in the position of one of these PDP admins and
>>> ask 
myself, how do I create a XACML Policy that will contain all
>>> the 
info I want to govern the access to this web service Resource
>>> 
(as suggested by the para 2 in section 4, etc.). What I am 
thinking
>>> is that only a subset of this info should go to the 
XACMLAssertions,
>>> which will end up in the wsdl, but the rest of 
the info I want to keep
>>> private and just use at runtime to 
validate and authorize requests and
>>> produce Responses 
etc.
>>>
>>> So, the question is: how do I flag the 
subset of XACML Policy info
>>> that is targeted for the 
XACMLAssertions - I guess I am also assuming
>>> that the WebService 
Manager, in whatever form it will take, will in
>>> general make a 
XACMLRequest to the PDP to get the Policy or
>>> Policies governing 
this Resource. That Manager would then need to
>>> be able to select 
from the XACML Policy (as opposed to the WS Policy,
>>> which, on 
the other hand, the Manager is populating for setup etc.) the
>>> 
elements:
>>>
>>>       <element 
ref="*xacml:Policy*" minOccurs="*0*" maxOccurs="*1*" />
>>> 
      <element ref="*xacml:PolicySet*" minOccurs="*0*" 

>>> maxOccurs="*1*" />
>>>       
<element ref="*xacml:Apply*" minOccurs="*0*" 
>>> 
maxOccurs="*unbounded*" />
>>>   <element 
ref="*xacml-context:Request*" minOccurs="*0*" 
>>> maxOccurs="*1*" 
/>
>>>
>>> that can be moved from the xacml:Policy 
data to the Capabilities and 
>>> Resources
>>> elements 
of the XACML*Assertion.
>>>
>>> So, I am wondering what 
the original xacml:Policy, which I assume can 
>>> 
contain
>>> the source elements for these XACML*Assertions, will 
look like and 
>>> how one
>>> would go about selecting 
the appropriate info therefrom.
>>>
>>> Bottom line is 
that the examples you suggested below, appear to me to 
>>> be 
the
>>> final step of this process: i.e. some entity has put these 
ws:Policy 
>>> blocks as
>>> part of the wsdl or other 
that the client encounters before making 
>>> the 
actual
>>> access. To use your first 
example:
>>>
>>>     
<Requirements>
>>>        Has signed 
license agreement
>>>     
</Requirements>
>>>
>>> I would expect that 
somewhere in the PDP policy store that a 
>>> 
xacml:Attribute
>>> might exist with an AttributeValue: "Has signed 
license agreement", 
>>> and that
>>> when one queries 
the PDP for this xacml:Policy that they are able to 
>>> obtain 
this
>>> AttributeValue and put it in the Requirements element of 
the ws:Policy.
>>>
>>> OK, so now hopefully that 
explains how I am looking at this and maybe 
>>> 
there
>>> is some complete aspect to this that I am missing, that 
will help 
>>> explain it all.
>>>
>>> 
       Thanks,
>>>       
 Rich
>>>
>>>
>>>
>>>
>>> 
Anne Anderson - Sun Microsystems wrote:
>>>
>>>> Hi 
Rich,
>>>>
>>>> Thanks for the 
feedback.
>>>>
>>>> Rich Levinson wrote On 
12/15/06 
14:05,:
>>>>
>>>>>
>>>>> 
        61. WS-XACML: How are the contents of 
XACMLAuthzAssertions
>>>>>         
represented in the base XACML 
Policies
>>>>>
>>>>> (Submitted by: 
*Rich*)
>>>>>
>>>>> Reading the spec, it 
appeared to me that an important piece of info 
>>>>> might be 
missing (or either I missed it or it intentionally is not 

>>>>> there, but that's the point of this issue). As an entry 
point to 
>>>>> this potential issue, consider statement in 
Section 4, p 23, para 
>>>>> 2, that 
says
>>>>>
>>>>> "For security reasons, many 
entities are unwilling to publish their 
>>>>> complete 
authorization and access control policies. Therefore, an 

>>>>> XACMLAuthzAssertion </xacml/AuthzAssertion> MAY 
not be a complete 
>>>>> specification of an entity's 
authorization and access control 
>>>>> policy. A service MAY 
choose to publish all or a subset of the 
>>>>> 
XACMLauthorization or access control policy it will apply with 

>>>>> respect to particular policy 
targets."
>>>>>
>>>>> How are the subsets of 
the core xacml policies identified as to 
>>>>> what should 
and should not be made 
public?
>>>>
>>>>
>>>>
>>>>
>>>> 
It is completely site-dependent as to what is published and what 

>>>> isn't. Particular trade/service communities (on-line 
bookstores, 
>>>> etc.) might standardize policy vocabularies to 
be used in stating 
>>>> XACMLAuthzAssertions or 
XACMLPrivacyAssertions for their sites.
>>>>
>>>> 
As an example, Sun certainly isn't going to publish its enterprise 

>>>> policy.  But consider some fictitious software 
download site 
>>>> maintained by Sun; for this site, Sun might 
publish the following:
>>>>
>>>> 
<wsp:exactlyOne>
>>>>   
<XACMLAuthzAssertion>
>>>>     
<Requirements>
>>>>        Has signed 
license agreement
>>>>     
</Requirements>
>>>>     
<Capabilities>
>>>>        Provide 
trial version
>>>>     
</Capabilities>
>>>>   
</XACMLAuthzAssertion>
>>>>   
<XACMLAuthzAssertion>
>>>>     
<Requirements>
>>>>       Has signed license 
agreement
>>>>       Has paid for Level 3 
support
>>>>     
</Requirements>
>>>>     
<Capabilities>
>>>>       Provide current 
production version
>>>>     
</Capabilities>
>>>>   
</XACMLAuthzAssertion>
>>>> 
</wsp:exactlyOne>
>>>>
>>>> Would it help to 
include an example like this?
>>>>
>>>> Also, it 
would be of interest to
>>>>
>>>>> see some 
example policies that contained entities that end up in 
>>>>> 
the Capabilities and Requirements sections of the Assertions. I am 

>>>>> particularly interested in how privacy requirements 
might be set up 
>>>>> in the original policy since these are 
generally not part of the 
>>>>> authorization process, per 
se', but possibly could be considered to 
>>>>> be modelled as 
XACML Obligations. Any guidance on this in reply to 
>>>>> 
issue or changes to doc would be much 
appreciated.
>>>>
>>>>
>>>>
>>>> 
Consider a service policy saying the service will provide a copy of 

>>>> its current price list if the client agrees to retain it no 
longer 
>>>> than 30 days and not to disclose it to 3rd parties. 
 The service 
>>>> also says it will not disclose the 
client's personal information to 
>>>> 3rd 
parties.
>>>>
>>>>   
<XACMLPrivacyAssertion>
>>>>     
<Requirements>
>>>>       
 max-data-retention-days <= 30
>>>>       
 data-disclosure == "ours" }
>>>>     
</Requirements>
>>>>     
<Capabilities>
>>>>       
 resource-id="current-price-list"
>>>>       
 //p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of { "ours" 
}
>>>>     </Capabilities>
>>>> 
  </XACMLPrivacyAssertion>
>>>>
>>>> A 
client policy might say:
>>>>
>>>>   
<XACMLPrivacyAssertion>
>>>>     
<Requirements>
>>>>       
 resource-id="current-price-list"
>>>>       
 //p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of { "ours" 
}
>>>>     </Requirements>
>>>> 
    <Capabilities>
>>>>       
 max-data-retention-days <= 30
>>>>       
 data-disclosure == "ours" }
>>>>     
</Capabilities>
>>>>   
</XACMLPrivacyAssertion>
>>>>
>>>> There is 
another example using XACML's XML syntax in Section 6 of WD 
8.
>>>>
>>>> Is this what you are looking for? 
 If you could describe ways in 
>>>> which the examples in 
Section 6 are inadequate, I could provide more 
>>>> examples or 
better 
examples.
>>>>
>>>>>
>>>>> 
Status: *OPEN*
>>>>>
>>>>
>>

-- 

Anne H. Anderson             Email: 

Sun Microsystems Laboratories
1 Network 
Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 
USA  Fax: 781/442-1692