cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
Subject Re: WS-SX
Date Mon, 24 Sep 2007 15:17:13 GMT
Very interesting comments, Sergey.  Remarks in-line.

On Sep 23, 2007, at 8:24 AM, Sergey Beryozkin wrote:

> 1.       The core policy framework needs to be enhanced a bit to  
> deal with
> the normalization of nested polices which are abound in WS- 
> SecurityPolicy
> policies, to deal with the effective policy calculation when multiple
> Ws-SecurityPolicy polices are attached to multiple points for a  
> given policy
> subject like Endpoint, etc.

That's good to know.

> 2.       Supporting those policy assertions which map to what CXF  
> security
> runtime already supports would be a great start IMHO. This includes an
> HTTPS-related assertion too.

Good point.  The same issues come up with specification of key  
material there, too (relevant to your remakes below).

> A separate comment on a WS-Security feature. I strongly believe  
> that we need
> to revisit the guidelines on when to use WS-Policy expressions as  
> opposed to
> CXF features.
> For ex, lets take WS-SecurityPolicy which we all agree is worth  
> supporting.
> WS-SecurityPolicy policy expressions are in themselves can do the
> configuration just fine.

I am less certain of that.  Yes, technically WS-SP is capable of that  
(modulo specification of key material); the question is; i) were they  
designed for that, and ii) do we really want to inflict that kind of  
pain on applications?  Do we provide tooling for writing this?  Or is  
it a matter of BYO?  (Also known as, "vi or emacs").

> But using policy expressions provides for much more than just  
> statically
> configuring the runtime. They allow for a next to unlimited set of
> enhancements be applied to the consumer of services annotated with  
> such polices. Hence when thinking on how a given capability or  
> requirement should be  configured one should prefer using
> policy expressions when such requirements can be of use to a client/ 
> consumer.

That's a fairly normative statement, there, Sergey!  One shouldn't  
use "should" :)

> If we take WS-SecurityPolicy then we can see its policy expressions  
> are
> about expressing requirements to the consumers. Configuration is a  
> positive
> side-effect. One can attach such a WS-SecurityPolicy assertion either
> directly in a WSDL, or using an external attachment mechanism  
> supported by
> CXF. I believe Metro and Axis2 support both approaches.  Either  
> way, the
> question arises where to put the private stuff, like the key material
> location, passwords, and the like. One approach is to put them  
> inside the
> policy expression and strip them out at a WSDL publication time.

That seems fraught with the chance of error, to me.  What assurance  
do you have that a private key (password) doesn't "leak"?

> Another
> approach is to put the private stuff outside the policy expression  
> but then
> merge the information from multiple sources.

I think that's Microsoft's approach, and I think it's basically the  
right one.  The spec is mute on this information (righty), as it has  
no role in what policy is there for (viz., reducing -- not  
necessarily eliminating -- the amount of out-of-band agreement that  
would otherwise be needed to get 2 endpoints to communicate).

> Either approach has its pros
> and cons. The latter approach, by the way, works perfectly well with
> Java-first style of service development, the runtime could smartly  
> annotate
> the WSDL at a publication time, which is what Metro can do.

I'm not sure what you mean here.  Did you mean "former approach"?   
What's the connection between WSDL annotations and private key  
material?  (Or was this in reference to a previous point?)

> So lets have a look at a WS-Security feature. Basically I believe  
> that if we
> start supporting WS-SecurityPolicy then the WS-Security feature  
> becomes
> redundant/obsolete.  If one uses WS-SecurityPolicy then one does  
> not need to
> use WS-Security feature, and if one uses a WS-Security feature then  
> there's
> no point in using WS-SecurityPolicy.

I think that depends a lot on how you look at what the feature /does/  
(or can do).  For example, you could think of a feature as playing  
several roles in the runtime:

  *) as a "user-friendly" way to configure behavior at an endpoint

     Most applications probably use pretty simplistic scenarios, and  
may not require the full flexibility of configuration at, say, the  
granularity of a WSDL operation.

  *) as a "compiler" of WS-SP

     Configuration of a feature could result in the publication of WS- 
SecurityPolicy in a WSDL endpoint.

  *) as a configuration mechanism for interoperability with non- 
policy-aware applications

     Not all applications with which a CXF endpoint are policy- 
aware.  So, for example, you might /need/ some kind of config,  
because a service has not published policy in its service contract.

  *) (as you say below) as a mechanism for specification of key material

     I like that approach.

Also, don't underestimate the importance of programmatic  
configuration of key material.  There is a strong tendency to push  
configuration into a file (or other resource), but when you're  
dealing with applications that have key material in memory (or have  
obtained it via their own methods), we need to be able to provide a  
facility for specifying this material programatically.  We do that  
now, for example, in the case of TLS (well, https, at least).

> Supporting both WS-SecurityPolicy and
> WS-Security feature will add to the confusion people already when  
> choosing
> how to configure a given capability.

Im less inclined to use WS-SecurityPolicy as a configuration  
mechanism, at least exclusively so.  It's not really designed to be  
human-readable, despite the fact that it's written in XML, and XML is  
supposed to be human-readable, etc etc.

I'm also not sure I buy the argument that having more than one way to  
do things is inherently confusing to users.  That kind of confusion  
can be managed by well-written documentation, and a clear delineation  
of roles.  For example, if feature-based config is a generator for WS- 
SecurityPolicy, and there are alternative mechanisms for specifying  
policy at a low level (with proper support for conflict resolution),  
then the complexity can be kept under control.

> Additionally, using policies one can
> annotate the contract at a very fine-grained fashion, which is not  
> possible
> when using features.

Again, I'd ask whether this is really something that's needed, in  
 >20% of the cases.  In any event, if you have the option to do both  
low-level config through WS-SP, and coarser config though a feature,  
you cover the 80% case with low complexity.

So, to summarize:

  *) I disagree that specification of key material should be done  
through WSDL and/or WS-Policy; that's not what it's for, and there is  
a real risk of compromise of security-sensitive information this way
  *) I am more inclined to view feature-based config as a kind of  
simplification of policy-based config, and as a potential generator  
of policy, which makes it complementary to policy, not orthogonal
  *) I agree that in some small percentage of cases, we need to  
support configuration of WS-SecurityPolicy directly, and at a low  
level, but these cases fall below the 20% bar, and can certainly be  
exposed through low-level config.


PS> Another topic to raise in all this is the distinction between  
policy, as it is expressed in a service contract, and any client-side  
security requirements.  For example, I'm a voting machine client and  
I want to make sure the vote I cast i) goes to the voting machine  
server, and is is confidentiality and integrity protected.  Is that a  
"policy", in your sense?  How do I express it?  How do I enforce it.   
(Cuz I ain't submitting my vote until I know the policy constraints  
are satisfied.)

Still another consideration is what to do in the case where you're no  
using SOAP.  But I suppose this discussion is really limited to SOAP,  
specifically, as the WS-SecurityPolicy spec is limited in scope to  
the use of WS-Security.

View raw message