Hi Fred
Sorry for the delay.
>> 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" :)
Supporting WS-SecurityPolicy means being able to consume explicit policy
expressions which give the runtime information about what security capabilities
it needs to support/enforce.
Supporting CXF WS-Feature means being able to consume CXF feature expressions
which give the runtime information about what security capabilities it needs to
support/enforce.
I've specifically made nearly duplicate statements.
Supporting WS-SecurityPolicy or CXF WS-Feature is about providing the details
to the runtime. In this respect WS-SecurityPolicy can do what CXF WS-Feature
can do and vice-versa. This is where the similarity ends because one can do
with WS-SecurityPolicy many more things one can't with features.
>> 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 belive this is not relevant to the issue of what does it mean to support
WS-SecurityPolicy.
I also respectfully disagree that manually creating advanced features is
simplier than creating verbose but
boilerplate policy expressions.
> 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.
Please see above, WS-Security Feature is not a "poor man's" tool. It's a way to
tell to the runtime
what it needs to do with respect to the security. It's nothing to do though
with support for WS-SecurityPolicy.
Generating polices from features does not seem to be like a promising idea to
be fare, for a number of things.
One of them is that WS-Policy is more than just configuration and you can't
reflect things like multiple alternatives in features. There's a bunch of other
problems I can see in this conversion.
WS-SecurityPolicy and WS-Security Feature can either complement each other
(features specifying the private stuff) or used as two alternatives mechanisms
to achieve the same common goal, , providing the configuration details to the
runtime (but as I said using WS-SecurityPolicy can help in achieveng even more
goals).
> 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.
<snip/>
Once again, WS-Policy does provide configuration, but it also provides for much
more.
I understand from what yourself and Dan explained to me that features are
useful, can be less verbose and can be handy to use. Using featutes has nothing
to do with the support for WS-SecurityPolicy though.
> 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.
Sorry for even raising this point :-) It's all that my defensive mood which is
to blame :-)
> 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.
+1.
>>
>> 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).
The verbosity of policy expressions is obvious here :-)
As I said, I personally don't believe it can work. It does seem like a hack,
sorry. Translating from features to policies will be tricky enough, should we
ship stylesheets ? And what assurance do you have such a conversion process
won't leak the private stuff to the client ? And you can't do alternatives for
clients to choose from, and attach
capabilities in a more fine-grained fashion. And you can't do the intersection
if you're on the client side.
And we'll have to tell users to translate policy expressions which work for
them elsewhere into our own private CXF feature stuff : how will they do it ?
What is the point ?
As I said, INHO it would be much better to learn how to utilize both features
and policies to work together and to push all the needed data to the runtime.
> 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.
I agree that WS-*Policy does not need to be the only way.
As far as the WS-SecurityPolicy support is concerned I strongly believe that
using WS-Policy expressions should be a preferred mechanism to push
publicly-visible requirements into the runtime.
Futhermore, as far as the configuration of publicly visible settings which can
be of interest to the client is concerned, using WS-Policy should be a
preferred mechanism generally. That could be a non-normative guideline helping
people to choose. This is just my opinion.
Thanks, Sergey
>
> -Fred
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
