Juan, If I understand correctly what you are trying to do, then what you need is an authorization module. WSS4J handler is doing the authentication part, now you want to check for user authorization. The best way is to have an authorization handler which gets the user's certificate as explained by Werner and check for authorization based on the users certificate distinguished name or alias from keystore. Having a separate authorization handler would also be a cleaner approach (and this is what I believe is Werner's concern).
Sanjesh -----Original Message----- From: Dittmann, Werner [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 27, 2005 10:08 AM To: Juan Cervera; Apache WSS4J-Dev Mailing List Subject: AW: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? Juan, I'm not opposing on a callback to do this. We can introduce such a thing having an additional configuration parameter. On the other hand, your service has already access to the certificate used to sign. Just have a look into to FAQ, the WSResult structures, and possible into the interop implementation (Ping impl). See the code snippet: MessageContext msgContext = MessageContext.getCurrentContext(); Vector results = (Vector) msgContext.getProperty(WSHandlerConstants.RECV_RESULTS); log.trace("Potential number of usernames: " + results.size()); for (int i = 0; results != null && i < results.size(); i++) { WSHandlerResult hResult = (WSHandlerResult) results.get(i); Vector hResults = hResult.getResults(); for (int j = 0; j < hResults.size(); j++) { WSSecurityEngineResult eResult = (WSSecurityEngineResult) hResults.get(j); // An encryption or timestamp action does not have an associated principal // only Signature and UsernameToken actions return a principal if (eResult.getAction() != WSConstants.ENCR && eResult.getAction() != WSConstants.TS) { System.out.println("Principal's name: " + eResult.getPrincipal().getName()); } } } Now, instead of doing "eResult.getPrincipal()" do a "eResult.getCertificate()". The result structure holds a lot of information about the process request. This code actually runs in the your service called by Axis. The problem with callbacks is, that they do not have a direct connection or knowledge of the service that is being called at the end. This is because the callbacks run in the handler context. Could this be also a solution? Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Juan Cervera [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 27. September 2005 16:41 > An: Apache WSS4J-Dev Mailing List > Betreff: RE: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? > > > Werner, > > Let me explain you briefly the business logic I'm after and > then you can decide if it is worth it to add this to WSS4J. > > If I use the same keystore for several clients, the > signatures will just be accepted for any of them, as them all > will be trusted either because all the certs are signed by > the same CA root cert or because the keystore includes all > the individual certs. > > At that point WSS4J knows if the cert and signature are valid > but does not allow to check the details of the cert to > difference between different trusted clients. We may want to > verify those details, for several reasons, like being able to > authenticate that the signature really comes from the > expected client (or at least it will let us log that!), this > would open the door to extra filtering about which services > each customer can access. All using a single keystore. > > Regarding to the exact code you mention I'm not sure as I > have had not a chance to check it, but basically what I think > would be useful is, just after the certificate+signature have > been validated by the current code, allow the possibility > (optional) of calling a callback class which based on the > Subject's Distinguished Name details of the cert will still > be able to reject the message, the callback implementation > could do some other useful things, like extra logging and > bits like this. > > Now, I cannot guarantee that this is the best approach to > this issue and some people may argue that the certificate > validation is not the right place to do this (but taking into > account that we don't have access to the certificate details > afterwards I think it is). In any case this is not critical > for me as I still can "simulate" the same effect by having a > different keystores per service with just the certs for the > customers I want to access it, and/or deploying the same > service several times with different keystores if I want > extra control for different customers. Even though it is a > nightmare for maintenance. > > I'm open to comments though. > > Thanks, > Juan > > -----Original Message----- > From: Dittmann, Werner [mailto:[EMAIL PROTECTED] > Sent: 27 September 2005 14:35 > To: Juan Cervera; Apache WSS4J-Dev Mailing List > Subject: AW: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? > > Juan, > > at the receiver side the WSSecurityEngine (or Processor) > places the certificate used to create the Signature in the > result structure. There is some code in the handler that > performs some additional verification on the cert. > > You proposal is to replace that code and provide a callback > to get an easier way to add certificate checks? > > Regards, > Werner > > > > -----Ursprüngliche Nachricht----- > > Von: Juan Cervera [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 27. September 2005 15:16 > > An: Apache WSS4J-Dev Mailing List > > Betreff: RE: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? > > > > > > > > I think he may refer to what I already proposed some time ago. > > > > WSS4J does not have right now a way to verify the details of a > > signature certificate, it just knows if it is in the > keystore and if > > it is trusted. > > > > But it would be a good enhancement to create a new callback > to allow > > the user to code extra checkings on the certificate so they > can verify > > the Subject's Distinguished Name details (i.e. commonName, > > countryName, etc). I guess that would require those details being > > passed to the callback from Merlin from the certificate in the SOAP > > message. > > > > Juan > > > > -----Original Message----- > > From: Dittmann, Werner [mailto:[EMAIL PROTECTED] > > Sent: 27 September 2005 07:31 > > To: Richard Wareing; Apache WSS4J-Dev Mailing List > > Subject: AW: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? > > > > Richard, > > > > I'm not sure if I understand your proposal correctly. > > Couldn't that be done by extending/implementing another class that > > implements the Crypto interface? Classes that implement > this interface > > a Merlin and BouncyCastle in the **/components/crypto package. > > > > Regads, > > Werner > > > > > -----Ursprüngliche Nachricht----- > > > Von: Richard Wareing [mailto:[EMAIL PROTECTED] > > > Gesendet: Dienstag, 27. September 2005 00:01 > > > An: Apache WSS4J-Dev Mailing List > > > Betreff: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? > > > > > > > > > Are there any plans on implementing such a feature? It > > would be handy > > > to have in order to lookup a remote WS client's public > > "signature key" > > > instead of a grabbing it from a key store file. This would > > be similar > > > to what apparently can be done with encryption via the > > > ENC_CALLBACK_REF/ENC_CALLBACK_CLASS (see WSHandlerConstants > > API docs). > > > > > > Regards, > > > > > > Richard Wareing > > > Reimer Technology Group > > > > > > > > > --- > > > [This E-mail scanned for viruses by Declude Virus] > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
