Re: [dipal-discuss] Re: Request for example Assertions

[Anne Anderson <Anne.Anderson@sun.com>]

It is true that XACML 2.0 can easily express all of this.  XACML is a 
fantastic language for expressing a service's own policy, and is also 
useful as a policy interchange format.  But full XACML 2.0 is not 
suitable for use as a web services policy assertion language.  Why not? 
Because the intersection of two XACML policies is not defined, and is 
not, in the general case, computable.  If one is concerned only with the 
provider service's policy, then using an XACML policy to represent the 
authorization components may be helpful: a consumer service developer 
could look the policy over and decide which Attributes and values need 
to be supplied and design the consumer interface to provide those 
Attributes.

But if the determination of mutually acceptable Attributes and values is 
to be made automatically, then there needs to be a way of computing the 
intersection of policies from a consumer and a provider, and knowing 
whether there are any sets of Attributes and values that can satisfy 
that intersection.  Full XACML, with its combining algorithms and 
complex functions, does not provide this capability.

For web services, the advantage of using a simple framework of Boolean 
operators along with efficiently-intersectable Assertions is that it is 
possible to determine whether two policies are compatible, and if so, 
what one policy can represent their mutually compatible sets of inputs. 
  In Disjunctive Normal Form, such an intersected policy can be used to 
select a set of inputs that will satisfy the policy.  A subset of XACML 
can represent such a Boolean combination of intersectable Assertions, 
and that is what XACML WSPL does.  But XACML WSPL is dead.  There are 
other proposals for the Boolean framework itself (WS-Policy, 
WS-Agreement) that still need intersectable Assertions. 
WS-PolicyConstraints takes a smaller subset of XACML WSPL that can be 
used within any of these frameworks to provider intersectable Assertions.

The current "hub-and-spoke" model for web services policies, where only 
the provider service has a policy and it is used to generate client 
stubs that clients must be programmed against (with the developer 
manually selecting one of the stubs that the client will use), will not 
support efficient dynamic composition and binding of services.  Only 
when consumer services AND provider services can express their policies, 
and those policies can be intersected, will it be possible to support 
dynamic service composition.

I will try to post WS-PolicyConstraints expressions for Paul's examples 
soon.

Regards,
Anne

Hal Lockhart wrote:

> XACML 2.0 can easily express all of this.
> 
>  
> 
> Hal
> 
>  
> 
> ________________________________
> 
> From: Paul OConnor [mailto:poconnor@e-brilliance.com] 
> Sent: Wednesday, January 18, 2006 11:38 PM
> To: dipal-discuss@lists.oasis-open.org
> Subject: [dipal-discuss] Re: Request for example Assertions
> 
>  
> 
> I wonder how access control assertions and policy can be expressed and
> so I would propose the following very common use case in financial
> services applications:
> 
>  
> 
> An equities trading service enforces access control policy which
> leverages subject attributes from the firms identity store:
> 
>  
> 
> User role (trader, manager, etc.)
> 
> Trade limit (max trade without additional approval)
> 
> Trading hours (can trade after hours?)
> 
> Trade location (can trade from home or office only)
> 
>  
> 
> Along with context variables:
> 
>  
> 
> Amount of trade
> 
> Type of trade
> 
> Equity being traded
> 
> Additional approval flag
> 
>  
> 
> These attributes must be asserted by the client making the request,
> e.g., a trade portal. The policy enforcement infrastructure would then
> calculate a policy decision before the service was ever invoked.
> 
>  
> 
>  
> 
> 

-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA