Basically, the way this is supposed to work (with wss4j right now, maybe changed in the future) is that WSS4J will verify the signature using whatever it finds in the keystore (or elsewhere).
After signature validation occurs, it then calls the verifyTrust method to make sure the cert that was used with that signature is one that is actually trusted for that message. Normally, we just check it with the trust store. However, you could do whatever you want. You could check if the cert belongs to user1 or not. Etc... Dan On Thu October 15 2009 6:21:25 pm cLaSic wrote: > Hi Daniel, > > Thank you for your response. > First of all i'll explain the scenario : > > -I got a cxf service using WS-Security. The server's truststore got some > trusted public keys (alias1, alias2, alias3 ...). > -Each client send a Soap request something like this (this request does not > contain the public key) : > > <Soap> > <Security>the WS-Security signature ...</Security> > <Body> > <user>user1</user> > </Body> > </Soap> > > -This request is signed using the client's private key. > -If the user=user1 then the server must verify the signature using only the > publi key (alias1) > -If the user=user2 then the server must verify the signature using only the > publi key (alias2) > ... > > -So the question is : where and how should i make this test and select the > apropriate public key for verification. > > -> I think that the verifyTrust Method is used only to verify if the cert > is in the server's Keystore and not to verify the request signature. > > Thanks for you help, > cLaSic > > dkulp wrote: > > On Tue October 13 2009 4:17:36 pm cLaSic wrote: > >> Yea i have already tried this but not working ! > > > > Define "not working". With that method, you are given the X509 cert > > that > > was used to sign the method and the reqeust data from which you can get > > the > > trust store and such (I think). From that, it's completely up to you to > > accept that cert or not. > > > > Dan > > > >> dkulp wrote: > >> > You probably need to subclass the WSS4JInInterceptor and override the > >> > method: > >> > > >> > protected boolean verifyTrust(X509Certificate cert, RequestData > >> > reqData) > >> > throws WSSecurityException > >> > > >> > > >> > Dan > >> > > >> > cLaSic wrote: > >> >> Hi, > >> >> > >> >> What if the Server got 3 public keys (alias1, alias2, alias3) and we > >> >> want to use only the second one to verify the signature! How can we > >> >> do this with CXF ? i beleive that we have to override something in > >> >> the IN interceptor. > >> >> > >> >> Regards, > >> >> cLaSic > >> >> > >> >> Mayank Mishra-3 wrote: > >> >>> Hi, > >> >>> > >> >>> One way of doing this is by specifying Alias name in trust store > >> >>> related assertions/configuration specified using the WS-Security > >> >>> Policy. You can specify this assertion at policy bound to > >> >>> Binding/Port/Service level. > >> >>> > >> >>> But since the scenario has different client each with its own > >> >>> private key, either you can use the BST signature key reference > >> >>> Identifier in which client sends the public certificate embedded in > >> >>> the secured message. > >> >>> or in the WS-SecurityPolicy, you can specify an KeyValueToken as a > >> >>> token type, then the Security engine would output an RSAKeyValue key > >> > >> in > >> > >> >>> the security header which is the public key certificate I guess. > >> >>> > >> >>> But in both cases, on the receiving side, we require to write a > >> >>> callback handler to extract, validate and reinsert the certificate > >> >>> in the context to use it. > >> >>> > >> >>> With Regards, > >> >>> Mayank > >> >>> > >> >>> cLaSic wrote: > >> >>>> Hi all, > >> >>>> > >> >>>> I have a general question about WS-Security : How the server select > >> > >> a > >> > >> >>>> certificat from the thruststore to authenticate the client > >> >>>> signature > >> > >> ? > >> > >> >>>> we > >> >>>> suppose that we have a lot of client, and each one has it's private > >> >>>> key, of > >> >>>> course the server has also each client public key. > >> >>>> > >> >>>> Regards, > >> >>>> cLaSic > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
