You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <se...@iona.com> on 2007/09/23 14:24:35 UTC
RE: WS-SX
Hi
A couple of comments on WS-SecurityPolicy:
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.
This is something I'd be willing to contribute to.
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.
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.
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.
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. Another
approach is to put the private stuff outside the policy expression but then
merge the information from multiple sources. 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.
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. Supporting both WS-SecurityPolicy and
WS-Security feature will add to the confusion people already when choosing
how to configure a given capability. Additionally, using policies one can
annotate the contract at a very fine-grained fashion, which is not possible
when using features.
I still think something like WS-Security feature has its place. It can be
used by users which just don't want to use WS-SecurityPolicy for whatever
reasons and who are happy with being able to annotate a limited part of the
contract. More realistically though one can probably use WS-Security feature
to keep the private stuff like passwords but have everything else kept in
the corresponding policy expression.
Cheers, Sergey
_____
From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
Sent: 22 September 2007 21:38
To: cxf-dev@incubator.apache.org
Subject: WS-SX
One of the things on my wishlist for 2.1 is support for WS-SX -
WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its a very important
feature for a lot of corporations because it enables much faster security
and it also enables a range of security scenarios which weren't possible
before.
I know I've chatted with Fred a bit about this before, but I'd like to bring
the discussion to the dev list for a while so we can a) figure out the scope
of the work b) decide if we can do it for 2.1 and c) figure out who's going
to do what. Regarding this last point, I will be very happy to particpate,
but I'm not sure I can do the majority of the work. But I can certainly code
some and help brainstorm.
At a high level I suppose there are several things we need to do:
1. Build a WS-Trust service for token exchange. At the very least we
need to be able to create symmetric keys from the asymmetric public keys for
WS-SecureConversation.
2. WS-SecurityPolicy
1. First we need to start using JAXB catalog files. These files allow
JAXB to use classes which have already been generated when doing xsd2java.
In other words, our ws-security module can generate the security policy
beans and reference the beans in the policy module. Whereas right now, the
policy beans would be regenerated by JAXB. This requires an upgrade to JAXB
2.1 and also it requires use of the official/Mojo JAXB plugin instead of our
own. Our own plugin is architected in such a way that adding this feature
isn't really possible without a rewrite, which seems like a waste of time.
2. Which, if not all, policy assertions do we need to support?
3. WS-SecureConversation service and interceptors
4. WS-Security feature for configuration (I heard through the grapevine
someone may have started on this. Would be interested to see what has been
done - I really like the way Spring-WS does WS-Security configuration so it
may be interesting to look into that)
So with that - anyone else looked into this in more detail? Anyone want to
help pick up this feature for 2.1?
Cheers,
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: WS-SX
Posted by Sergey Beryozkin <se...@iona.com>.
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
Re: WS-SX
Posted by Fred Dushin <fr...@dushin.net>.
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
Re: WS-SX
Posted by Sergey Beryozkin <se...@iona.com>.
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" <fr...@dushin.net>
To: <cx...@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
RE: WS-SX
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 25 September 2007 17:58
> To: cxf-dev@incubator.apache.org
> Subject: Re: WS-SX
>
[snip]
> > I would like to be able to configure CXF specific
> configuration items
> > (like key info) via a feature. Policies can then be attached.
>
[snip]
> I just don't quite
> understand what you mean by "Policies can then be attached".
Dunno if this is what Dan was referring to, but bear in mind that
WS-Policy assertions can directly attached to certain features. The two
cases I have in mind are the <reliableMessaging> feature embedding the
<RMAssertion> and the <policies> feature embedding *any* policy
assertion.
This certainly adds flexibility, but at the cost of some potential
confusion. At least I've found when explaining the choice between
enabling WS-RM via policy or feature, that the glazed-eye look is most
likely to occur when the two approaches are conflated via an RMAssertion
attached to a reliableMessaging feature.
Cheers,
Eoghan
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: WS-SX
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Dan
If you don't mind I won't reply inline, I'm concerned that it'll be difficult to read it.
>> Another thing I'd like to avoid is to have some religious debate leading
>> nowhere.
>>
> I really don't believe this is hypothetical or religious at all.
I agree that the security considerations are important. It just seemed to me yesterday that the fact the information could be leaked was linked to the suggestion to use polices. Possibly I was in a defensive mood :-). In context of the WS-SecurityPolicy work, I suggested two possible approaches, use polices to keep both public and private stuff (to be stripped off at publication time) or use policies for the public stuff only and features for the private stuff. The concern was expressed that the info could be leaked in the former case, which is fair enough, but I do not think it affects the general idea of when to use polices as opposed to features, rather it's a lower-level concern.
Not sure why I used the "religious" term though, I just wanted to avoid a head-on "policies are just better than features and vice versa" debate.
> Imagine I'm writing a GUI for CXF which configures the security for my
> services. As a CXF integrator, I don't want to have to generate policies
> to be able to configure a service. Features are much nicer to use. "new
> Feature().setFoo(bar);"
I think I agree. I don't see though what it's to do with the issue being discussed, I didn't advocate to generate the policies.
But here's another thing. Imagine a design tool consuming a service WSDL (in fact it does not have to be a WSDL), but for the simplicity sake lets use WSDL. If this WSDL has policies attached then the design tool can easily recognize the policies associated with a given endpoint, operation, message, binding, ask a user for additional questions, or, may be even generate the code you shown in the example. Now, the policies do not have to be explicitly attached to the WSDL, a CXF external policy attachment mechanism Andrea did can be used to annotate the published WSDL, polices can live outside of WSDL with the latter being unaware of them.
> I would like to be able to configure CXF specific configuration items
> (like key info) via a feature. Policies can then be attached.
So are we in agreement or am I misunderstanding ? Do you agree that the private stuff goes into features and the public
stuff goes into policies, when dealing with WS-SecurityPolices for ex ? This is one of the approaches which people seem to agree upon. I just don't quite understand what you mean by "Policies can then be attached". Do you mean "information in features and policies will be merged" to provide a unified view of the configuration info to the WS-SX engine or something similar ? This approach will work, it will be just more complicated but it will work.
That said, I'd still like CXF to support "the private-info inside a policy" approach, it might make design tools happier. But as I said, it's not something which concerns me much at the moment.
>
> I see policies and configuration of the other bits as two seperate
> processes. For instance, you may have a policy which you apply to all
> your services. But the key information may differ on each one.
This makes total sense to me. So are we in agreement :-) ?
>> * how can one satisfy a user's desire to attach capabilities to endpoints,
>> operations, and bindings using features
>>
> Yeah, thats what Policy is for. Are you suggesting that users are going
> to have different key information for different operations? I can
> certainly see bindings/endpoints - and you can apply features at that level.
With WS-Policy one can apply seperate (WS-SecurityPolicy) policies to messages, portType itself,
portType/operations, binding itself, binding/operations, etc. They get then merged into effective policies for different policy subjects like endpoints. I didn't mean a seperate keyinfo per the operation, and as I said above, agreed, using features to specify, say, per-service key-info details, passwords, etc sounds good.
> Speaking of the client: are you suggesting the client has to take a
> policy from a service, add in a bunch of extra expressions for key info
> and the like, and then deploy? Thats a hell of a lot of work. Thats what
> features are for: to supply configuration which is orthogonal to Policy.
I just mean that both Policy and features will contribute to providing all the information a WS-SX engine will need.
I'm somewhat uncomfortable about the 'orthogonal' term but I think I see what you mean and I agree.
I see policies serving two goals : providing info to the consumers and, as a positive side effect, providing the configuration to the providers and as such they play together with other mechanisms like features.
> Who's looking at WS-Pol as a configuration option only here? I didn't
> think anyone was.
This is great. It's a good message.
> So to summarize: we should use features for information which is not
> useful for the client and for stuff which should not be public beyond the local service.
+1. Agreed...
>Because:
> 1. It makes API configuration of the service easier. No need to generate
> policy documents by hand.
Don't understand. I've seen your example but I don't see what it's to do with supportng WS-SecurityPolicy (which are policy expressions). Can you explain again ?
> 2. Security considerations - Policy files are not easily tracked and
> will leak IMO
I'd not go that far. What about config files, what about trust to the runtime itself ? Is it written in stone it's all safe and bullet-proof ? But I'm ok with accepting this message for now.
> 3. Configuration readability - WS-SecPol files are quite verbose/sticky.
> As Fred said: "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."
Hmm... I'm totaly lost again. I agree the verbosity is there. What does 'sticky' mean in this context ?
So what does it mean to you to support a WS-SecurityPolicy ?
> 4. Separation of concerns: Policy and configuration are two separate
> processes, often done at different stages. They also have different
> levels of reusability.
Hmm...You're probably now referring to those SOA architects applying their polices and seeing the configuration
being generated ? Yes ? What is it to do with supporting a WS-SecurityPolicy ? Having WS-SecurityPolicy polices attached to say a WSDL plays 3 roles : providing info to design tools, providing info to client runtimes for the intersection purposes, and configuring the provider's runtime. What do you mean by diffent stages ? If you're talking about SOA architects then in their world no WS-SecurityPolicy may exist, WS-SecurityPolicy is a lower-level concept, product/WS-* specifc, etc
>
> I'm not saying we couldn't also support policy expressions for
> configuration, but I think the use case for it is limited. Again, as
> Fred said: "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."
Totally lost. I start feeling that when saying "we want to support WS-SecurityPolicy"
you guys mean to look at a WS-SecurityPolicy spec, see what is possible to configure using those policy expressions
and then just translate it all into cxf features and that is it... Am I right ? If yes, then CXF won't support WS-SecurityPolicy ever, CXF will support WS-Security. Do you see the difference ? Or am I totally off-tack ?
>
> Of the above items, I will admit that 3/4 are potentially overcomeable
> but I would rank #1 & #2 as very important issues which kill the idea of
> configuring everything in Policy for me. We could also potentially use a
> feature to generate policy, but that would be a PITA IMO. It'd probably
> just be easier to interact with the WS-SX engine directly.
I don't understand it, sorry. Please clarify points 1, 3, and 4 again.
Thanks, Sergey
----- Original Message -----
From: "Dan Diephouse" <da...@mulesource.com>
To: <cx...@incubator.apache.org>
Sent: Tuesday, September 25, 2007 3:38 PM
Subject: Re: WS-SX
> Sergey Beryozkin wrote:
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
>> Sent: 24 September 2007 21:31
>> To: cxf-dev@incubator.apache.org
>> Subject: RE: WS-SX
>>
>> I think we're over-blowing the problem a bit. Lets not get sidetracked into
>> hypothetical discussions on how dangerous it is to put a private stuff into
>> policies. Rather lets come up with a set of practical guidelines on when to
>> use policies and features.
>> Another thing I'd like to avoid is to have some religious debate leading
>> nowhere.
>>
> I really don't believe this is hypothetical or religious at all.
>> Dan, you said you wanted to support WS-SecurityPolicy because it was so
>> important for the enterprise. Now you're also saying that using features is
>> so much better from an API perspective.
>>
>> I personally don't understand what is your position. I'm just confused. Can
>> you please clarify?
>>
> Imagine I'm writing a GUI for CXF which configures the security for my
> services. As a CXF integrator, I don't want to have to generate policies
> to be able to configure a service. Features are much nicer to use. "new
> Feature().setFoo(bar);"
>> Do you want support WS-SecurityPolicy by using WS-Security feature ? I don't
>> think it makes any sense but I'd you to explain please.
>>
> I would like to be able to configure CXF specific configuration items
> (like key info) via a feature. Policies can then be attached.
>
> I see policies and configuration of the other bits as two seperate
> processes. For instance, you may have a policy which you apply to all
> your services. But the key information may differ on each one.
>> Can you explain please what you mean by saying it's so much harder to set up
>> a service using a policy ?
>>
> See above.
>> I'd also like to suggest you to think of the following :
>>
>> * how can one satisfy a user's desire to attach capabilities to endpoints,
>> operations, and bindings using features
>>
> Yeah, thats what Policy is for. Are you suggesting that users are going
> to have different key information for different operations? I can
> certainly see bindings/endpoints - and you can apply features at that level.
>> * how can a client to avoid doing duplications like enabling MTOM on the
>> client side when using features
>>
> I don't understand this question - if the client encounters an MTOM
> policy expression, it can just enable it. No feature needed.
>> * how can a client perform intersection of capabilities using features
>>
> Eh? I'm not suggesting we rip out policy all together.
>
> Speaking of the client: are you suggesting the client has to take a
> policy from a service, add in a bunch of extra expressions for key info
> and the like, and then deploy? Thats a hell of a lot of work. Thats what
> features are for: to supply configuration which is orthogonal to Policy.
>> Or yes, one more thing.
>>
>> How can one express 'or' combination using features, that is how one can do
>> multiple alternatives, something one can easily do with policies :
>>
>> <Policy>
>> <All>
>> </All>
>> <All>
>> </All>
>> </Policy>
>>
>> Alternatives are targeted at a consumer. Multiple consumers can choose their
>> own alternatives and a provider will ensure it supports all the consumers.
>> Consumers may also have their policies on which case they'll do the
>> intersection.
>>
>> This clearly shows that WS-Policy is not about configuration only. Looking
>> at a WS-Policy language as the configuration option only is not correct.
>> I don't want push the message that using policies is the only true way to
>> go. I'd just like us to agree on a policy (:-)) when polices should be
>> applied.
>>
> Who's looking at WS-Pol as a configuration option only here? I didn't
> think anyone was.
>
> So to summarize: we should use features for information which is not
> useful for the client and for stuff which should not be public beyond
> the local service. Because:
> 1. It makes API configuration of the service easier. No need to generate
> policy documents by hand.
> 2. Security considerations - Policy files are not easily tracked and
> will leak IMO
> 3. Configuration readability - WS-SecPol files are quite verbose/sticky.
> As Fred said: "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."
> 4. Separation of concerns: Policy and configuration are two separate
> processes, often done at different stages. They also have different
> levels of reusability.
>
> I'm not saying we couldn't also support policy expressions for
> configuration, but I think the use case for it is limited. Again, as
> Fred said: "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."
>
> Of the above items, I will admit that 3/4 are potentially overcomeable
> but I would rank #1 & #2 as very important issues which kill the idea of
> configuring everything in Policy for me. We could also potentially use a
> feature to generate policy, but that would be a PITA IMO. It'd probably
> just be easier to interact with the WS-SX engine directly.
>
> - Dan
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: WS-SX
Posted by Dan Diephouse <da...@mulesource.com>.
Sergey Beryozkin wrote:
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 24 September 2007 21:31
> To: cxf-dev@incubator.apache.org
> Subject: RE: WS-SX
>
> I think we're over-blowing the problem a bit. Lets not get sidetracked into
> hypothetical discussions on how dangerous it is to put a private stuff into
> policies. Rather lets come up with a set of practical guidelines on when to
> use policies and features.
> Another thing I'd like to avoid is to have some religious debate leading
> nowhere.
>
I really don't believe this is hypothetical or religious at all.
> Dan, you said you wanted to support WS-SecurityPolicy because it was so
> important for the enterprise. Now you're also saying that using features is
> so much better from an API perspective.
>
> I personally don't understand what is your position. I'm just confused. Can
> you please clarify?
>
Imagine I'm writing a GUI for CXF which configures the security for my
services. As a CXF integrator, I don't want to have to generate policies
to be able to configure a service. Features are much nicer to use. "new
Feature().setFoo(bar);"
> Do you want support WS-SecurityPolicy by using WS-Security feature ? I don't
> think it makes any sense but I'd you to explain please.
>
I would like to be able to configure CXF specific configuration items
(like key info) via a feature. Policies can then be attached.
I see policies and configuration of the other bits as two seperate
processes. For instance, you may have a policy which you apply to all
your services. But the key information may differ on each one.
> Can you explain please what you mean by saying it's so much harder to set up
> a service using a policy ?
>
See above.
> I'd also like to suggest you to think of the following :
>
> * how can one satisfy a user's desire to attach capabilities to endpoints,
> operations, and bindings using features
>
Yeah, thats what Policy is for. Are you suggesting that users are going
to have different key information for different operations? I can
certainly see bindings/endpoints - and you can apply features at that level.
> * how can a client to avoid doing duplications like enabling MTOM on the
> client side when using features
>
I don't understand this question - if the client encounters an MTOM
policy expression, it can just enable it. No feature needed.
> * how can a client perform intersection of capabilities using features
>
Eh? I'm not suggesting we rip out policy all together.
Speaking of the client: are you suggesting the client has to take a
policy from a service, add in a bunch of extra expressions for key info
and the like, and then deploy? Thats a hell of a lot of work. Thats what
features are for: to supply configuration which is orthogonal to Policy.
> Or yes, one more thing.
>
> How can one express 'or' combination using features, that is how one can do
> multiple alternatives, something one can easily do with policies :
>
> <Policy>
> <All>
> </All>
> <All>
> </All>
> </Policy>
>
> Alternatives are targeted at a consumer. Multiple consumers can choose their
> own alternatives and a provider will ensure it supports all the consumers.
> Consumers may also have their policies on which case they'll do the
> intersection.
>
> This clearly shows that WS-Policy is not about configuration only. Looking
> at a WS-Policy language as the configuration option only is not correct.
> I don't want push the message that using policies is the only true way to
> go. I'd just like us to agree on a policy (:-)) when polices should be
> applied.
>
Who's looking at WS-Pol as a configuration option only here? I didn't
think anyone was.
So to summarize: we should use features for information which is not
useful for the client and for stuff which should not be public beyond
the local service. Because:
1. It makes API configuration of the service easier. No need to generate
policy documents by hand.
2. Security considerations - Policy files are not easily tracked and
will leak IMO
3. Configuration readability - WS-SecPol files are quite verbose/sticky.
As Fred said: "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."
4. Separation of concerns: Policy and configuration are two separate
processes, often done at different stages. They also have different
levels of reusability.
I'm not saying we couldn't also support policy expressions for
configuration, but I think the use case for it is limited. Again, as
Fred said: "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."
Of the above items, I will admit that 3/4 are potentially overcomeable
but I would rank #1 & #2 as very important issues which kill the idea of
configuring everything in Policy for me. We could also potentially use a
feature to generate policy, but that would be a PITA IMO. It'd probably
just be easier to interact with the WS-SX engine directly.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
RE: WS-SX
Posted by Sergey Beryozkin <se...@iona.com>.
Or yes, one more thing.
How can one express 'or' combination using features, that is how one can do
multiple alternatives, something one can easily do with policies :
<Policy>
<All>
</All>
<All>
</All>
</Policy>
Alternatives are targeted at a consumer. Multiple consumers can choose their
own alternatives and a provider will ensure it supports all the consumers.
Consumers may also have their policies on which case they'll do the
intersection.
This clearly shows that WS-Policy is not about configuration only. Looking
at a WS-Policy language as the configuration option only is not correct.
I don't want push the message that using policies is the only true way to
go. I'd just like us to agree on a policy (:-)) when polices should be
applied.
Cheers, Sergey
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
Sent: 24 September 2007 21:31
To: cxf-dev@incubator.apache.org
Subject: RE: WS-SX
I think we're over-blowing the problem a bit. Lets not get sidetracked into
hypothetical discussions on how dangerous it is to put a private stuff into
policies. Rather lets come up with a set of practical guidelines on when to
use policies and features.
Another thing I'd like to avoid is to have some religious debate leading
nowhere.
Dan, you said you wanted to support WS-SecurityPolicy because it was so
important for the enterprise. Now you're also saying that using features is
so much better from an API perspective.
I personally don't understand what is your position. I'm just confused. Can
you please clarify?
Do you want support WS-SecurityPolicy by using WS-Security feature ? I don't
think it makes any sense but I'd you to explain please.
Can you explain please what you mean by saying it's so much harder to set up
a service using a policy ?
I'd also like to suggest you to think of the following :
* how can one satisfy a user's desire to attach capabilities to endpoints,
operations, and bindings using features
* how can a client to avoid doing duplications like enabling MTOM on the
client side when using features
* how can a client perform intersection of capabilities using features
Thanks, Sergey
-----Original Message-----
From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
Sent: 24 September 2007 19:26
To: cxf-dev@incubator.apache.org
Subject: Re: WS-SX
Fred Dushin wrote:
> 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 agree that its quite dangerous to put the security info in the policy.
People will start emailing policies around or putting them in their
repository without the proper security constraints. If there was
significant simplification from a user's POV in doing this, I would
probably support it. But as it stands, people are most likely going to
have a separate policy file and configuration file anyway.
> *) 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.
I completely agree here with Fred, and I thank him for taking the time
to write this email which expresses my views better than I could have :-).
I especially would like people to consider the use case of using CXF
from the API. Its much harder to set up a service to use WS-SX by
building a policy document than it is to use a Feature.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: WS-SX
Posted by Sergey Beryozkin <se...@iona.com>.
I think we're over-blowing the problem a bit. Lets not get sidetracked into
hypothetical discussions on how dangerous it is to put a private stuff into
policies. Rather lets come up with a set of practical guidelines on when to
use policies and features.
Another thing I'd like to avoid is to have some religious debate leading
nowhere.
Dan, you said you wanted to support WS-SecurityPolicy because it was so
important for the enterprise. Now you're also saying that using features is
so much better from an API perspective.
I personally don't understand what is your position. I'm just confused. Can
you please clarify?
Do you want support WS-SecurityPolicy by using WS-Security feature ? I don't
think it makes any sense but I'd you to explain please.
Can you explain please what you mean by saying it's so much harder to set up
a service using a policy ?
I'd also like to suggest you to think of the following :
* how can one satisfy a user's desire to attach capabilities to endpoints,
operations, and bindings using features
* how can a client to avoid doing duplications like enabling MTOM on the
client side when using features
* how can a client perform intersection of capabilities using features
Thanks, Sergey
-----Original Message-----
From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
Sent: 24 September 2007 19:26
To: cxf-dev@incubator.apache.org
Subject: Re: WS-SX
Fred Dushin wrote:
> 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 agree that its quite dangerous to put the security info in the policy.
People will start emailing policies around or putting them in their
repository without the proper security constraints. If there was
significant simplification from a user's POV in doing this, I would
probably support it. But as it stands, people are most likely going to
have a separate policy file and configuration file anyway.
> *) 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.
I completely agree here with Fred, and I thank him for taking the time
to write this email which expresses my views better than I could have :-).
I especially would like people to consider the use case of using CXF
from the API. Its much harder to set up a service to use WS-SX by
building a policy document than it is to use a Feature.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: WS-SX
Posted by Dan Diephouse <da...@mulesource.com>.
Fred Dushin wrote:
> 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 agree that its quite dangerous to put the security info in the policy.
People will start emailing policies around or putting them in their
repository without the proper security constraints. If there was
significant simplification from a user's POV in doing this, I would
probably support it. But as it stands, people are most likely going to
have a separate policy file and configuration file anyway.
> *) 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.
I completely agree here with Fred, and I thank him for taking the time
to write this email which expresses my views better than I could have :-).
I especially would like people to consider the use case of using CXF
from the API. Its much harder to set up a service to use WS-SX by
building a policy document than it is to use a Feature.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: WS-SX
Posted by Sergey Beryozkin <se...@iona.com>.
>So the preferred mechanism for configuration would always be a feature,
> but that for more low-level stuff policies can be used?
It should be the other way around. Using policies for low-level stuff makes policies of no use to anyone, but makes them just yeat
anothjer configuration mechanism no one will ever use
Cheers, Sergey
----- Original Message -----
From: "Johnson, Eric" <Er...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Monday, September 24, 2007 4:34 PM
Subject: RE: WS-SX
<snip>
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.
</snip>
For point number 2 are you saying that users would generally use CXF
feature mechanism for configuration of endpoints and that the runtime
would generate the policies that a service provider would need to
advertise? In that case a client/consumer could consume the advertised
policies and reconfigure themselves based on the policies?
So the preferred mechanism for configuration would always be a feature,
but that for more low-level stuff policies can be used?
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: WS-SX
Posted by "Johnson, Eric" <Er...@iona.com>.
<snip>
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.
</snip>
For point number 2 are you saying that users would generally use CXF
feature mechanism for configuration of endpoints and that the runtime
would generate the policies that a service provider would need to
advertise? In that case a client/consumer could consume the advertised
policies and reconfigure themselves based on the policies?
So the preferred mechanism for configuration would always be a feature,
but that for more low-level stuff policies can be used?
Re: WS-SX
Posted by Fred Dushin <fr...@dushin.net>.
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.
Re: Policies and features (Was : WS-SX)
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Eric
yes, this is exactly how I see it myself. IMHO it makes sense.
As I said earlier this is just a guideline which I'd like us to come up with. At least users will see that we ourselves know when to use which approach, which will be better than just us saying you can configure the same thing using 3 different appproaches, choose yourself whichever approach you like.
More comments in other emails in this thread...
Thanks, Sergey
----- Original Message -----
From: "Johnson, Eric" <Er...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Monday, September 24, 2007 3:22 PM
Subject: RE: Policies and features (Was : WS-SX)
Pardon the real simplistic black/whiteness of this comment, but it is
directed toward figuring out the message to a user trying to sort out
which of the myriad configuration mechanisms to use....
So what you are saying, in general, is:
* Use policies when you want a service provider to advertise
requirements for interaction to a consumer. For example, I use RM and
require strong encryption.
* Use features to configure stuff that is local to a running process.
For example, use this persistent data store and this security key store.
For things like credentials and other private information the mechanism
gets more complicated, but for the user who is trying to figure out how
to set up a CXF based application the above rules are good.
Or am I missing something?
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
Sent: Monday, September 24, 2007 9:34 AM
To: cxf-dev@incubator.apache.org
Subject: Policies and features (Was : WS-SX)
Hi Eoghan
I've created a new topic so that I don't interfere with the original
WS-SX topic...
I'd like to step back for a second before answering to your specific
question.
Lets say we have an ability to express the same capability/requirement
using several alternative mechanisms, for ex, using a WS-Policy policy
expression and a CXF feature. We can probably agree that providing
several options is confusing to users and to those writing the
documentation. At the same time I don't think we can enforce the usage
of a single alternative. Hence we should have a good idea of when to the
WS-Policy expressions, when to use CXF features, when to use both, and
provide guidelines.
IMHO a general guideline is : if it's of public interest (interest to
consumers) then it's a policy. Otherwise it's a feature. If
policy-unaware consumers are targeted then both alternatives might be
used, as such consumers still have to configure themselves. If it's a
consumer which is being configured then both alternatives are usable too
but the policy is better because more advanced WS-policy features can be
used when both a consumer and a provider are configured with ws-policy.
I think it was too strong to suggect a WS-Security feature would be
redundant/obsolete if WS-SecurityPolicy were supported. I just don't see
why would people use a CXF feature if a corresponding WS-SecurityPolicy
expression were available. Only if we could have this feature usable in
scenarios when no WS-Security was involved (say when people work with
restful services and do XMLEncryption, etc) then I can see why would
people choose to use a feature.
When users are unhappy when seeing WS- appendix then let them use
features and not worry about policies (though it's worth saying a
WS-Policy language is not bound to WS-* services and the frameworks
defines the mechanism to attach policies to arbitrary XML elements).
If we were to use WS-SecurityPolicy then we'd need to decide where the
private stuff would go. As I said earlier two options are possible.
One is to embedd the private stuff inside the policy itself and strip it
out at the publication time, works with wsdl/java first developement,
see for example :
1. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
"As is the case when you develop your service from WSDL, private policy
assertions are removed before the final WSDL is published. "
2. Similar pattern is used in Apache Rampart :
http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
Alternative approach is to put the public stuff into a policy and a
private stuff into a feature and merge the info. Possibly using the
advanced CXF feature mechanism where a policy assertion can be embedded
into a feature, as in case with RM assertions.
So finally I'm getting to your question :
>>Would the same logic apply to the reliableMessaging feature versus the
>>RMAssertion?
I believe we should advise users to use a reliableMessaging feature only
when it can add a private stuff (which is of no interest to consumers of
such polices) in addition to what a public WS-RM policy can already
express.
Alternatively we can advise people to put a private stuff inside a
policy itself but we'd have to strip it off at the publication time. In
case of RM we may not even have to do it as the private stuff won't be
as sensitive as the private security stuff and well-behaved RM consumers
should ignore unrecognized RM extensions.
I think both options can be supported, but with guidelines people would
be less confused with a number of configuration options we have.
Would you agree with what I said ?
Thanks, Sergey
Hi Sergey,
A quick question on your observation that the WS-Security feature would
be redundant/obsolete if WS-SecurityPolicy were supported.
Would the same logic apply to the reliableMessaging feature versus the
RMAssertion?
Obviously there are some differences in the RM case, in the sense that
(a) an RMAssertion can be embedded in the reliableMessaging feature, and
(b) otherwise the primary purpose of the reliableMessaging feature is to
specify "non-private" behavior outside the scope of the RMAssertion
(e.g. the sequenceTerminationPolicy).
But I'm wondering if your line of reasoning would extend to embedding
e.g. the sequenceTerminationPolicy as a custom extension of the
RMAssertion?
Cheers,
Eoghan
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 23 September 2007 13:25
> To: cxf-dev@incubator.apache.org
> Subject: RE: WS-SX
>
> Hi
>
>
>
> A couple of comments on WS-SecurityPolicy:
>
>
>
> 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.
>
> This is something I'd be willing to contribute to.
>
> 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.
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
> Another approach is to put the private stuff outside the policy
> expression but then merge the information from multiple sources.
> 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.
>
>
>
> 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.
> Supporting both WS-SecurityPolicy and WS-Security feature will add to
> the confusion people already when choosing how to configure a given
> capability. Additionally, using policies one can annotate the contract
> at a very fine-grained fashion, which is not possible when using
> features.
>
>
>
> I still think something like WS-Security feature has its
> place. It can be used by users which just don't want to use
> WS-SecurityPolicy for whatever reasons and who are happy with
> being able to annotate a limited part of the contract. More
> realistically though one can probably use WS-Security feature
> to keep the private stuff like passwords but have everything
> else kept in the corresponding policy expression.
>
>
>
> Cheers, Sergey
>
>
>
>
>
>
>
>
>
> _____
>
> From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> Sent: 22 September 2007 21:38
> To: cxf-dev@incubator.apache.org
> Subject: WS-SX
>
>
>
> One of the things on my wishlist for 2.1 is support for WS-SX
> - WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its
> a very important feature for a lot of corporations because it
> enables much faster security and it also enables a range of
> security scenarios which weren't possible before.
>
> I know I've chatted with Fred a bit about this before, but
> I'd like to bring the discussion to the dev list for a while
> so we can a) figure out the scope of the work b) decide if we
> can do it for 2.1 and c) figure out who's going to do what.
> Regarding this last point, I will be very happy to
> particpate, but I'm not sure I can do the majority of the
> work. But I can certainly code some and help brainstorm.
>
> At a high level I suppose there are several things we need to do:
>
> 1. Build a WS-Trust service for token exchange. At the
> very least we
> need to be able to create symmetric keys from the asymmetric
> public keys for WS-SecureConversation.
> 2. WS-SecurityPolicy
>
> 1. First we need to start using JAXB catalog files. These
> files allow
> JAXB to use classes which have already been generated when
> doing xsd2java.
> In other words, our ws-security module can generate the
> security policy beans and reference the beans in the policy
> module. Whereas right now, the policy beans would be
> regenerated by JAXB. This requires an upgrade to JAXB
> 2.1 and also it requires use of the official/Mojo JAXB plugin
> instead of our own. Our own plugin is architected in such a
> way that adding this feature isn't really possible without a
> rewrite, which seems like a waste of time.
> 2. Which, if not all, policy assertions do we need to support?
>
> 3. WS-SecureConversation service and interceptors
> 4. WS-Security feature for configuration (I heard through
> the grapevine
> someone may have started on this. Would be interested to see
> what has been done - I really like the way Spring-WS does
> WS-Security configuration so it may be interesting to look into that)
>
> So with that - anyone else looked into this in more detail?
> Anyone want to help pick up this feature for 2.1?
>
> Cheers,
> - Dan
>
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland) Registered
> Number: 171387 Registered Address: The IONA Building,
> Shelbourne Road, Dublin 4, Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Policies and features (Was : WS-SX)
Posted by "Johnson, Eric" <Er...@iona.com>.
Pardon the real simplistic black/whiteness of this comment, but it is
directed toward figuring out the message to a user trying to sort out
which of the myriad configuration mechanisms to use....
So what you are saying, in general, is:
* Use policies when you want a service provider to advertise
requirements for interaction to a consumer. For example, I use RM and
require strong encryption.
* Use features to configure stuff that is local to a running process.
For example, use this persistent data store and this security key store.
For things like credentials and other private information the mechanism
gets more complicated, but for the user who is trying to figure out how
to set up a CXF based application the above rules are good.
Or am I missing something?
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
Sent: Monday, September 24, 2007 9:34 AM
To: cxf-dev@incubator.apache.org
Subject: Policies and features (Was : WS-SX)
Hi Eoghan
I've created a new topic so that I don't interfere with the original
WS-SX topic...
I'd like to step back for a second before answering to your specific
question.
Lets say we have an ability to express the same capability/requirement
using several alternative mechanisms, for ex, using a WS-Policy policy
expression and a CXF feature. We can probably agree that providing
several options is confusing to users and to those writing the
documentation. At the same time I don't think we can enforce the usage
of a single alternative. Hence we should have a good idea of when to the
WS-Policy expressions, when to use CXF features, when to use both, and
provide guidelines.
IMHO a general guideline is : if it's of public interest (interest to
consumers) then it's a policy. Otherwise it's a feature. If
policy-unaware consumers are targeted then both alternatives might be
used, as such consumers still have to configure themselves. If it's a
consumer which is being configured then both alternatives are usable too
but the policy is better because more advanced WS-policy features can be
used when both a consumer and a provider are configured with ws-policy.
I think it was too strong to suggect a WS-Security feature would be
redundant/obsolete if WS-SecurityPolicy were supported. I just don't see
why would people use a CXF feature if a corresponding WS-SecurityPolicy
expression were available. Only if we could have this feature usable in
scenarios when no WS-Security was involved (say when people work with
restful services and do XMLEncryption, etc) then I can see why would
people choose to use a feature.
When users are unhappy when seeing WS- appendix then let them use
features and not worry about policies (though it's worth saying a
WS-Policy language is not bound to WS-* services and the frameworks
defines the mechanism to attach policies to arbitrary XML elements).
If we were to use WS-SecurityPolicy then we'd need to decide where the
private stuff would go. As I said earlier two options are possible.
One is to embedd the private stuff inside the policy itself and strip it
out at the publication time, works with wsdl/java first developement,
see for example :
1. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
"As is the case when you develop your service from WSDL, private policy
assertions are removed before the final WSDL is published. "
2. Similar pattern is used in Apache Rampart :
http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
Alternative approach is to put the public stuff into a policy and a
private stuff into a feature and merge the info. Possibly using the
advanced CXF feature mechanism where a policy assertion can be embedded
into a feature, as in case with RM assertions.
So finally I'm getting to your question :
>>Would the same logic apply to the reliableMessaging feature versus the
>>RMAssertion?
I believe we should advise users to use a reliableMessaging feature only
when it can add a private stuff (which is of no interest to consumers of
such polices) in addition to what a public WS-RM policy can already
express.
Alternatively we can advise people to put a private stuff inside a
policy itself but we'd have to strip it off at the publication time. In
case of RM we may not even have to do it as the private stuff won't be
as sensitive as the private security stuff and well-behaved RM consumers
should ignore unrecognized RM extensions.
I think both options can be supported, but with guidelines people would
be less confused with a number of configuration options we have.
Would you agree with what I said ?
Thanks, Sergey
Hi Sergey,
A quick question on your observation that the WS-Security feature would
be redundant/obsolete if WS-SecurityPolicy were supported.
Would the same logic apply to the reliableMessaging feature versus the
RMAssertion?
Obviously there are some differences in the RM case, in the sense that
(a) an RMAssertion can be embedded in the reliableMessaging feature, and
(b) otherwise the primary purpose of the reliableMessaging feature is to
specify "non-private" behavior outside the scope of the RMAssertion
(e.g. the sequenceTerminationPolicy).
But I'm wondering if your line of reasoning would extend to embedding
e.g. the sequenceTerminationPolicy as a custom extension of the
RMAssertion?
Cheers,
Eoghan
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 23 September 2007 13:25
> To: cxf-dev@incubator.apache.org
> Subject: RE: WS-SX
>
> Hi
>
>
>
> A couple of comments on WS-SecurityPolicy:
>
>
>
> 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.
>
> This is something I'd be willing to contribute to.
>
> 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.
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
> Another approach is to put the private stuff outside the policy
> expression but then merge the information from multiple sources.
> 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.
>
>
>
> 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.
> Supporting both WS-SecurityPolicy and WS-Security feature will add to
> the confusion people already when choosing how to configure a given
> capability. Additionally, using policies one can annotate the contract
> at a very fine-grained fashion, which is not possible when using
> features.
>
>
>
> I still think something like WS-Security feature has its
> place. It can be used by users which just don't want to use
> WS-SecurityPolicy for whatever reasons and who are happy with
> being able to annotate a limited part of the contract. More
> realistically though one can probably use WS-Security feature
> to keep the private stuff like passwords but have everything
> else kept in the corresponding policy expression.
>
>
>
> Cheers, Sergey
>
>
>
>
>
>
>
>
>
> _____
>
> From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> Sent: 22 September 2007 21:38
> To: cxf-dev@incubator.apache.org
> Subject: WS-SX
>
>
>
> One of the things on my wishlist for 2.1 is support for WS-SX
> - WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its
> a very important feature for a lot of corporations because it
> enables much faster security and it also enables a range of
> security scenarios which weren't possible before.
>
> I know I've chatted with Fred a bit about this before, but
> I'd like to bring the discussion to the dev list for a while
> so we can a) figure out the scope of the work b) decide if we
> can do it for 2.1 and c) figure out who's going to do what.
> Regarding this last point, I will be very happy to
> particpate, but I'm not sure I can do the majority of the
> work. But I can certainly code some and help brainstorm.
>
> At a high level I suppose there are several things we need to do:
>
> 1. Build a WS-Trust service for token exchange. At the
> very least we
> need to be able to create symmetric keys from the asymmetric
> public keys for WS-SecureConversation.
> 2. WS-SecurityPolicy
>
> 1. First we need to start using JAXB catalog files. These
> files allow
> JAXB to use classes which have already been generated when
> doing xsd2java.
> In other words, our ws-security module can generate the
> security policy beans and reference the beans in the policy
> module. Whereas right now, the policy beans would be
> regenerated by JAXB. This requires an upgrade to JAXB
> 2.1 and also it requires use of the official/Mojo JAXB plugin
> instead of our own. Our own plugin is architected in such a
> way that adding this feature isn't really possible without a
> rewrite, which seems like a waste of time.
> 2. Which, if not all, policy assertions do we need to support?
>
> 3. WS-SecureConversation service and interceptors
> 4. WS-Security feature for configuration (I heard through
> the grapevine
> someone may have started on this. Would be interested to see
> what has been done - I really like the way Spring-WS does
> WS-Security configuration so it may be interesting to look into that)
>
> So with that - anyone else looked into this in more detail?
> Anyone want to help pick up this feature for 2.1?
>
> Cheers,
> - Dan
>
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland) Registered
> Number: 171387 Registered Address: The IONA Building,
> Shelbourne Road, Dublin 4, Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
Re: Policies and features (Was : WS-SX)
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Eoghan
I agree with your analysis.
"public stuff in the policy, private stuff in the feature, merge at runtime" seems a better approach in general as it
advocates the right seperation of concerns and avoids some edge cases (some private extensions which could be understood by consumers using the same policy aware runtime and such can be kept inside) one would have to deal with otherwise. It'll likely be more performant.
I believe Metro deals with edge cases by marking truly private stuff by an attribute like 'private=true'.
That said I feel we should let people to embedd the private stuff into policies too, possibly with the exception for security policies (to make security people happy :-))...This might help design tools to process such policies. I agree it can be a performance issue but at the same time it's a once-only hit.
When referring to "Publish the WSDL" task I mean the service provider exposing the service contract to the consumer, either directly or indirectly by publishing it to some registry, so it's a response to a dynamic HTTP "GET ...?wsdl" query in the former case. I was thinking of WSDLPublisher, at a publish time, just removing the private stuff inside policy expressions at a publication time only, possibly checking for 'private' attribute.
So I like what you suggested about the seperation, it's just that I feel it might be useful in some cases to get "the private stuff inside policies" working too, but I wouldn't be concerned about it now as long as we agree on the general principle : public stuff to consumers (and runtime), private stuff to the runtime only.
Cheers, Sergey
----- Original Message -----
From: "Glynn, Eoghan" <eo...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Monday, September 24, 2007 3:43 PM
Subject: RE: Policies and features (Was : WS-SX)
Hi Sergey,
I agree with much of what you said, in particular that we need to be
clearer in our guidance to help users decide whether they should assert
a policy or apply an "equivalent" feature (the equivalence being fuzzy
at best).
Your suggested inclusion of private stuff in the policy assertions, to
be stripped out when the WSDL is published, is interesting.
In order for this to work, we'd need a well-defined concept of what it
means to "publish" the WSDL. As things stand, the client usually gets
hold of the WSDL in one of two ways, either as a local static copy of
the WSDL file or in response to a dynamic HTTP "GET ...?wsdl" query.
So were you thinking of something like a pre-processor tool that would
be applied to the WSDL to sanitize it of anything unsuitable for the
client's consumption? Potential issues would include (1) the overhead of
an extra step in the deployment work-flow and (2) the incremental work
required for each policy type to make this tool aware of the distinction
between private and public child-elements.
I suppose one approach to #2 would be simply base it on the schema for
the policy type, e.g. any element not in the standard schema would be
considered "private".
However, there are certain potential extensions of the standard policies
that aren't strictly-speaking private and could be "interesting" to the
client, so we may not necessarily want to strip these out.
For example, it may be useful for the client to know that the
ws-rm:reliableMessaging/deliveryAssurance in effect on the
destination-side is AtMostOnce, and use this knowledge to be more
aggressive in resending non-idempotent un-acknowledged messages (safe in
the knowledge that any duplicates would simply be discarded by the RM
destination).
Now one advantage of the alternative approach (public stuff in the
policy, private stuff in the feature, merge at runtime) is that this is
pretty close to what we have right now. We don't enforce the
distinction, but for certain policies/features it is possible to follow
that pattern.
Cheers,
Eoghan
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 24 September 2007 14:34
> To: cxf-dev@incubator.apache.org
> Subject: Policies and features (Was : WS-SX)
>
> Hi Eoghan
>
> I've created a new topic so that I don't interfere with the
> original WS-SX topic...
>
>
> I'd like to step back for a second before answering to your
> specific question.
>
> Lets say we have an ability to express the same
> capability/requirement using several alternative mechanisms,
> for ex, using a WS-Policy policy expression and a CXF
> feature. We can probably agree that providing several options
> is confusing to users and to those writing the documentation.
> At the same time I don't think we can enforce the usage of a
> single alternative. Hence we should have a good idea of when
> to the WS-Policy expressions, when to use CXF features, when
> to use both, and provide guidelines.
>
> IMHO a general guideline is : if it's of public interest
> (interest to consumers) then it's a policy. Otherwise it's a
> feature. If policy-unaware consumers are targeted then both
> alternatives might be used, as such consumers still have to
> configure themselves. If it's a consumer which is being
> configured then both alternatives are usable too but the
> policy is better because more advanced WS-policy features can
> be used when both a consumer and a provider are configured
> with ws-policy.
>
> I think it was too strong to suggect a WS-Security feature
> would be redundant/obsolete if WS-SecurityPolicy were
> supported. I just don't see why would people use a CXF
> feature if a corresponding WS-SecurityPolicy expression were
> available. Only if we could have this feature usable in
> scenarios when no WS-Security was involved (say when people
> work with restful services and do XMLEncryption, etc) then I
> can see why would people choose to use a feature.
> When users are unhappy when seeing WS- appendix then let them
> use features and not worry about policies (though it's worth
> saying a WS-Policy language is not bound to WS-* services and
> the frameworks defines the mechanism to attach policies to
> arbitrary XML elements).
>
> If we were to use WS-SecurityPolicy then we'd need to decide
> where the private stuff would go. As I said earlier two
> options are possible.
> One is to embedd the private stuff inside the policy itself
> and strip it out at the publication time, works with
> wsdl/java first developement, see for example :
>
> 1. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
> "As is the case when you develop your service from WSDL,
> private policy assertions are removed before the final WSDL
> is published. "
> 2. Similar pattern is used in Apache Rampart :
> http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
>
> Alternative approach is to put the public stuff into a policy
> and a private stuff into a feature and merge the info.
> Possibly using the advanced CXF feature mechanism where a
> policy assertion can be embedded into a feature, as in case
> with RM assertions.
>
> So finally I'm getting to your question :
>
> >>Would the same logic apply to the reliableMessaging feature
> versus the
> >>RMAssertion?
>
> I believe we should advise users to use a reliableMessaging
> feature only when it can add a private stuff (which is of no
> interest to consumers of such polices) in addition to what a
> public WS-RM policy can already express.
>
> Alternatively we can advise people to put a private stuff
> inside a policy itself but we'd have to strip it off at the
> publication time. In case of RM we may not even have to do it
> as the private stuff won't be as sensitive as the private
> security stuff and well-behaved RM consumers should ignore
> unrecognized RM extensions.
>
> I think both options can be supported, but with guidelines
> people would be less confused with a number of configuration
> options we have.
>
> Would you agree with what I said ?
>
> Thanks, Sergey
>
>
>
>
> Hi Sergey,
>
> A quick question on your observation that the WS-Security
> feature would be redundant/obsolete if WS-SecurityPolicy were
> supported.
>
> Would the same logic apply to the reliableMessaging feature
> versus the RMAssertion?
>
> Obviously there are some differences in the RM case, in the sense that
> (a) an RMAssertion can be embedded in the reliableMessaging
> feature, and
> (b) otherwise the primary purpose of the reliableMessaging
> feature is to specify "non-private" behavior outside the
> scope of the RMAssertion (e.g. the sequenceTerminationPolicy).
>
> But I'm wondering if your line of reasoning would extend to
> embedding e.g. the sequenceTerminationPolicy as a custom
> extension of the RMAssertion?
>
> Cheers,
> Eoghan
>
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> > Sent: 23 September 2007 13:25
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: WS-SX
> >
> > Hi
> >
> >
> >
> > A couple of comments on WS-SecurityPolicy:
> >
> >
> >
> > 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.
> >
> > This is something I'd be willing to contribute to.
> >
> > 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.
> >
> >
> >
> > 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.
> >
> > 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.
> >
> >
> >
> > 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.
> > Another approach is to put the private stuff outside the policy
> > expression but then merge the information from multiple sources.
> > 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.
> >
> >
> >
> > 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.
> > Supporting both WS-SecurityPolicy and WS-Security feature
> will add to
> > the confusion people already when choosing how to configure a given
> > capability. Additionally, using policies one can annotate
> the contract
> > at a very fine-grained fashion, which is not possible when using
> > features.
> >
> >
> >
> > I still think something like WS-Security feature has its
> > place. It can be used by users which just don't want to use
> > WS-SecurityPolicy for whatever reasons and who are happy with
> > being able to annotate a limited part of the contract. More
> > realistically though one can probably use WS-Security feature
> > to keep the private stuff like passwords but have everything
> > else kept in the corresponding policy expression.
> >
> >
> >
> > Cheers, Sergey
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _____
> >
> > From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> > Sent: 22 September 2007 21:38
> > To: cxf-dev@incubator.apache.org
> > Subject: WS-SX
> >
> >
> >
> > One of the things on my wishlist for 2.1 is support for WS-SX
> > - WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its
> > a very important feature for a lot of corporations because it
> > enables much faster security and it also enables a range of
> > security scenarios which weren't possible before.
> >
> > I know I've chatted with Fred a bit about this before, but
> > I'd like to bring the discussion to the dev list for a while
> > so we can a) figure out the scope of the work b) decide if we
> > can do it for 2.1 and c) figure out who's going to do what.
> > Regarding this last point, I will be very happy to
> > particpate, but I'm not sure I can do the majority of the
> > work. But I can certainly code some and help brainstorm.
> >
> > At a high level I suppose there are several things we need to do:
> >
> > 1. Build a WS-Trust service for token exchange. At the
> > very least we
> > need to be able to create symmetric keys from the asymmetric
> > public keys for WS-SecureConversation.
> > 2. WS-SecurityPolicy
> >
> > 1. First we need to start using JAXB catalog files. These
> > files allow
> > JAXB to use classes which have already been generated when
> > doing xsd2java.
> > In other words, our ws-security module can generate the
> > security policy beans and reference the beans in the policy
> > module. Whereas right now, the policy beans would be
> > regenerated by JAXB. This requires an upgrade to JAXB
> > 2.1 and also it requires use of the official/Mojo JAXB plugin
> > instead of our own. Our own plugin is architected in such a
> > way that adding this feature isn't really possible without a
> > rewrite, which seems like a waste of time.
> > 2. Which, if not all, policy assertions do we need to support?
> >
> > 3. WS-SecureConversation service and interceptors
> > 4. WS-Security feature for configuration (I heard through
> > the grapevine
> > someone may have started on this. Would be interested to see
> > what has been done - I really like the way Spring-WS does
> > WS-Security configuration so it may be interesting to look
> into that)
> >
> > So with that - anyone else looked into this in more detail?
> > Anyone want to help pick up this feature for 2.1?
> >
> > Cheers,
> > - Dan
> >
> >
> >
> > --
> > Dan Diephouse
> > MuleSource
> > http://mulesource.com | http://netzooid.com/blog
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland) Registered
> > Number: 171387 Registered Address: The IONA Building,
> > Shelbourne Road, Dublin 4, Ireland
> >
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road,
> Dublin 4, Ireland
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road,
> Dublin 4, Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Policies and features (Was : WS-SX)
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Fred
Only true security expert can express this concern :-)
I agree that putting a private stuff inside a public policy may not be desirable. As I said, I'm not trying to suggest that
"private stuff in public policies" is the only true way to go. I just feel it might be handy sometimes to be able to do so. We can put the private stuff into features. I'm not certain it will guarantee that no leakage will occur though :-) though it will be user's responsibility to keep that private info safe which is better for runtime :-)
Cheers, Sergey
----- Original Message -----
From: "Fred Dushin" <fr...@dushin.net>
To: <cx...@incubator.apache.org>
Sent: Monday, September 24, 2007 4:35 PM
Subject: Re: Policies and features (Was : WS-SX)
> Another is information "leakage". I am uncomfortable with putting
> sensitive security information in a service contract (such as a
> private key password), and just trusting the runtime to not publish
> it. How would an auditor be assured this information is not disclosed?
>
> -Fred
>
> On Sep 24, 2007, at 10:43 AM, Glynn, Eoghan wrote:
>
>> Now one advantage of the alternative approach (public stuff in the
>> policy, private stuff in the feature, merge at runtime) is that
>> this is
>> pretty close to what we have right now. We don't enforce the
>> distinction, but for certain policies/features it is possible to
>> follow
>> that pattern.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Policies and features (Was : WS-SX)
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 24 September 2007 16:35
> To: cxf-dev@incubator.apache.org
> Subject: Re: Policies and features (Was : WS-SX)
>
> Another is information "leakage". I am uncomfortable with
> putting sensitive security information in a service contract
> (such as a private key password), and just trusting the
> runtime to not publish it. How would an auditor be assured
> this information is not disclosed?
Yep, the possibility of the WSDL "sanitization" being over-looked is one
of the things I was thinking about when I mentioned this extra step in
the deployment work-flow being an issue.
One approach to ensuring the sanitization always occurs would be only
publish WSDL to secure clients via the dynamic route (i.e. via a HTTP
"GET ...?wsdl" as opposed to a static copy of the WSDL file). Then the
pre-processing of the WSDL could be plugged into the WSDL QueryHandler
logic.
It would be clunky, but at least less error-prone than relying on the
deployer to manually run a pre-processor over the WSDL before
provisioning a static copy to the client.
Cheers,
Eoghan
> -Fred
>
> On Sep 24, 2007, at 10:43 AM, Glynn, Eoghan wrote:
>
> > Now one advantage of the alternative approach (public stuff in the
> > policy, private stuff in the feature, merge at runtime) is that
> > this is
> > pretty close to what we have right now. We don't enforce the
> > distinction, but for certain policies/features it is possible to
> > follow
> > that pattern.
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Policies and features (Was : WS-SX)
Posted by Fred Dushin <fr...@dushin.net>.
Another is information "leakage". I am uncomfortable with putting
sensitive security information in a service contract (such as a
private key password), and just trusting the runtime to not publish
it. How would an auditor be assured this information is not disclosed?
-Fred
On Sep 24, 2007, at 10:43 AM, Glynn, Eoghan wrote:
> Now one advantage of the alternative approach (public stuff in the
> policy, private stuff in the feature, merge at runtime) is that
> this is
> pretty close to what we have right now. We don't enforce the
> distinction, but for certain policies/features it is possible to
> follow
> that pattern.
RE: Policies and features (Was : WS-SX)
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Hi Sergey,
I agree with much of what you said, in particular that we need to be
clearer in our guidance to help users decide whether they should assert
a policy or apply an "equivalent" feature (the equivalence being fuzzy
at best).
Your suggested inclusion of private stuff in the policy assertions, to
be stripped out when the WSDL is published, is interesting.
In order for this to work, we'd need a well-defined concept of what it
means to "publish" the WSDL. As things stand, the client usually gets
hold of the WSDL in one of two ways, either as a local static copy of
the WSDL file or in response to a dynamic HTTP "GET ...?wsdl" query.
So were you thinking of something like a pre-processor tool that would
be applied to the WSDL to sanitize it of anything unsuitable for the
client's consumption? Potential issues would include (1) the overhead of
an extra step in the deployment work-flow and (2) the incremental work
required for each policy type to make this tool aware of the distinction
between private and public child-elements.
I suppose one approach to #2 would be simply base it on the schema for
the policy type, e.g. any element not in the standard schema would be
considered "private".
However, there are certain potential extensions of the standard policies
that aren't strictly-speaking private and could be "interesting" to the
client, so we may not necessarily want to strip these out.
For example, it may be useful for the client to know that the
ws-rm:reliableMessaging/deliveryAssurance in effect on the
destination-side is AtMostOnce, and use this knowledge to be more
aggressive in resending non-idempotent un-acknowledged messages (safe in
the knowledge that any duplicates would simply be discarded by the RM
destination).
Now one advantage of the alternative approach (public stuff in the
policy, private stuff in the feature, merge at runtime) is that this is
pretty close to what we have right now. We don't enforce the
distinction, but for certain policies/features it is possible to follow
that pattern.
Cheers,
Eoghan
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 24 September 2007 14:34
> To: cxf-dev@incubator.apache.org
> Subject: Policies and features (Was : WS-SX)
>
> Hi Eoghan
>
> I've created a new topic so that I don't interfere with the
> original WS-SX topic...
>
>
> I'd like to step back for a second before answering to your
> specific question.
>
> Lets say we have an ability to express the same
> capability/requirement using several alternative mechanisms,
> for ex, using a WS-Policy policy expression and a CXF
> feature. We can probably agree that providing several options
> is confusing to users and to those writing the documentation.
> At the same time I don't think we can enforce the usage of a
> single alternative. Hence we should have a good idea of when
> to the WS-Policy expressions, when to use CXF features, when
> to use both, and provide guidelines.
>
> IMHO a general guideline is : if it's of public interest
> (interest to consumers) then it's a policy. Otherwise it's a
> feature. If policy-unaware consumers are targeted then both
> alternatives might be used, as such consumers still have to
> configure themselves. If it's a consumer which is being
> configured then both alternatives are usable too but the
> policy is better because more advanced WS-policy features can
> be used when both a consumer and a provider are configured
> with ws-policy.
>
> I think it was too strong to suggect a WS-Security feature
> would be redundant/obsolete if WS-SecurityPolicy were
> supported. I just don't see why would people use a CXF
> feature if a corresponding WS-SecurityPolicy expression were
> available. Only if we could have this feature usable in
> scenarios when no WS-Security was involved (say when people
> work with restful services and do XMLEncryption, etc) then I
> can see why would people choose to use a feature.
> When users are unhappy when seeing WS- appendix then let them
> use features and not worry about policies (though it's worth
> saying a WS-Policy language is not bound to WS-* services and
> the frameworks defines the mechanism to attach policies to
> arbitrary XML elements).
>
> If we were to use WS-SecurityPolicy then we'd need to decide
> where the private stuff would go. As I said earlier two
> options are possible.
> One is to embedd the private stuff inside the policy itself
> and strip it out at the publication time, works with
> wsdl/java first developement, see for example :
>
> 1. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
> "As is the case when you develop your service from WSDL,
> private policy assertions are removed before the final WSDL
> is published. "
> 2. Similar pattern is used in Apache Rampart :
> http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
>
> Alternative approach is to put the public stuff into a policy
> and a private stuff into a feature and merge the info.
> Possibly using the advanced CXF feature mechanism where a
> policy assertion can be embedded into a feature, as in case
> with RM assertions.
>
> So finally I'm getting to your question :
>
> >>Would the same logic apply to the reliableMessaging feature
> versus the
> >>RMAssertion?
>
> I believe we should advise users to use a reliableMessaging
> feature only when it can add a private stuff (which is of no
> interest to consumers of such polices) in addition to what a
> public WS-RM policy can already express.
>
> Alternatively we can advise people to put a private stuff
> inside a policy itself but we'd have to strip it off at the
> publication time. In case of RM we may not even have to do it
> as the private stuff won't be as sensitive as the private
> security stuff and well-behaved RM consumers should ignore
> unrecognized RM extensions.
>
> I think both options can be supported, but with guidelines
> people would be less confused with a number of configuration
> options we have.
>
> Would you agree with what I said ?
>
> Thanks, Sergey
>
>
>
>
> Hi Sergey,
>
> A quick question on your observation that the WS-Security
> feature would be redundant/obsolete if WS-SecurityPolicy were
> supported.
>
> Would the same logic apply to the reliableMessaging feature
> versus the RMAssertion?
>
> Obviously there are some differences in the RM case, in the sense that
> (a) an RMAssertion can be embedded in the reliableMessaging
> feature, and
> (b) otherwise the primary purpose of the reliableMessaging
> feature is to specify "non-private" behavior outside the
> scope of the RMAssertion (e.g. the sequenceTerminationPolicy).
>
> But I'm wondering if your line of reasoning would extend to
> embedding e.g. the sequenceTerminationPolicy as a custom
> extension of the RMAssertion?
>
> Cheers,
> Eoghan
>
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> > Sent: 23 September 2007 13:25
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: WS-SX
> >
> > Hi
> >
> >
> >
> > A couple of comments on WS-SecurityPolicy:
> >
> >
> >
> > 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.
> >
> > This is something I'd be willing to contribute to.
> >
> > 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.
> >
> >
> >
> > 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.
> >
> > 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.
> >
> >
> >
> > 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.
> > Another approach is to put the private stuff outside the policy
> > expression but then merge the information from multiple sources.
> > 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.
> >
> >
> >
> > 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.
> > Supporting both WS-SecurityPolicy and WS-Security feature
> will add to
> > the confusion people already when choosing how to configure a given
> > capability. Additionally, using policies one can annotate
> the contract
> > at a very fine-grained fashion, which is not possible when using
> > features.
> >
> >
> >
> > I still think something like WS-Security feature has its
> > place. It can be used by users which just don't want to use
> > WS-SecurityPolicy for whatever reasons and who are happy with
> > being able to annotate a limited part of the contract. More
> > realistically though one can probably use WS-Security feature
> > to keep the private stuff like passwords but have everything
> > else kept in the corresponding policy expression.
> >
> >
> >
> > Cheers, Sergey
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _____
> >
> > From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> > Sent: 22 September 2007 21:38
> > To: cxf-dev@incubator.apache.org
> > Subject: WS-SX
> >
> >
> >
> > One of the things on my wishlist for 2.1 is support for WS-SX
> > - WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its
> > a very important feature for a lot of corporations because it
> > enables much faster security and it also enables a range of
> > security scenarios which weren't possible before.
> >
> > I know I've chatted with Fred a bit about this before, but
> > I'd like to bring the discussion to the dev list for a while
> > so we can a) figure out the scope of the work b) decide if we
> > can do it for 2.1 and c) figure out who's going to do what.
> > Regarding this last point, I will be very happy to
> > particpate, but I'm not sure I can do the majority of the
> > work. But I can certainly code some and help brainstorm.
> >
> > At a high level I suppose there are several things we need to do:
> >
> > 1. Build a WS-Trust service for token exchange. At the
> > very least we
> > need to be able to create symmetric keys from the asymmetric
> > public keys for WS-SecureConversation.
> > 2. WS-SecurityPolicy
> >
> > 1. First we need to start using JAXB catalog files. These
> > files allow
> > JAXB to use classes which have already been generated when
> > doing xsd2java.
> > In other words, our ws-security module can generate the
> > security policy beans and reference the beans in the policy
> > module. Whereas right now, the policy beans would be
> > regenerated by JAXB. This requires an upgrade to JAXB
> > 2.1 and also it requires use of the official/Mojo JAXB plugin
> > instead of our own. Our own plugin is architected in such a
> > way that adding this feature isn't really possible without a
> > rewrite, which seems like a waste of time.
> > 2. Which, if not all, policy assertions do we need to support?
> >
> > 3. WS-SecureConversation service and interceptors
> > 4. WS-Security feature for configuration (I heard through
> > the grapevine
> > someone may have started on this. Would be interested to see
> > what has been done - I really like the way Spring-WS does
> > WS-Security configuration so it may be interesting to look
> into that)
> >
> > So with that - anyone else looked into this in more detail?
> > Anyone want to help pick up this feature for 2.1?
> >
> > Cheers,
> > - Dan
> >
> >
> >
> > --
> > Dan Diephouse
> > MuleSource
> > http://mulesource.com | http://netzooid.com/blog
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland) Registered
> > Number: 171387 Registered Address: The IONA Building,
> > Shelbourne Road, Dublin 4, Ireland
> >
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road,
> Dublin 4, Ireland
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road,
> Dublin 4, Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Policies and features (Was : WS-SX)
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Eoghan
I've created a new topic so that I don't interfere with the original WS-SX topic...
I'd like to step back for a second before answering to your specific question.
Lets say we have an ability to express the same capability/requirement using several alternative mechanisms, for ex, using a WS-Policy policy expression and a CXF feature. We can probably agree that providing several options is confusing to users and to those writing the documentation. At the same time I don't think we can enforce the usage of a single alternative. Hence we should have a good idea of when to the WS-Policy expressions, when to use CXF features, when to use both, and provide guidelines.
IMHO a general guideline is : if it's of public interest (interest to consumers) then it's a policy. Otherwise it's a feature. If policy-unaware consumers are targeted then both alternatives might be used, as such consumers still have to configure themselves. If it's a consumer which is being configured then both alternatives are usable too but the policy is better because more advanced WS-policy features can be used when both a consumer and a provider are configured with ws-policy.
I think it was too strong to suggect a WS-Security feature would be redundant/obsolete if WS-SecurityPolicy were supported. I just don't see why would people use a CXF feature if a corresponding WS-SecurityPolicy expression were available. Only if we could have this feature usable in scenarios when no WS-Security was involved (say when people work with restful services and do XMLEncryption, etc) then I can see why would people choose to use a feature.
When users are unhappy when seeing WS- appendix then let them use features and not worry about policies (though it's worth saying a WS-Policy language is not bound to WS-* services and the frameworks defines the mechanism to attach policies to arbitrary XML elements).
If we were to use WS-SecurityPolicy then we'd need to decide where the private stuff would go. As I said earlier two options are possible.
One is to embedd the private stuff inside the policy itself and strip it out at the publication time, works with wsdl/java first
developement, see for example :
1. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
"As is the case when you develop your service from WSDL, private policy assertions are removed before the final WSDL is published. "
2. Similar pattern is used in Apache Rampart :
http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
Alternative approach is to put the public stuff into a policy and a private stuff into a feature and merge the info. Possibly using the advanced CXF feature mechanism where a policy assertion can be embedded into a feature, as in case with RM assertions.
So finally I'm getting to your question :
>>Would the same logic apply to the reliableMessaging feature versus the
>>RMAssertion?
I believe we should advise users to use a reliableMessaging feature only when it can add a private stuff (which is of no interest to consumers of such polices) in addition to what a public WS-RM policy can already express.
Alternatively we can advise people to put a private stuff inside a policy itself but we'd have to strip it off at the publication time. In case of RM we may not even have to do it as the private stuff won't be as sensitive as the private security stuff and well-behaved RM consumers should ignore unrecognized RM extensions.
I think both options can be supported, but with guidelines people would be less confused with a number of configuration options we have.
Would you agree with what I said ?
Thanks, Sergey
Hi Sergey,
A quick question on your observation that the WS-Security feature would
be redundant/obsolete if WS-SecurityPolicy were supported.
Would the same logic apply to the reliableMessaging feature versus the
RMAssertion?
Obviously there are some differences in the RM case, in the sense that
(a) an RMAssertion can be embedded in the reliableMessaging feature, and
(b) otherwise the primary purpose of the reliableMessaging feature is to
specify "non-private" behavior outside the scope of the RMAssertion
(e.g. the sequenceTerminationPolicy).
But I'm wondering if your line of reasoning would extend to embedding
e.g. the sequenceTerminationPolicy as a custom extension of the
RMAssertion?
Cheers,
Eoghan
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 23 September 2007 13:25
> To: cxf-dev@incubator.apache.org
> Subject: RE: WS-SX
>
> Hi
>
>
>
> A couple of comments on WS-SecurityPolicy:
>
>
>
> 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.
>
> This is something I'd be willing to contribute to.
>
> 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.
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
> Another approach is to put the private stuff outside the
> policy expression but then merge the information from
> multiple sources. 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.
>
>
>
> 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. Supporting
> both WS-SecurityPolicy and WS-Security feature will add to
> the confusion people already when choosing how to configure a
> given capability. Additionally, using policies one can
> annotate the contract at a very fine-grained fashion, which
> is not possible when using features.
>
>
>
> I still think something like WS-Security feature has its
> place. It can be used by users which just don't want to use
> WS-SecurityPolicy for whatever reasons and who are happy with
> being able to annotate a limited part of the contract. More
> realistically though one can probably use WS-Security feature
> to keep the private stuff like passwords but have everything
> else kept in the corresponding policy expression.
>
>
>
> Cheers, Sergey
>
>
>
>
>
>
>
>
>
> _____
>
> From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> Sent: 22 September 2007 21:38
> To: cxf-dev@incubator.apache.org
> Subject: WS-SX
>
>
>
> One of the things on my wishlist for 2.1 is support for WS-SX
> - WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its
> a very important feature for a lot of corporations because it
> enables much faster security and it also enables a range of
> security scenarios which weren't possible before.
>
> I know I've chatted with Fred a bit about this before, but
> I'd like to bring the discussion to the dev list for a while
> so we can a) figure out the scope of the work b) decide if we
> can do it for 2.1 and c) figure out who's going to do what.
> Regarding this last point, I will be very happy to
> particpate, but I'm not sure I can do the majority of the
> work. But I can certainly code some and help brainstorm.
>
> At a high level I suppose there are several things we need to do:
>
> 1. Build a WS-Trust service for token exchange. At the
> very least we
> need to be able to create symmetric keys from the asymmetric
> public keys for WS-SecureConversation.
> 2. WS-SecurityPolicy
>
> 1. First we need to start using JAXB catalog files. These
> files allow
> JAXB to use classes which have already been generated when
> doing xsd2java.
> In other words, our ws-security module can generate the
> security policy beans and reference the beans in the policy
> module. Whereas right now, the policy beans would be
> regenerated by JAXB. This requires an upgrade to JAXB
> 2.1 and also it requires use of the official/Mojo JAXB plugin
> instead of our own. Our own plugin is architected in such a
> way that adding this feature isn't really possible without a
> rewrite, which seems like a waste of time.
> 2. Which, if not all, policy assertions do we need to support?
>
> 3. WS-SecureConversation service and interceptors
> 4. WS-Security feature for configuration (I heard through
> the grapevine
> someone may have started on this. Would be interested to see
> what has been done - I really like the way Spring-WS does
> WS-Security configuration so it may be interesting to look into that)
>
> So with that - anyone else looked into this in more detail?
> Anyone want to help pick up this feature for 2.1?
>
> Cheers,
> - Dan
>
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland) Registered
> Number: 171387 Registered Address: The IONA Building,
> Shelbourne Road, Dublin 4, Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: WS-SX
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Hi Sergey,
A quick question on your observation that the WS-Security feature would
be redundant/obsolete if WS-SecurityPolicy were supported.
Would the same logic apply to the reliableMessaging feature versus the
RMAssertion?
Obviously there are some differences in the RM case, in the sense that
(a) an RMAssertion can be embedded in the reliableMessaging feature, and
(b) otherwise the primary purpose of the reliableMessaging feature is to
specify "non-private" behavior outside the scope of the RMAssertion
(e.g. the sequenceTerminationPolicy).
But I'm wondering if your line of reasoning would extend to embedding
e.g. the sequenceTerminationPolicy as a custom extension of the
RMAssertion?
Cheers,
Eoghan
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 23 September 2007 13:25
> To: cxf-dev@incubator.apache.org
> Subject: RE: WS-SX
>
> Hi
>
>
>
> A couple of comments on WS-SecurityPolicy:
>
>
>
> 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.
>
> This is something I'd be willing to contribute to.
>
> 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.
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
> Another approach is to put the private stuff outside the
> policy expression but then merge the information from
> multiple sources. 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.
>
>
>
> 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. Supporting
> both WS-SecurityPolicy and WS-Security feature will add to
> the confusion people already when choosing how to configure a
> given capability. Additionally, using policies one can
> annotate the contract at a very fine-grained fashion, which
> is not possible when using features.
>
>
>
> I still think something like WS-Security feature has its
> place. It can be used by users which just don't want to use
> WS-SecurityPolicy for whatever reasons and who are happy with
> being able to annotate a limited part of the contract. More
> realistically though one can probably use WS-Security feature
> to keep the private stuff like passwords but have everything
> else kept in the corresponding policy expression.
>
>
>
> Cheers, Sergey
>
>
>
>
>
>
>
>
>
> _____
>
> From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> Sent: 22 September 2007 21:38
> To: cxf-dev@incubator.apache.org
> Subject: WS-SX
>
>
>
> One of the things on my wishlist for 2.1 is support for WS-SX
> - WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its
> a very important feature for a lot of corporations because it
> enables much faster security and it also enables a range of
> security scenarios which weren't possible before.
>
> I know I've chatted with Fred a bit about this before, but
> I'd like to bring the discussion to the dev list for a while
> so we can a) figure out the scope of the work b) decide if we
> can do it for 2.1 and c) figure out who's going to do what.
> Regarding this last point, I will be very happy to
> particpate, but I'm not sure I can do the majority of the
> work. But I can certainly code some and help brainstorm.
>
> At a high level I suppose there are several things we need to do:
>
> 1. Build a WS-Trust service for token exchange. At the
> very least we
> need to be able to create symmetric keys from the asymmetric
> public keys for WS-SecureConversation.
> 2. WS-SecurityPolicy
>
> 1. First we need to start using JAXB catalog files. These
> files allow
> JAXB to use classes which have already been generated when
> doing xsd2java.
> In other words, our ws-security module can generate the
> security policy beans and reference the beans in the policy
> module. Whereas right now, the policy beans would be
> regenerated by JAXB. This requires an upgrade to JAXB
> 2.1 and also it requires use of the official/Mojo JAXB plugin
> instead of our own. Our own plugin is architected in such a
> way that adding this feature isn't really possible without a
> rewrite, which seems like a waste of time.
> 2. Which, if not all, policy assertions do we need to support?
>
> 3. WS-SecureConversation service and interceptors
> 4. WS-Security feature for configuration (I heard through
> the grapevine
> someone may have started on this. Would be interested to see
> what has been done - I really like the way Spring-WS does
> WS-Security configuration so it may be interesting to look into that)
>
> So with that - anyone else looked into this in more detail?
> Anyone want to help pick up this feature for 2.1?
>
> Cheers,
> - Dan
>
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland) Registered
> Number: 171387 Registered Address: The IONA Building,
> Shelbourne Road, Dublin 4, Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland