OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
Back to discussions
Expand all | Collapse all

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

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

    Posted 12-20-2006 22:00 
    Anne -- 
 
For what it's worth, in my organization we have been viewing privacy rules as just one of several sets of rules controlling access (to data assets.)  We envisioned each set of rules as being managed by a separate authority (e.g., Chief Privacy Officer for privacy rules based on the Privacy Act) using some tooling interface of the PAP and being applied jointly in the access-control PDP.  
 
This implies a potentally large set of rules, which may raise some engineering issues (lots more cycles determining access than in executing query.) 
 
It also suggests the need for a "consistency check" (in the PAP?) to make sure rules don't contradict each other. (For extra value-added, create a "rules inconsistency resolution" service to facilitate among rules authorities.) 
 
Martin
 
 
Martin F. Smith
Program Manager, Information Sharing & Identity Management
DHS CIO Office
202 447-3743 (New! as of 10/2006)
202 441-9731 cell
 

________________________________

From: xacml-return-125-martin.smith=dhs.gov@lists.oasis-open.org on behalf of Anne Anderson - Sun Microsystems
Sent: Wed 12/20/2006 3:30 PM
To: Anthony Nadalin
Cc: Rich Levinson; xacml@lists.oasis-open.org
Subject: Re: [xacml] New Issue#61: WS-XACML: How are the contents of XACMLAuthzAssertions represented in the base XACML Policies





Anthony Nadalin wrote On 12/20/06 10:12,:
> 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

XACMLAssertions were originally designed as a way to include XACML
policies in WS-Policy instances, and thus tie XACML more directly to Web
services, but the XACMLAssertions are certainly useful for more than
WS-Policy.  WS-Authorization and WS-Privacy have been mentioned numerous
times, although I have not seen anything moving forward, and it seems to
me that the XACMLAuthzAssertion and the XACMLPrivacyAssertion should be
able to fill the roles possibly envisioned for those two specifications.

The other two parts of the WS-XACML specification - the authorization
token and passing Attributes in the SOAP header - are more explicitly
Web services oriented.

That said, the XACMLAssertions are useful both in WS-Policy and in other
contexts.  I have proposed dropping the non-Assertion sections from
WS-XACML, and if so, I would be open to changing the name to something
like "XACML Authorization and Privacy Policy Assertions" (XAPPA? :-)

> 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

Are you referring to ways an XACMLAssertion could refer to WS-Security
claims used in the SOAP Security Header?  I could define a new standard
vocabulary identifier for such claims, and could give an example of
placing constraints on them.  Do you want to supply an example of a
claim you would like to see used?

> 3) there are 2 sides the requestor and receiver, each should be able to
> represent policy, not seeing this clearly in this proposal

Section 6 of WD 8 shows a client XACMLPrivacyAssertion and a Service
XACMLPrivacyAssertion.  What more would you like to see?

The academic team I am working with has made use of XACMLAssertions in a
multi-stage privacy policy negotiation protocol, so once our paper is
finished, perhaps I could include that as an example that would show the
two sides even more clearly.

Thanks for the review and comments.

Regards,
Anne

>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> Inactive hide details for Anne Anderson - Sun Microsystems
>


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

    Posted 12-21-2006 15:03 
    The features of XACML 2.0 perfectly match these requirements. The use of
policies and policy sets along with policy combining algorithms allows
policies that address different concerns (privacy, application
structure, regulatory requirements), or different scopes (department,
division, organization) to be created by distinct administrators who are
not closely coordinating their activities. The processing rules of XACML
will automatically collect all the policies relevant to a given
situation and the combining rules will resolve any conflicts.

In past, we have had debates as to whether or not there is such a thing
as a policy consistency check. At a minimum there are numerous
difficulties with determining if a set of policies "conflict" in the
intuitive sense of the word, except in the most simple and obvious
cases. 

Of course if I have a policy with two rules, one of which says if
subject is a member of the foo group, permit and another which says if
subject is a member of the foo group, deny, intuitively we would say
this is probably not how the policy was intended to be written. However,
XACML has no problem evaluating such a policy and giving a deterministic
answer (which depends on the combining algorithm in force). A tool to
detect this kind of thing could be developed, but many feel it would
have little value as this thing is easy for a person to spot and few
policies are written this way.

Now consider a more realistic example. Suppose one policy says members
of the foo group can access resources with the bar attribute value
greater than 100 and another policy says that members of the blah group
are not allowed to access resources with a splat attribute value of less
than 1000. Are these conflicting? The answer depends on the assignment
of attributes to subjects and resources. It also may depend on the
particular access request. Further, the attribute assignments may not be
known at the time of policy creation. In fact, the assignments my change
over the lifetime of the policies so that at one point in time they
always conflict and at other time the never conflict and perhaps at a
third time they conflict for some requests and not for others.
  
Hal

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  Re: [xacml] New Issue#61: WS-XACML: How are the contents ofXACMLAuthzAssertions represented in the base XACML Policies

    Posted 12-21-2006 16:38 
    Here is another common example of difficulty in determining 
"conflicting" rules.  Consider the following Policy:



If Anne is a member of Group X, these "conflict" in that Anne is 
permitted access according to Rule A, but is denied access according to 
Rule B.  But in most cases, this type of "conflict" is just a typical 
use case for "deny" rules: write a general Permit rule that covers most 
cases (Rule A), but then handle exceptions with Deny rules (Rule B). 
Note that if only "Permit" rules or only "Deny" rules are used, there 
will never be "conflicts", just possible overlaps.

As Hal points out, the combining algorithms handle every such "conflict" 
according to the direction of the policy writer, so no analysis tool can 
tell whether they are intentional or not.  Even the case of two 
identical Rules, with identical effective Targets and chains of 
combining algorithms (computed using all encompassing Policy and 
PolicySet elements), with one returning "Permit" and the other returning 
"Deny", is not necessarily a "conflict", since they must be considered 
in the context of other Rules in their respective encompassing Policies.

The use of PolicySets, each covering some specific area of concern, 
allows groups of Rules and Policies to be managed by the people who are 
responsible for that area.  They can be responsible for ensuring that 
"their" PolicySet correctly reflects their intentions.  They can also 
raise a concern if they feel "their" PolicySet is being incorrectly 
combined with other PolicySets at higher levels.  The XACML 3.0 
Administrative Policy allows an organization to control who can specify 
policies that affect some particular area of concern.

Regards,
Anne

Hal Lockhart wrote:

> The features of XACML 2.0 perfectly match these requirements. The use of
> policies and policy sets along with policy combining algorithms allows
> policies that address different concerns (privacy, application
> structure, regulatory requirements), or different scopes (department,
> division, organization) to be created by distinct administrators who are
> not closely coordinating their activities. The processing rules of XACML
> will automatically collect all the policies relevant to a given
> situation and the combining rules will resolve any conflicts.
> 
> In past, we have had debates as to whether or not there is such a thing
> as a policy consistency check. At a minimum there are numerous
> difficulties with determining if a set of policies "conflict" in the
> intuitive sense of the word, except in the most simple and obvious
> cases. 
> 
> Of course if I have a policy with two rules, one of which says if
> subject is a member of the foo group, permit and another which says if
> subject is a member of the foo group, deny, intuitively we would say
> this is probably not how the policy was intended to be written. However,
> XACML has no problem evaluating such a policy and giving a deterministic
> answer (which depends on the combining algorithm in force). A tool to
> detect this kind of thing could be developed, but many feel it would
> have little value as this thing is easy for a person to spot and few
> policies are written this way.
> 
> Now consider a more realistic example. Suppose one policy says members
> of the foo group can access resources with the bar attribute value
> greater than 100 and another policy says that members of the blah group
> are not allowed to access resources with a splat attribute value of less
> than 1000. Are these conflicting? The answer depends on the assignment
> of attributes to subjects and resources. It also may depend on the
> particular access request. Further, the attribute assignments may not be
> known at the time of policy creation. In fact, the assignments my change
> over the lifetime of the policies so that at one point in time they
> always conflict and at other time the never conflict and perhaps at a
> third time they conflict for some requests and not for others.
>   
> Hal
> 
> 
>>
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content