Hi Yogesh, Looking at the code, you can actually do the same thing with the "signaturePropertiesFile" or the "encryptionPropertiesFile" of the "StaticSTSProperties". I guess they should be renamed to be a bit clearer. Could you try with util:Properties and let me know if it works?
Colm. On Thu, Dec 13, 2012 at 4:20 PM, ychawla <[email protected]>wrote: > Hello All, > I am working on pulling literals out of my code base and moving as much as > I > can to properties file. > > When configuring signature properties on a JAX-WS endpoint, you can either > point to a keystore properties file or provide properties. To provide > properties, you can do this: > > <entry key="ws-security.signature.properties" > value-ref="stsKeystoreProperties" /> > > <util:properties id="stsKeystoreProperties"> > <prop > > key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop> > <prop > key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop> > <prop > > key="org.apache.ws.security.crypto.merlin.keystore.password">stsspass</prop> > <prop > key="org.apache.ws.security.crypto.merlin.keystore.alias">mystskey</prop> > <prop > > key="org.apache.ws.security.crypto.merlin.keystore.file">stsstore.jks</prop> > </util:properties> > > You can then take the using Spring Property Placedholder Configurer to set > the values for alias, file, password, etc. > > When working with the StaticSTSProperties, you can only configure the > keystore properties file as far as I can tell. To add greater flexibility, > you can add a 'Properties' variable like so: > > private Properties sigProperties; > > You can then update the 'configureProperties' to support either a > properties > object or properties file: > > //Only allow either signature properties or signature properties file > if (sigProperties != null && signaturePropertiesFile != null) { > throw new STSException("Configuration error: cannot load > signature > properties. You should either set the signature properties file or > signature properties but not both"); > } > > //load the signatureCrypto from the properties object > if (signatureCrypto == null && sigProperties != null) { > try { > signatureCrypto = CryptoFactory.getInstance(sigProperties); > } catch (WSSecurityException ex) { > LOG.fine("Error in loading the signature Crypto object: " + > ex.getMessage()); > throw new STSException(ex.getMessage()); > } > } > > //load the signatureCrypto from the signature properties file > if (signatureCrypto == null && signaturePropertiesFile != null) { > Properties sigProperties = getProps(signaturePropertiesFile); > if (sigProperties == null) { > LOG.fine("Cannot load signature properties using: " + > signaturePropertiesFile); > throw new STSException("Configuration error: cannot load > signature properties"); > } > try { > signatureCrypto = CryptoFactory.getInstance(sigProperties); > } catch (WSSecurityException ex) { > LOG.fine("Error in loading the signature Crypto object: " + > ex.getMessage()); > throw new STSException(ex.getMessage()); > } > } > > The encryption properties can be handled in the same way. Would this be a > good addition to the StaticSTSProperties file or would it conflict with > anything? I have tried it out in my local environment and it is working. > > I can create a JIRA and submit a patch for this. > > Thanks, > Yogesh > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/CXF-STS-StaticSTSProperties-flexible-configuration-tp5720224.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
