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.
