Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by WernerDittmann: http://wiki.apache.org/ws/FrontPage/WsFx/wss4jFAQ ------------------------------------------------------------------------------ 1. [#noalgo No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-1_5 or similar] 1. [#npe Spurious Null Pointer Exception] 1. [#debug Where can I change the debug level of wss4j?] - 1. [#many I have many clients and one service (and i need signature+encryption). Is there a way to handle many client certs?] + 1. [#many I have many clients and one service (and I need signature+encryption). Is there a way to handle many client certs?] 1. [#username How do i extract user's name or certificate info from my web service?] + 1. [#time Timestamp handling in WSS4J] [[Anchor(isWSS4J)]] @@ -105, +106 @@ [http://logging.apache.org/ Apache logging] project. [[Anchor(many)]] - ==== I have many clients and one service (and i need signature+encryption). Is there a way to handle many client certs? ==== + ==== I have many clients and one service (and I need signature+encryption). Is there a way to handle many client certs? ==== - Each client has its own certificate, the requests shall be signed and encrypted. The responses also signed and encrypted. + Each client has its own certificate, the requests shall be signed and encrypted. The responses also signed and + encrypted. - Well, to keep the effort of the certificate adminsitration low I usually use the following technique. Using this way no special programming on the client or service is required, all handled via standard deployment. + Well, to keep the effort of the certificate adminsitration low I usually use the following technique. Using this + way no special programming on the client or service is required, all handled via standard deployment. Client part, request: - - set up the client to use Binary Security Token (BST) when signing: + * set up the client to use Binary Security Token (BST) when signing: - {{{ + {{{ - <parameter name="signatureKeyIdentifier" value="DirectReference" /> + <parameter name="signatureKeyIdentifier" value="DirectReference" /> - }}} + }}} - In this way the request contains the client's certificate, i.e. its public key. Because the certificate is included in the request the server does not need to store the certificate of every client. + In this way the request contains the client's certificate, i.e. its public key. Because the certificate is + included in the request the server does not need to store the certificate of every client. - - Use the server's certificate (the public key) to perform request encryption. + * Use the server's certificate (the public key) to perform request encryption. Server part, request: - - The handler (WSDoAllReceiver/WSSecurityEngine)) extracts the client's certificate from the request (because it's a Binary Security Token). Use this certificate to verfiy and perform trust verification agains the root certificate (certificate of the Certificate Authority, CA). The current verifyTrust implemetation requires to have all client certificates in the keystore to provide a better security/trust check against phony DNs and possible other mismatches. + * The handler (WSDo``All``Receiver/WSSecurity``Engine)) extracts the client's certificate from the request + (because it's a Binary Security Token). Use this certificate to verfiy and perform trust verification agains + the root certificate (certificate of the Certificate Authority, CA). The current verifyTrust implemetation + requires to have all client certificates in the keystore to provide a better security/trust check against + phony DNs and possible other mismatches. - - the handler stores the extracted client certificate in the message context. This is transparent to the client and server code. + * the handler stores the extracted client certificate in the message context. This is transparent to the client + and server code. Server part, response: + * To perform signing the server uses its private key to sign. You may use BST or some other way to identify the + server's certificate. Every client needs to have the server's certificate anyway if you encrypt the request (see + above). - - To perform signing the server uses its private key to sign. You may use BST or some other way to identify the server's certificate. Every client needs to have the server's certificate anyway if you encrypt the request (see above). - - - To perform response encryption set the encryption user name to "useReqSigCert". This is a special name that directs the WSDoAllSender handler to use the stored client's certificate (the clients public key) to perform response encryption. + * To perform response encryption set the encryption user name to "useReqSigCert". This is a special name + that directs the WSDo``All``Sender handler to use the stored client's certificate (the clients public + key) to perform response encryption. Client part, response: - - nothing special, just set up the response stream correctly in the client's WSDD file. + * nothing special, just set up the response stream correctly in the client's WSDD file. - As pointed out, usually no modification in client/service coding necessary, also no need to change the trust handling inside WSDoAllReceiver except that you need a very special certificate trust verification. + As pointed out, usually no modification in client/service coding is necessary, also no need to change the + trust handling inside WSDo``All``Receiver except that you need a very special certificate trust verification. [[Anchor(username)]] ==== How do i extract user's name or certificate info from my web service? ==== @@ -160, +173 @@ } }}} + [[Anchor(time)]] + ==== Timestamp handling in WSS4J ==== + WSS4J supports several time features and options. If you just use the + action {{{Timestamp}}} without any further configuration WSS4J uses the + following defaults: + * All timestaps use millisecond precision + * The default time difference between {{{Created}}} and {{{Expires}}} is set + to 300 seconds (5 minutes). + Use the following handler parameters to change these settings: + * {{{timeToLive}}} to specify another time difference between + {{{Created}}} and {{{Expires}}}. The value of this parameter is an + integer that defines the time difference in seconds. + * {{{precisionInMilliseconds}}} to switch off the millisecond time + precision. Set the value to {{{false}}} or {{{0}}} to generate + timestamps without milliseconds. + WSS4J uses the ''UTC'' timezone (''zulu time'') to generate + timestamps. This is according to the WSS specifications. + + At the receiving end WSS4J checks if the request is still valid (is + not expired). This is done in two steps: + * In the first step the WSSecurity``Engine (WSS4J 1.x.y) or the + Timestamp``Processor (since WSS4J 2.x.x) checks the {{{Expires}}} + timestanp against the server's current time. + * In the second step the WSS4J handler, either {{{WSDoAllReceiver}}} + or {{{WSS4JHandler}}}, performs a check based on server + information. The server computes a valid creation time by subtraction + the time-to-live from the current time at the server and checks the + {{{Created}}} time aginst this computed value. The default + time-to-live value is 300 seconds. You may specify a {{{timeToLive}}} + parameter in the handler's request path at the server to define + another value for the time difference. +
