cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject RE: WS-SX
Date Sun, 23 Sep 2007 12:24:35 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message