You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2010/07/22 21:44:42 UTC
Simplify the configuration options on the WS-Trust page?
Team,
On the STS client page[1], the property keys configured for the direct and
indirect configuration options for an STS client seem unnecessarily
different:
direct configuration uses:
<entry key="ws-security.username" value="joe"/>
<entry key="ws-security.callback-handler"
value="interop.client.KeystorePasswordCallback"/>
<entry key="ws-security.signature.properties" value="etc/alice.properties"/>
<entry key="ws-security.encryption.properties" value="etc/bob.properties"/>
indirect configuration uses:
<entry key="ws-security.sts.token.properties" value="etc/bob.properties"/>
<entry key="ws-security.callback-handler"
value="interop.client.KeystorePasswordCallback"/>
<entry key="ws-security.signature.properties" value="etc/alice.properties"/>
<entry key="ws-security.encryption.properties" value="etc/bob.properties"/>
The example would probably be clearer if the configuration were the same for
both, or at least some explanation given why they should be different.
(BTW, what is "ws-security.sts.token.properties" for? I haven't needed it.)
Any problem with standardizing to the same sample config? This is what I'm
using locally for my test client against a Metro STS:
<entry key="ws-security.username" value="alice"/>
<entry key="ws-security.callback-handler" value="client.MyCallbackHandler"/>
<entry key="ws-security.signature.properties"
value="clientKeystore.properties"/>
<entry key="ws-security.encryption.properties"
value="clientKeystore.properties"/>
<entry key="ws-security.encryption.username" value="mystskey"/>
Where clientKeystore.properties is this:
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=cspass
org.apache.ws.security.crypto.merlin.keystore.alias=myclientkey
org.apache.ws.security.crypto.merlin.file=clientstore.jks
It seems to work fine, requires one less properties file, providing you use
the same keystore for the truststore--I can put in a sentence telling the
user to have separate "ws-security.signature.properties" and
"ws-security.encryption.properties" values if the keystore and truststore
are different.
Thoughts?
Thanks,
Glen
[1] http://cxf.apache.org/docs/ws-trust.html
--
View this message in context: http://cxf.547215.n5.nabble.com/Simplify-the-configuration-options-on-the-WS-Trust-page-tp1842738p1842738.html
Sent from the cxf-dev mailing list archive at Nabble.com.
RE: Simplify the configuration options on the WS-Trust page?
Posted by Glen Mazza <gl...@gmail.com>.
OK, since there are (at least) two types of client<->STS validation options,
I kept the upper one at UsernameToken and the lower at X.509 so readers will
have two examples, and also fattened up the documentation a bit. You can
add in the ActAs documentation elements once 2.3 is ready (or when you have
ActAs working.)
Thanks,
Glen
dvaleri wrote:
>
> ws-security.sts.token.properties is used to provide key material to the
> STS
> when you specify a KeyType. I have used this when the STS issues tokens
> based on PKI credentials. The docs also mention being used to decrypt
> encrypted tokens.
>
> I added another property today ws-security.sts.token.act-as, that supports
> a
> WS-T 1.4 ActAs element in the request. I think the example needs to be
> cleaned up like you mention, but I also think we need to provide a
> complete
> list of configuration options on that page.
>
--
View this message in context: http://cxf.547215.n5.nabble.com/Simplify-the-configuration-options-on-the-WS-Trust-page-tp1842738p1843012.html
Sent from the cxf-dev mailing list archive at Nabble.com.
RE: Simplify the configuration options on the WS-Trust page?
Posted by David Valeri <dv...@apache.org>.
ws-security.sts.token.properties is used to provide key material to the STS
when you specify a KeyType. I have used this when the STS issues tokens
based on PKI credentials. The docs also mention being used to decrypt
encrypted tokens.
I added another property today ws-security.sts.token.act-as, that supports a
WS-T 1.4 ActAs element in the request. I think the example needs to be
cleaned up like you mention, but I also think we need to provide a complete
list of configuration options on that page.
-----Original Message-----
From: Glen Mazza [mailto:glen.mazza@gmail.com]
Sent: Thursday, July 22, 2010 3:45 PM
To: dev@cxf.apache.org
Subject: Simplify the configuration options on the WS-Trust page?
Team,
On the STS client page[1], the property keys configured for the direct and
indirect configuration options for an STS client seem unnecessarily
different:
direct configuration uses:
<entry key="ws-security.username" value="joe"/>
<entry key="ws-security.callback-handler"
value="interop.client.KeystorePasswordCallback"/>
<entry key="ws-security.signature.properties" value="etc/alice.properties"/>
<entry key="ws-security.encryption.properties" value="etc/bob.properties"/>
indirect configuration uses:
<entry key="ws-security.sts.token.properties" value="etc/bob.properties"/>
<entry key="ws-security.callback-handler"
value="interop.client.KeystorePasswordCallback"/>
<entry key="ws-security.signature.properties" value="etc/alice.properties"/>
<entry key="ws-security.encryption.properties" value="etc/bob.properties"/>
The example would probably be clearer if the configuration were the same for
both, or at least some explanation given why they should be different.
(BTW, what is "ws-security.sts.token.properties" for? I haven't needed it.)
Any problem with standardizing to the same sample config? This is what I'm
using locally for my test client against a Metro STS:
<entry key="ws-security.username" value="alice"/>
<entry key="ws-security.callback-handler" value="client.MyCallbackHandler"/>
<entry key="ws-security.signature.properties"
value="clientKeystore.properties"/>
<entry key="ws-security.encryption.properties"
value="clientKeystore.properties"/>
<entry key="ws-security.encryption.username" value="mystskey"/>
Where clientKeystore.properties is this:
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.cry
pto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=cspass
org.apache.ws.security.crypto.merlin.keystore.alias=myclientkey
org.apache.ws.security.crypto.merlin.file=clientstore.jks
It seems to work fine, requires one less properties file, providing you use
the same keystore for the truststore--I can put in a sentence telling the
user to have separate "ws-security.signature.properties" and
"ws-security.encryption.properties" values if the keystore and truststore
are different.
Thoughts?
Thanks,
Glen
[1] http://cxf.apache.org/docs/ws-trust.html
--
View this message in context:
http://cxf.547215.n5.nabble.com/Simplify-the-configuration-options-on-the-WS
-Trust-page-tp1842738p1842738.html
Sent from the cxf-dev mailing list archive at Nabble.com.