FOUND IT!
I had already debugged and the exception was being thrown properly. The
problem was that our client was encrypting and sending the message, and if
it got a security failure due to an expired session, it would get a new
session, copy the body of the original message into a new envelope and send
that one encrypted. Unfortunately, we were copying the body after it was
encrypted, so on the server when we got an encrypted body we assumed the
pipeline had not processed it.
Thanks for the help.
-EP
[quoted text, click to view] "William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:e2PZV25iFHA.3340@TK2MSFTNGP10.phx.gbl...
> I would enable breaking on all exceptions and try to step through the
server
> side in a debug session.
>
> --
> William Stacey [MVP]
>
> "ep" <reply@newgroup.only.please> wrote in message
> news:OXvbeh5iFHA.3568@tk2msftngp13.phx.gbl...
> >I have a server application which has been using WSE 2.0 and custom
> >security
> > tokens. We needed to change one of the asmx webservices to a
SoapService.
> > Now when the incoming security token is invalid, our
SecurityTokenManager
> > correctly throws an exception. The problem is that this exception is
> > ignored, and the soapservice gets a soapenvelope with encrypted data,
> > which
> > it can't understand. Further, the fault thrown back is based on invalid
> > data (encrypted) being received at the soapservice, instead of the
proper
> > security fault which would allow re-establishing a session.
> >
> > So, why are my security exceptions ignored? How can I get the pipeline
to
> > properly throw my fault?
> >
> >
>
>