It sounds like what you want is HTTP DIGEST authentication, which supplies a client certificate outside the realm of SOAP. Or am I lost (again)? Have you looked into it? Doing so would not simply drop the connection, it would return a standard HTTP 401 (unauthorized), however...
Russ -----Original Message----- From: Robert Mecklenburg [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 4:43 PM To: [EMAIL PROTECTED] Subject: RE: Abort a axis handler chain RM> I want to implement a service that authenticates the caller (using a RM> certificate in the message). If the user is not authorized to invoke RM> the service, I want *no response* sent at all. No return value, no RM> exception, nothing. Is this possible? Anne Thomas Manes writes: ATM> If the service is defined as a request/response pattern, then I don't think ATM> that's possible. You should return a SOAP Fault, but you might consider ATM> sending back an HTTP error instead. Nelson Minar writes: NM> I agree with Anne, this is a somewhat unnatural thing to want to do. NM> The simple thing would be to simply return a SOAP Fault: the caller NM> would get a 500 error back with some basic data in the body. We are very concerned about security in our server. If a "bad guy" attacks our server we don't want: a) to reveal any information about the failed authentication, or b) to place any further burden on the underlying network. The response could contribute to a DoS attack, for instance. I'll investigate your suggestions (and Robert Lowe's), thank you. In the meantime, we came up with these two possibilities: 1. We could spawn a thread to process the soap message and pre-emptively terminate the thread in the event of an authentication failure. 2. Re-write the return address in the soap header to route the message into the bit bucket or to another soap client of our own choosing (which would dump the response in the bit bucket). Do either of these sound promising? Thanks, -- Robert