> 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 <[EMAIL PROTECTED]> 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 >>> >> >
