You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mark2008 <mh...@gmail.com> on 2008/11/27 14:50:46 UTC
WS-Security in Production Environment
I am looking at the online tutorials on how to use Encryption / Signature to
secure CXF web service.
The examples package the keystore / truststore into the web war file and
deploy to the some web container.
My question is, after the cxf/webservice application has been deployed to a
production environment, how do we import the client certificate and update
the truststore for any new client without shutting down the web server?
What's the best practice on this?
Thanks,
Mark
--
View this message in context: http://www.nabble.com/WS-Security-in-Production-Environment-tp20719606p20719606.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Security in Production Environment
Posted by ma...@pramati.com.
> If your clients are signing their requests, why not just use the
> public key you used to verify the signature on the request to encrypt
> the response? I can't see a need for SAML or WS-Trust in a scenario
> like this.
Hi Fred,
I can understand that if clients are signing (with KeyIdentifier as BST),
I can use that public key certificate to encrypt the response from the
server. I have modified and tested it too, it works well.
But, I feel we are constraining clients or request to have at least one
signature of some element/body. What about Signing in case of IssuerSerial
as Signature KeyIdentifier.
Also, this won't work if the response need to be secured (encrypted) not
the request or if both needs to encrypted only.
Any views/ideas of achieving this behavior will be appreciated.
With Regards,
Mayank
>
> On Nov 28, 2008, at 1:14 AM, Mayank Mishra <ma...@pramati.com> wrote:
>
>> Hi,
>>
>> I have a similar query for X.509 based cryptography. In the
>> development or testing environment, we can manually put client's X.
>> 509 public key into the server's truststore and server's X.509
>> public key into the client's truststore. Whereas, in the production,
>> we can safely assume putting server's public key into the client's
>> truststore, but not the otherway (making server trust on all client
>> who are going to communicate).
>>
>> Let's say if the response from the server requires to be encrypted.
>> Then server requires a X.509 public certificate of the client to
>> Encrypt the response. Assume, I have a service communicating to many
>> clients. I guess, it is not a right behavior for the server to put
>> all clients public certificates in the truststore. How the
>> configuration is expected to work in the production environment?
>>
>> Does WS-Trust provides a solution for this? I understand that SAML
>> Token is generally issued from the STS to client for claiming
>> authentication and authorization on the service. Also, I understand
>> that in WS-Trust a shared token "proof token" is send to both client
>> and server for securing request and response. But, can this be used
>> for exchanging X.509 public and private keys too.
>>
>> With Regards,
>> Mayank
>>
>> Mayank Mishra wrote:
>>> Hi,
>>>
>>> I agree with Glen to have keystore/Truststore outside the war.
>>> Usually containers comes with their own default keystore/
>>> truststore. For testing and development purposes, the keystore
>>> configurations are complete. However, for production environments,
>>> you may want to create a secure environment where ONLY your
>>> installations trust each other. WSS4J takes custom crypto
>>> configurations for Alias, Keystore location, TrustStore location,
>>> type of store using properties files.
>>>
>>> With Regards,
>>> Mayank
>>>
>>> Mark2008 wrote:
>>>> I am looking at the online tutorials on how to use Encryption /
>>>> Signature to
>>>> secure CXF web service.
>>>> The examples package the keystore / truststore into the web war
>>>> file and
>>>> deploy to the some web container.
>>>>
>>>> My question is, after the cxf/webservice application has been
>>>> deployed to a
>>>> production environment, how do we import the client certificate
>>>> and update
>>>> the truststore for any new client without shutting down the web
>>>> server?
>>>> What's the best practice on this?
>>>>
>>>> Thanks,
>>>>
>>>> Mark
>>>
>>
>
Re: WS-Security in Production Environment
Posted by Fred Dushin <fr...@dushin.net>.
If your clients are signing their requests, why not just use the
public key you used to verify the signature on the request to encrypt
the response? I can't see a need for SAML or WS-Trust in a scenario
like this.
On Nov 28, 2008, at 1:14 AM, Mayank Mishra <ma...@pramati.com> wrote:
> Hi,
>
> I have a similar query for X.509 based cryptography. In the
> development or testing environment, we can manually put client's X.
> 509 public key into the server's truststore and server's X.509
> public key into the client's truststore. Whereas, in the production,
> we can safely assume putting server's public key into the client's
> truststore, but not the otherway (making server trust on all client
> who are going to communicate).
>
> Let's say if the response from the server requires to be encrypted.
> Then server requires a X.509 public certificate of the client to
> Encrypt the response. Assume, I have a service communicating to many
> clients. I guess, it is not a right behavior for the server to put
> all clients public certificates in the truststore. How the
> configuration is expected to work in the production environment?
>
> Does WS-Trust provides a solution for this? I understand that SAML
> Token is generally issued from the STS to client for claiming
> authentication and authorization on the service. Also, I understand
> that in WS-Trust a shared token "proof token" is send to both client
> and server for securing request and response. But, can this be used
> for exchanging X.509 public and private keys too.
>
> With Regards,
> Mayank
>
> Mayank Mishra wrote:
>> Hi,
>>
>> I agree with Glen to have keystore/Truststore outside the war.
>> Usually containers comes with their own default keystore/
>> truststore. For testing and development purposes, the keystore
>> configurations are complete. However, for production environments,
>> you may want to create a secure environment where ONLY your
>> installations trust each other. WSS4J takes custom crypto
>> configurations for Alias, Keystore location, TrustStore location,
>> type of store using properties files.
>>
>> With Regards,
>> Mayank
>>
>> Mark2008 wrote:
>>> I am looking at the online tutorials on how to use Encryption /
>>> Signature to
>>> secure CXF web service.
>>> The examples package the keystore / truststore into the web war
>>> file and
>>> deploy to the some web container.
>>>
>>> My question is, after the cxf/webservice application has been
>>> deployed to a
>>> production environment, how do we import the client certificate
>>> and update
>>> the truststore for any new client without shutting down the web
>>> server?
>>> What's the best practice on this?
>>>
>>> Thanks,
>>>
>>> Mark
>>
>
Re: WS-Security in Production Environment
Posted by Mayank Mishra <ma...@pramati.com>.
Hi,
I have a similar query for X.509 based cryptography. In the development
or testing environment, we can manually put client's X.509 public key
into the server's truststore and server's X.509 public key into the
client's truststore. Whereas, in the production, we can safely assume
putting server's public key into the client's truststore, but not the
otherway (making server trust on all client who are going to communicate).
Let's say if the response from the server requires to be encrypted. Then
server requires a X.509 public certificate of the client to Encrypt the
response. Assume, I have a service communicating to many clients. I
guess, it is not a right behavior for the server to put all clients
public certificates in the truststore. How the configuration is expected
to work in the production environment?
Does WS-Trust provides a solution for this? I understand that SAML Token
is generally issued from the STS to client for claiming authentication
and authorization on the service. Also, I understand that in WS-Trust a
shared token "proof token" is send to both client and server for
securing request and response. But, can this be used for exchanging
X.509 public and private keys too.
With Regards,
Mayank
Mayank Mishra wrote:
> Hi,
>
> I agree with Glen to have keystore/Truststore outside the war. Usually
> containers comes with their own default keystore/truststore. For
> testing and development purposes, the keystore configurations are
> complete. However, for production environments, you may want to create
> a secure environment where ONLY your installations trust each other.
> WSS4J takes custom crypto configurations for Alias, Keystore location,
> TrustStore location, type of store using properties files.
>
> With Regards,
> Mayank
>
> Mark2008 wrote:
>> I am looking at the online tutorials on how to use Encryption /
>> Signature to
>> secure CXF web service.
>> The examples package the keystore / truststore into the web war file and
>> deploy to the some web container.
>>
>> My question is, after the cxf/webservice application has been
>> deployed to a
>> production environment, how do we import the client certificate and
>> update
>> the truststore for any new client without shutting down the web server?
>> What's the best practice on this?
>>
>> Thanks,
>>
>> Mark
>
Re: WS-Security in Production Environment
Posted by Mayank Mishra <ma...@pramati.com>.
Hi,
I agree with Glen to have keystore/Truststore outside the war. Usually
containers comes with their own default keystore/truststore. For testing
and development purposes, the keystore configurations are complete.
However, for production environments, you may want to create a secure
environment where ONLY your installations trust each other. WSS4J takes
custom crypto configurations for Alias, Keystore location, TrustStore
location, type of store using properties files.
With Regards,
Mayank
Mark2008 wrote:
> I am looking at the online tutorials on how to use Encryption / Signature to
> secure CXF web service.
>
> The examples package the keystore / truststore into the web war file and
> deploy to the some web container.
>
> My question is, after the cxf/webservice application has been deployed to a
> production environment, how do we import the client certificate and update
> the truststore for any new client without shutting down the web server?
> What's the best practice on this?
>
> Thanks,
>
> Mark
>
Re: WS-Security in Production Environment
Posted by Glen Mazza <gl...@gmail.com>.
I don't think you should be putting the keystore/truststore in the WAR file
(although my example[1] is apparently doing that, out of simplicity due to
multiple platforms--I should probably update that with a disclaimer). You
can hardcode your *.jks files to a location outside the WAR in the
clientKeystore.properties and serviceKeystore.properties files mentioned in
[1].
Glen
[1] http://www.jroller.com/gmazza/entry/implementing_ws_security_with_the
Mark2008 wrote:
>
> I am looking at the online tutorials on how to use Encryption / Signature
> to secure CXF web service.
>
> The examples package the keystore / truststore into the web war file and
> deploy to the some web container.
>
> My question is, after the cxf/webservice application has been deployed to
> a production environment, how do we import the client certificate and
> update the truststore for any new client without shutting down the web
> server? What's the best practice on this?
>
> Thanks,
>
> Mark
>
--
View this message in context: http://www.nabble.com/WS-Security-in-Production-Environment-tp20719606p20720159.html
Sent from the cxf-user mailing list archive at Nabble.com.