Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of eoghan.glynn@iona.com
 designates 62.221.12.55 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: WS-SX
Date: Mon, 24 Sep 2007 11:54:41 +0100
Message-ID: <FA1787F64A095C4090E76EBAF8B183E0720056@emea-ems1.IONAGLOBAL.com>
In-Reply-To: <EMEA-EMS1Vux1Zcn8Tt00000174@emea-ems1.ionaglobal.com>
Thread-Topic: WS-SX
Thread-Index: Acf9aaVMRCheile+TziAXCALYLGYmwAaonzAADCZbJA=
From: "Glynn, Eoghan" <eoghan.glynn@iona.com>
To: <cxf-dev@incubator.apache.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


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=2Eg. the sequenceTerminationPolicy as a custom extension of the
RMAssertion?

Cheers,
Eoghan=20

> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]=20
> Sent: 23 September 2007 13:25
> To: cxf-dev@incubator.apache.org
> Subject: RE: WS-SX
>=20
> Hi
>=20
> =20
>=20
> A couple of comments on WS-SecurityPolicy:
>=20
> =20
>=20
> 1.       The core policy framework needs to be enhanced a bit=20
> to deal with
> the normalization of nested polices which are abound in=20
> WS-SecurityPolicy policies,
>=20
> to deal with the effective policy calculation when multiple=20
> Ws-SecurityPolicy polices are attached to multiple points for=20
> a given policy subject like Endpoint, etc.
>=20
> This is something I'd be willing to contribute to.
>=20
> 2.       Supporting those policy assertions which map to what=20
> CXF security
> runtime already supports would be a great start IMHO. This=20
> includes an HTTPS-related assertion too.
>=20
> =20
>=20
> A separate comment on a WS-Security feature. I strongly=20
> believe that we need to revisit the guidelines on when to use=20
> WS-Policy expressions as opposed to CXF features.
>=20
> For ex, lets take WS-SecurityPolicy which we all agree is=20
> worth supporting.
> WS-SecurityPolicy policy expressions are in themselves can do=20
> the configuration just fine.=20
>=20
> But using policy expressions provides for much more than just=20
> statically configuring the runtime. They allow for a next to=20
> unlimited set of enhancements be applied to the consumer of
>=20
> services annotated with such polices. Hence when thinking on=20
> how a given capability or requirement should be  configured=20
> one should prefer using policy expressions when
>=20
> such requirements can be of use to a client/consumer.  =20
>=20
> =20
>=20
> If we take WS-SecurityPolicy then we can see its policy=20
> expressions are about expressing requirements to the=20
> consumers. Configuration is a positive side-effect. One can=20
> attach such a WS-SecurityPolicy assertion either directly in=20
> a WSDL, or using an external attachment mechanism supported=20
> by CXF. I believe Metro and Axis2 support both approaches.=20
> Either way, the question arises where to put the private=20
> stuff, like the key material location, passwords, and the=20
> like. One approach is to put them inside the policy=20
> expression and strip them out at a WSDL publication time.=20
> Another approach is to put the private stuff outside the=20
> policy expression but then merge the information from=20
> multiple sources. Either approach has its pros and cons. The=20
> latter approach, by the way, works perfectly well with=20
> Java-first style of service development, the runtime could=20
> smartly annotate the WSDL at a publication time, which is=20
> what Metro can do.
>=20
> =20
>=20
> So lets have a look at a WS-Security feature. Basically I=20
> believe that if we start supporting WS-SecurityPolicy then=20
> the WS-Security feature becomes redundant/obsolete. If one=20
> uses WS-SecurityPolicy then one does not need to use=20
> WS-Security feature, and if one uses a WS-Security feature=20
> then there's no point in using WS-SecurityPolicy. Supporting=20
> both WS-SecurityPolicy and WS-Security feature will add to=20
> the confusion people already when choosing how to configure a=20
> given capability. Additionally, using policies one can=20
> annotate the contract at a very fine-grained fashion, which=20
> is not possible when using features.=20
>=20
> =20
>=20
> I still think something like WS-Security feature has its=20
> place. It can be used by users which just don't want to use=20
> WS-SecurityPolicy for whatever reasons and who are happy with=20
> being able to annotate a limited part of the contract. More=20
> realistically though one can probably use WS-Security feature=20
> to keep the private stuff like passwords but have everything=20
> else kept in the corresponding policy expression. =20
>=20
> =20
>=20
>  Cheers, Sergey
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
>   _____ =20
>=20
> From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> Sent: 22 September 2007 21:38
> To: cxf-dev@incubator.apache.org
> Subject: WS-SX
>=20
> =20
>=20
> One of the things on my wishlist for 2.1 is support for WS-SX=20
> - WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its=20
> a very important feature for a lot of corporations because it=20
> enables much faster security and it also enables a range of=20
> security scenarios which weren't possible before.=20
>=20
> I know I've chatted with Fred a bit about this before, but=20
> I'd like to bring the discussion to the dev list for a while=20
> so we can a) figure out the scope of the work b) decide if we=20
> can do it for 2.1 and c) figure out who's going to do what.=20
> Regarding this last point, I will be very happy to=20
> particpate, but I'm not sure I can do the majority of the=20
> work. But I can certainly code some and help brainstorm.
>=20
> At a high level I suppose there are several things we need to do:
>=20
> 1.	Build a WS-Trust service for token exchange. At the=20
> very least we
> need to be able to create symmetric keys from the asymmetric=20
> public keys for WS-SecureConversation.
> 2.	WS-SecurityPolicy
>=20
> 1.	First we need to start using JAXB catalog files. These=20
> files allow
> JAXB to use classes which have already been generated when=20
> doing xsd2java.
> In other words, our ws-security module can generate the=20
> security policy beans and reference the beans in the policy=20
> module. Whereas right now, the policy beans would be=20
> regenerated by JAXB. This requires an upgrade to JAXB
> 2.1 and also it requires use of the official/Mojo JAXB plugin=20
> instead of our own. Our own plugin is architected in such a=20
> way that adding this feature isn't really possible without a=20
> rewrite, which seems like a waste of time.
> 2.	Which, if not all, policy assertions do we need to support?
>=20
> 3.	WS-SecureConversation service and interceptors
> 4.	WS-Security feature for configuration (I heard through=20
> the grapevine
> someone may have started on this. Would be interested to see=20
> what has been done - I really like the way Spring-WS does=20
> WS-Security configuration so it may be interesting to look into that)
>=20
> So with that - anyone else looked into this in more detail?=20
> Anyone want to help pick up this feature for 2.1?
>=20
> Cheers,
> - Dan
>=20
>=20
>=20
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>=20
> ----------------------------
> IONA Technologies PLC (registered in Ireland) Registered=20
> Number: 171387 Registered Address: The IONA Building,=20
> Shelbourne Road, Dublin 4, Ireland
>=20

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland