A client of mine is using WSE2 for authenticating rich clients over a
webservice, and for message signing. (They're using SSL for encryption and
server verification.)
They're using UsernameToken for passing credentials, with
PasswordOptions.SendNone, and of course a custom UsernameTokenManager for
supplying the authenticating password for verifying the message's digital
signature.

What I am trying to find, with little success, is a standard way to apply
the usual best practices for secure authentication, specifically regarding
failed logins.
Typically, I have my clients (according to well established best practices)
log failed authentication attempts to the audit system; temporarily block a
user's account after a certain number of consecutive failed authentication
attempts; and additional actions as a result of the logon process, including
logging succesful logons, logouts, etc.

Though I am relatively new to WSE, my understanding is that the custom code
can only supply the expected credentials to WSE for internal verification by
itself, but the custom code cannot get involved in the credential
verification process; rather, WSE will either allow the service to be called,
or will throw an Exception, if the credentials do not match (rather the
digital signature created by credentials does not match the one included in
the message).

How can custom code handle failed authentication events? By extension, how
do we prevent WSE from returning an information-rich Exception (i.e. password
is not correct, but you guessed a valid username) to the (potentially
malicious) client app?

I have come up with several possible alternatives, none of which seem great
- or even logical, since I would expect WSE to have builtin support for
functionality such as this. Anyway, what I have come up with so far:
1. Catching the OnLogonUserFailed event - this seems to not be relevant,
since we're using custom authentication with
UsernameTokenManager.AuthenticateToken being overridden (from the
documentation it seems that this only works with the default implementation
of UsernameTokenManager authenticating against a Windows user account);
2. Overriding the UsernameTokenManager.VerifyToken method - this too seems
to be not relevant, since the default implementation of VerifyToken is
required - or can I explicitly perform the validation some other way? Also,
calling base.VerifyToken in the override wouldn't help much, since we still
would have no way of knowing whether the user was verified or not... unless
we just wrap the call to base in a try/catch block, and handle it thru the
exception...?
3. Catching a webwide SecurityFault Exception, in global.asax - this is
obviously the least appropriate method, though it does seem to be the only
one assured to work... I prefer avoiding this.

So - any ideas/thoughts/relevant meanderings? Which is best? Am I wrong on
something here, or is there another way?

Thanks,