cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: WS-SX
Date Tue, 25 Sep 2007 17:27:32 GMT
Hi Fred

Very sorry for replying late. I've probably ignored the order of replies altready, sorry.

I think I see how are you looking ta the problem, I got it while replying to Dan's emails,
though
I got lost a bit in the end, hopefully Dan will clarify few things.

In meantime, can you please explain one thing to me.
What do you mean when you're saying : "CXF will support WS-SecurityPolicy" ?

I'll have a bunch of question later but for a start I'd like to see what do you mean under
"CXF will support WS-SecurityPolicy"

Few comments to your message.

>> 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").

By "configuration" I mean all the public stuff such policies have. As I said I believe policies
do two things : provide info to consumers and as a side effect, do configure the provider
(and play together
with features providing a private stuff).

What pain are you talking about  ? I don't think many people will really put those policies
manually in production environments, tools will do it for them.

>> 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" :)

Can I ask you the question : what is the purpose of WS-Policy polices in your understanding
?

As far as 'should' is concerned I don't understand your remark. I'm trying to reason here
not to tell anyone
how things 'must' be done.

> That seems fraught with the chance of error, to me.  What assurance  
> do you have that a private key (password) doesn't "leak"?
This with respect to putting a private stuff into polices and stripping them off...
Ok, as I said, I don't want to concentarte on this isse now. One advantage of supporting such
approach
is that it helps the toold to get all the info they need. Another one is that one does not
to get info form multiple sources, all info is available in one place.
Here's a question for you : What assurance do you have about configuration files not being
leaked or the runtime itself not messing up while dpoing the security stuff ? Tests ?
But as I said, I'm not too concerned about this issue for now.

>> 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?)

What I mean that if you have a policy, say, located in the external file, right and you do
a java-first
development that, if you use a policy, a published WSDL for a service will still have policies
attached to it and thus
providing all the info the consumers need to know about.

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

Policies do not negatively affect the interoperability they improve it.
Service provider with policies attached wil lreach to policy-aware consumers and to policy
unaware ones
as it's policy unaware ones which will need to be configured anyway.

Service provider with features won't reach to anyone (as far as facilitating the advanced
communication is concerned)

>  *) 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.

Don't understand it sorry.

 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.

If use use features you can't do intersection. If you use polices on both sides you can do
the intersection.

Thanks, Sergey

----- Original Message ----- 
From: "Fred Dushin" <fred@dushin.net>
To: <cxf-dev@incubator.apache.org>
Sent: Monday, September 24, 2007 4:17 PM
Subject: Re: WS-SX


> 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.
> 
> -Fred
> 
> 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.

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message