Ah wait, I didn't read the full message. I wasn't on crack - the
<KeyStore> element *is* proprietary.
Here's all I want out of the WS-SecPol stuff. An easy way to configure
key store information for the server/client from the API. The best way
to do this seems to be a WSSXFeature of some sort. We can also support
our own <KeyStore>/<TrustStore> elements and the like. But it seems
critical to me that we support configuration of this information via the
API as well, and the best place for this seems to be a Feature. This is
*complementary* to policy and I'm not trying to replace it. Both will
still be needed for the server/client configuration.
Cheers,
- Dan
Dan Diephouse wrote:
Thanks for the example Sergey, that does help clear things up. I
didn't realize there was a visibility element, nor did I realize that
there were actually standard expressions for configuring the private
key info.
Question then: what *can't* be configured via standard ws-secpol
policy expressions? I'm confused now, as it was my understanding that
these things required proprietary extensions for configuration.
If there isn't actually anything else the user needs to supply, I
agree - it makes sense to just configure ws-sx via policy. In the case
of the client, they can just write a small policy file with the
necessary trust information and attach it via the policy feature bits
which have already been developed.
Cheers,
- Dan
Sergey Beryozkin wrote:
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
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
