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]
