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.ma...@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.
