Juan, It's been a while since I worked on WSS4J and I am not sure what's in there right now. As far as I know I dont think there is authorization stuff in there. The code has changed a lot recently and I am just following the changes from emails on the list. But you can just write a regular authorization handler that checks for authorization and throws a fault if authorization fails, no need to worry about having a callback.
Sanjesh -----Original Message----- From: Juan Cervera [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 27, 2005 11:53 AM To: Apache WSS4J-Dev Mailing List Subject: RE: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? Sanjesh, Maybe you are right, some of the points I've hinted to are more in the authorisation side than in the authentication. What worried me is that I can authenticate that a message is signed by a trusted client but no by which one of them. In some way, I guess that could be considered as authorisation too ... In fact if there would be an authorisation handler, as you suggest, this could be easily dealt with. But that handler should have a callback so we can implement our own authorisation code. Do you mean that such a handler does already exist or that is planned for future development? Thanks, Juan -----Original Message----- From: Sanjesh Pathak [mailto:[EMAIL PROTECTED] Sent: 27 September 2005 16:47 To: 'Apache WSS4J-Dev Mailing List' Subject: FW: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? 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] --------------------------------------------------------------------- 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]
