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
