cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Re: WS-SX
Date Wed, 26 Sep 2007 16:39:26 GMT

On Sep 25, 2007, at 1:27 PM, Sergey Beryozkin wrote:

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

I looked over my previous posts on this thread, and I didn't see that  
quote.  I guess my answer is, "I don't know" :)

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

I see WS-Policy as more of a mechanism used by the runtime to  
dynamically drive behavior, than as a way to configure an endpoint.   
Policy can of course be used as a configuration mechanism, but that's  
really an implementation choice, on the part of the middle-ware  
vendor.  The policy specifications, qua specification, are there for  
one reason -- as a declarative specification of requirements or  
capabilities for various qualities of service (over and above what's  
already dictated by WSDL) supported by an endpoint.

In my view, a CXF Feature is a (vendor-specific) mechanism that  
allows developers to expose configuration to users without having to  
expose every last implementation detail of said feature.  So, for  
example, if your feature requires 12 interceptors for it to do it's  
job, you can tackle that with one fell swoop, as opposed to making  
the user configure each and every last interceptor.

This isn't to deliberately delude or throw off the user.  It's to  
give the feature implementor and the user some insulation from the  
inevitable implementation changes that will occur as the feature is  
maintained and enhanced.  Everyone wins.

Add to this custom XML beans, and you get some type safety, error  
detection based on schema validation, and even more insulation from  
low-level implementation details.  Could users drive all this through  
Spring?  Sure, be my guest.  But by doing that, you're exposing  
yourself to the potential for breakage, possible even after a minor  
product release.  Most users will prefer to use features, for that  
reason, and most implementors will prefer that users use features, as  
well.  Of course, all this is open source, so there's a gray line  
between what's supported and what's implemented.  But in most cases  
the choice is pretty clear.

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

Okay, that's fine, but what tools are you referring to, here?  These  
are provided by 3rd parties, right?  The CXF user is left to use,  
what, emacs?  That's an okay position, but we as a development team  
need to agree that that is acceptable.

I guess you can look at the role of a WS-Security Feature as a kind  
of "poor man's" tool, as it can also be used to generate WS- 
SecurityPolicy assertions.

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

WS-Policy, as I think I said before, is a mechanism for reducing  
(though perhaps not eliminating, all together) the amount of out-of- 
band agreement that would otherwise be required to get 2 endpoints to  
communicate with a desired Quality of Service (or Quality of  
Protection, in the case of WS-Security).

You seem to think that it can/should also be used as a mechanism for  
configuration, and while I agree that there are cases where that may  
be desirable (e.g., you mentioned policy alternatives, in a  
subsequent email, for example),

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

My apologies -- I was trying to add a bit of levity, but I may have  
offended you, in the process.  That was not my intention, and I  
apologize, if you were put off by it.

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

Right, and I appreciate your distinction here, between the 2 issues  
(where to put security-sensitive information, vs whether to use WS- 
Policy as a configuration tool).  And I also appreciate the fact that  
in this discussion, you and Eoghan have been talking about /options/  
for where to put "private" information.  I'm just expressing an  
opinion that this information should not be put in WSDL, and that the  
idea of preprocessing WSDL to strip out information of this nature  
has risk associated with it, and that in order to avoid that kind of  
risk, we should simply not architect a solution that associates  
security-sensitive information in way way with a service contract.

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

Fair 'nough.  I think it's more a matter of principle.  Policies are  
designed for the purpose of publication.  So if security-sensitive  
information is embedded in policy, there has to be a mechanism for  
non-disclosure, whereas if it's in, say, Spring, it is not /by  
design/ meant to be exposed.

> Policies do not negatively affect the interoperability they improve  
> it.

No point of disagreement there!

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

No, I don't think follows from what I've been suggesting.  There's  
nothing that says configuration of a feature can't result in the  
publication of policy.  For example, suppose you had a feature  
configuration for an endpoint as follows:

{{{
<jaxws:endpoint ...>
     <cxf:feature>
         <cxf:WsSecurityRequirements
             <cxf:Timestamp/>
             <cxf:Integrity
                <cxf:TrustStore  
trustStoreRetrievalMechanism="#trustStoreRetreivalBean"/>
                <cxf:parts>
                   <cxf:bodyPart>
                   <cxf:timestampPart/>
                <cxf:parts>
             </cxf:Integrity>
             <cxf:Confidentiality>
                 <cxf:decryptionKey
                     keyRetrievalMechanism="#keyRetrievalBean"/>
                <cxf:parts>
                   <cxf:bodyPart>
                   <cxf:signaturePart/>
                <cxf:parts>
             </cxf:Confidentiality>
         </cxf:WsSecurityRequirements>
     </cxf:feature>
</jaxws:endpoint>
}}}

Such a configuration could result in the WSDL artifact (accessible  
via "http://...?wsdl")

{{{
<wsdl:definitions ...
   <wsp:Policy wsu:Id="generatedPolicyArtifactId">
     <wsp:ExactlyOne>
       <wsp:All>
         <sp:AsymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ 
ws/2005/07/securitypolicy">
           <wsp:Policy>
             <sp:InitiatorToken>
               <wsp:Policy>
                 <sp:X509Token sp:IncludeToken="http:// 
schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/ 
AlwaysToRecipient">
                   <wsp:Policy>
                     <sp:WssX509V3Token10/>
                   </wsp:Policy>
                 </sp:X509Token>
               </wsp:Policy>
             </sp:InitiatorToken>
             <sp:RecipientToken>
               <wsp:Policy>
                 <sp:X509Token sp:IncludeToken="http:// 
schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
                   <wsp:Policy>
                     <sp:WssX509V3Token10/>
                   </wsp:Policy>
                 </sp:X509Token>
               </wsp:Policy>
             </sp:RecipientToken>
             <sp:AlgorithmSuite>
               <wsp:Policy>
                 <sp:Basic256/>
               </wsp:Policy>
             </sp:AlgorithmSuite>
             <sp:Layout>
               <wsp:Policy>
                 <sp:Lax/>
               </wsp:Policy>
             </sp:Layout>
             <sp:IncludeTimestamp/>
             <sp:EncryptSignature/>
             <sp:OnlySignEntireHeadersAndBody/>
           </wsp:Policy>
         </sp:AsymmetricBinding>
         <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/ 
securitypolicy">
           <wsp:Policy>
             <sp:MustSupportRefKeyIdentifier/>
             <sp:MustSupportRefIssuerSerial/>
           </wsp:Policy>
         </sp:Wss10>
       </wsp:All>
     </wsp:ExactlyOne>
   </wsp:Policy>
   <wsp:Policy wsu:Id="Input_policy">
     <wsp:ExactlyOne>
       <wsp:All>
         <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/ 
2005/07/securitypolicy">
           <sp:Body/>
           <sp:Header Name="TimeStamp" Namespace="http://docs.oasis- 
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"/>
         </sp:SignedParts>
         <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/ 
2005/07/securitypolicy">
           <sp:Body/>
           <sp:Header Name="Signature" Namespace="http://docs.oasis- 
open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"/>
         </sp:EncryptedParts>
       </wsp:All>
     </wsp:ExactlyOne>
   </wsp:Policy>
   <wsp:Policy wsu:Id="output_policy">
     <wsp:ExactlyOne>
       <wsp:All>
         <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/ 
2005/07/securitypolicy">
           <sp:Body/>
         </sp:SignedParts>
         <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/ 
2005/07/securitypolicy">
           <sp:Body/>
         </sp:EncryptedParts>
       </wsp:All>
     </wsp:ExactlyOne>
   </wsp:Policy>
   ...
}}}

The point being that you can just as easily define the security  
requirements in a feature and generate the policy artifacts, with the  
advantage that you can specify key material in the feature without  
putting it in a Policy file (which runs the risk of leakage, etc).

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

Again, I'm not arguing that policies not be operative in the  
runtime.  That would be to say that policy has not role to play in  
CXF, which is NOT what I'm saying here.  All I'm suggesting is that  
WS-*Policy does not need to be the only or even recommended  
configuration mechanism for the majority of use-cases.

-Fred

Mime
View raw message