You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by martin <sk...@gmail.com> on 2012/11/20 09:22:21 UTC
Expanding a webservice client to handle changing keys.
Hello
I am looking into introducing CXF as a viable alternative to the current
webservice framework used at my workplace. For a case I am going to expand
an old program of mine, but I need a little help to do so.
Currently the client and service of my example have a couple of keys which
they use to sign and encrypt the data between them. What I want to do is,
using WS-SecurityPolicy, to make the service capable of handling several
different keys using the “useReqSigCert” approach described in different
tutorials.
But here is the problem:
The challenge here is that the encryption and signature keys for the clients
will not be in a static location on the machines. They will be on USB keys
or other movable storage which the user will carry with him, in order to be
able to use any client on any machine he wishes.
So how do I achieve this?
As I see it there is one primary obstacle.
Every example I have seen so far deals with a static key and a static
password for said key. I will need to be able to specify where the key is,
and what its password is, at runtime.
Serverside, this setup seems easy enough, as there is no reason to have
anything but static keys and passwords. But how do I handle the client?
So my question is:
How do I set up a WS-SecurityPolicy for a CXF client that supports a key and
password for said key that changes from time to time?
1. I am guessing that using spring is not the optimal approach for this
problem, and I will need to specify via the API as briefly discussed here
http://cxf.apache.org/docs/ws-securitypolicy.html is this correct?
On the same page: http://cxf.apache.org/docs/ws-securitypolicy.html
I can see these properties:
ws-security.signature.crypto A Crypto object to be used for signature. If
this is not defined then "ws-security.signature.properties" is used instead.
ws-security.encryption.crypto A Crypto object to be used for encryption. If
this is not defined then "ws-security.encryption.properties" is used
instead.
2. Does this mean that you can define a fully qualified Merlin object and
deliver the reference to it directly to the framework?
Lastly I can see these two properties.
ws-security.signature.properties The Crypto property configuration to use
for signature, if "ws-security.signature.crypto" is not set instead.
ws-security.encryption.properties The Crypto property configuration to use
for encryption, if "ws-security.encryption.crypto" is not set instead.
3. I would also very much like to know exactly which properties I need to
set? I really can’t find anything but narrow examples in either the javadoc
or on the site, and the merlin api is not much help either. Where do i find
a list of what i need to specify in these properties?
Thank you in advance.
-Martin
--
View this message in context: http://cxf.547215.n5.nabble.com/Expanding-a-webservice-client-to-handle-changing-keys-tp5718802.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Expanding a webservice client to handle changing keys.
Posted by Daniel Kulp <dk...@apache.org>.
Note that those keys/values can be set on the clients request context as well:
((BindingProvider)proxy).getRequestContext()
.put( SecurityConstants.ENCRYPT_CRYPTO, crypto);
Within CXF, when we ask for the various crypto things, if it already is a Crypto object, we use it. Otherwise we assume it the properties needed to create the Crypto.
Dan
On Nov 20, 2012, at 9:24 AM, Andrei Shakirin <as...@talend.com> wrote:
> Not WS-Security policy properties, but SecurityConstants.ENCRYPT_CRYPTO (ws-security.encryption.crypto) and SecurityConstants.SIGNATURE_CRYPTO ws-(security.signature.crypto) properties. They are not directly bound with WS-Security Policy.
> You have to say WSS4J interceptors that they should use custom crypto provider, not standard Merlin. It is possible to achieve it through message properties.
> There are different possibilities to do it: in your client/service business code or in custom interceptor. With interceptor solution you will be able to reuse solution for some clients and services.
>
> Cheers,
> Andrei.
>
>> -----Original Message-----
>> From: martin [mailto:skumleren@gmail.com]
>> Sent: Dienstag, 20. November 2012 14:09
>> To: users@cxf.apache.org
>> Subject: RE: Expanding a webservice client to handle changing keys.
>>
>> So what you are doing is using an interceptor to define the WS-Security policy
>> properties before the WSS4J interceptors are invoked, is that correct?
>>
>>
>>
>> --
>> View this message in context: http://cxf.547215.n5.nabble.com/Expanding-
>> a-webservice-client-to-handle-changing-keys-tp5718802p5718827.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
RE: Expanding a webservice client to handle changing keys.
Posted by Andrei Shakirin <as...@talend.com>.
Not WS-Security policy properties, but SecurityConstants.ENCRYPT_CRYPTO (ws-security.encryption.crypto) and SecurityConstants.SIGNATURE_CRYPTO ws-(security.signature.crypto) properties. They are not directly bound with WS-Security Policy.
You have to say WSS4J interceptors that they should use custom crypto provider, not standard Merlin. It is possible to achieve it through message properties.
There are different possibilities to do it: in your client/service business code or in custom interceptor. With interceptor solution you will be able to reuse solution for some clients and services.
Cheers,
Andrei.
> -----Original Message-----
> From: martin [mailto:skumleren@gmail.com]
> Sent: Dienstag, 20. November 2012 14:09
> To: users@cxf.apache.org
> Subject: RE: Expanding a webservice client to handle changing keys.
>
> So what you are doing is using an interceptor to define the WS-Security policy
> properties before the WSS4J interceptors are invoked, is that correct?
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Expanding-
> a-webservice-client-to-handle-changing-keys-tp5718802p5718827.html
> Sent from the cxf-user mailing list archive at Nabble.com.
RE: Expanding a webservice client to handle changing keys.
Posted by martin <sk...@gmail.com>.
So what you are doing is using an interceptor to define the WS-Security
policy properties before the WSS4J interceptors are invoked, is that
correct?
--
View this message in context: http://cxf.547215.n5.nabble.com/Expanding-a-webservice-client-to-handle-changing-keys-tp5718802p5718827.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Expanding a webservice client to handle changing keys.
Posted by Andrei Shakirin <as...@talend.com>.
Sure, it works also with WS-Security Policy. Actually, it is recommended way to enable security in CXF.
Technically CXF just activates appropriate interceptors based on WS-Security Policy assertions using PolicyInterceptorProvider.
Important that your interceptor is called before WSS4J interceptors, otherwise crypto provider settings would not be accepted.
Cheers,
Andrei.
> -----Original Message-----
> From: martin [mailto:skumleren@gmail.com]
> Sent: Dienstag, 20. November 2012 12:41
> To: users@cxf.apache.org
> Subject: RE: Expanding a webservice client to handle changing keys.
>
> --Andrei Shakirin
>
> Will that not defeat the purpose of using the WS-Security Policy engine? I will
> be using clients created in several languages so loosing the WS-Security
> segments would be bad.
> Can i still keep the WS-Security Policy thorough this approach?
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Expanding-
> a-webservice-client-to-handle-changing-keys-tp5718802p5718822.html
> Sent from the cxf-user mailing list archive at Nabble.com.
RE: Expanding a webservice client to handle changing keys.
Posted by martin <sk...@gmail.com>.
--Andrei Shakirin
Will that not defeat the purpose of using the WS-Security Policy engine? I
will be using clients created in several languages so loosing the
WS-Security segments would be bad.
Can i still keep the WS-Security Policy thorough this approach?
--
View this message in context: http://cxf.547215.n5.nabble.com/Expanding-a-webservice-client-to-handle-changing-keys-tp5718802p5718822.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Expanding a webservice client to handle changing keys.
Posted by Andrei Shakirin <as...@talend.com>.
I have resolved it in the following way:
1) Create own implementation of WSS4J Crypto provider (instead Merlin):
public class CustomCryptoProvider extends CryptoBase {
@Override
public X509Certificate[] getX509Certificates(CryptoType cryptoType) {
CryptoType.TYPE type = cryptoType.getType();
X509Certificate[] certs = null;
switch (type) {
case ISSUER_SERIAL: {
certs = getX509CertificatesFromXKMS(cryptoType.getIssuer());
break;
}
case SUBJECT_DN: {
certs = getX509CertificatesFromXKMS(cryptoType.getSubjectDN());
break;
}
case ALIAS: {
...
break;
}
}
return certs;
}
@Override
public String getX509Identifier(X509Certificate cert) {
return cert.getSubjectDN().getName();
}
@Override
public PrivateKey getPrivateKey(X509Certificate certificate, CallbackHandler callbackHandler)
throws WSSecurityException {
...
}
@Override
public PrivateKey getPrivateKey(String identifier, String password) {
...
}
@Override
public boolean verifyTrust(X509Certificate[] certs) throws WSSecurityException {
return verifyTrust(certs, false);
}
@Override
public boolean verifyTrust(X509Certificate[] certs, boolean enableRevocation) throws WSSecurityException {
if(certs == null)
return false;
return xkmsInvoker.validateCertificate(certs[0]);
}
@Override
public boolean verifyTrust(PublicKey publicKey) throws WSSecurityException {
return false;
}
}
Here you can load your certificates and private keys from different key stores, remote, form XKMS, etc.
2) Create custom interceptor that invoked before WSS4JOutInterceptor/WSS4JInInterceptor.
This interceptor sets your own wss4j Crypto implementation for different purposes into message:
Crypto cryptoProvider = new CustomCryptoProvider ();
message.getExchange().put(SecurityConstants.ENCRYPT_CRYPTO, cryptoProvider);
message.getExchange().put(SecurityConstants.SIGNATURE_CRYPTO, cryptoProvider);
message.getExchange().put(SecurityConstants.STS_TOKEN_CRYPTO, cryptoProvider);
After that, your crypto provider will be called automatically from WSS4J, when it asks for the keys.
Regards,
Andrei.
> -----Original Message-----
> From: martin [mailto:skumleren@gmail.com]
> Sent: Dienstag, 20. November 2012 09:22
> To: users@cxf.apache.org
> Subject: Expanding a webservice client to handle changing keys.
>
> Hello
> I am looking into introducing CXF as a viable alternative to the current
> webservice framework used at my workplace. For a case I am going to
> expand an old program of mine, but I need a little help to do so.
> Currently the client and service of my example have a couple of keys which
> they use to sign and encrypt the data between them. What I want to do is,
> using WS-SecurityPolicy, to make the service capable of handling several
> different keys using the “useReqSigCert” approach described in different
> tutorials.
> But here is the problem:
> The challenge here is that the encryption and signature keys for the clients
> will not be in a static location on the machines. They will be on USB keys or
> other movable storage which the user will carry with him, in order to be able
> to use any client on any machine he wishes.
>
> So how do I achieve this?
> As I see it there is one primary obstacle.
> Every example I have seen so far deals with a static key and a static password
> for said key. I will need to be able to specify where the key is, and what its
> password is, at runtime.
>
> Serverside, this setup seems easy enough, as there is no reason to have
> anything but static keys and passwords. But how do I handle the client?
>
> So my question is:
> How do I set up a WS-SecurityPolicy for a CXF client that supports a key and
> password for said key that changes from time to time?
> 1. I am guessing that using spring is not the optimal approach for this
> problem, and I will need to specify via the API as briefly discussed here
> http://cxf.apache.org/docs/ws-securitypolicy.html is this correct?
>
>
> On the same page: http://cxf.apache.org/docs/ws-securitypolicy.html
> I can see these properties:
> ws-security.signature.crypto A Crypto object to be used for signature. If
> this is not defined then "ws-security.signature.properties" is used instead.
> ws-security.encryption.crypto A Crypto object to be used for encryption. If
> this is not defined then "ws-security.encryption.properties" is used instead.
> 2. Does this mean that you can define a fully qualified Merlin object and
> deliver the reference to it directly to the framework?
>
> Lastly I can see these two properties.
> ws-security.signature.properties The Crypto property configuration to
> use
> for signature, if "ws-security.signature.crypto" is not set instead.
> ws-security.encryption.properties The Crypto property configuration to
> use
> for encryption, if "ws-security.encryption.crypto" is not set instead.
>
>
> 3. I would also very much like to know exactly which properties I need
> to
> set? I really can’t find anything but narrow examples in either the javadoc or
> on the site, and the merlin api is not much help either. Where do i find a list
> of what i need to specify in these properties?
>
>
>
> Thank you in advance.
> -Martin
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Expanding-
> a-webservice-client-to-handle-changing-keys-tp5718802.html
> Sent from the cxf-user mailing list archive at Nabble.com.