cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Valeri" <dval...@apache.org>
Subject RE: Simplify the configuration options on the WS-Trust page?
Date Thu, 22 Jul 2010 21:02:20 GMT
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.


Mime
View raw message