Sorry, spam filter does not allow a link to nabble, here's the link to the
message on a cxf-user archive :
[1]
http://mail-archives.apache.org/mod_mbox/incubator-cxf-user/200709.mbox/[EMAIL
PROTECTED]
and in cryptic form to nabble
[1] www dot nabble dot com forwardslash Problems-with-Policy-file-tf4492323 dot
html
----- Original Message -----
From: "Sergey Beryozkin" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 26, 2007 2:27 PM
Subject: Re : WS-SX
Hi Dan
Here's a follow-up mail.
I was thinking that it would help if we look at a concrete user query [1].
Note that there's a WS-SecurityPolicy policy expression attached to the WSDL
contract.
The user has tried this WSDL with a policy expression in Metro and it worked for him. I've no doubt it will for him with quite a few
other stacks. Please also note that no private stuff is located in the policy itself. How Metro achieved hiding the private stuff is
immaterial.
Now, when we're talking about supporting WS-SecurityPolicy, we need to be concrete about exactly are we talking about. If a user
asks [1], can I do it in CXF, what will be our answer once we start claiming we support WS-SecurityPolicy ?
As I said I start feeling that the way you see CXF "supporting" WS-SecurityPolicy is that we look at what is possible to enable with
WS-SecurityPolicy expressions and then translate it all into corresponding feature expressions. As I said it will mean that we will
support no WS-SecurityPolicy but WS-Security. That's why I've quotes about "supporting". As such the only answer we could give to
users asking questions like [1] is that they'll have to convert the security policy expressions into corresponding CXF configuration
artifacts. I don't think it'll be good enough. I'll be happy to be corrected if I've misunderstood the way you envisage it all and I
apologize in advance if it's the case.
Supporting WS-SecurityPolicy means :
* runtime should be capable of accepting explicit policy expressions such as
those shown at [1]. As we've discussed
there's a number of ways to provide the missing private stuff to the runtime
* When a secure service provider publishes its WSDL, this WSDL has to contain WS-SecurityPolicy expressions in the right attachment
points inline or through external references. (optional bit)
This is what I believe will make "CXF supports WS-SecurityPolicy" a true
statement.
Now if there's a strong interest behind providing a WS-Security feature which will let users to basically set up the runtime by
providing it the same info WS-SecurityPolicy policies can give it, then it's fare enough. It's likely some users will want to use
this option. I just don't think it has something to do with the work required to support WS-SecurityPolicy.
Thanks, Sergey
----------------------------
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
