Re: Authentication in WSE
- From: "William Stacey [MVP]" <staceyw@xxxxxxxx>
- Date: Fri, 19 Aug 2005 10:15:04 -0400
I might even look at different method. I prefer SCTs over UTs anyway, so
use a SecurityContextToken instead. You control the creation of the SCT on
the server side and can use LogonUser api or custom DB login if you wish.
Then you can log to anything you want (i.e. DB, EventLog, etc) on the server
side. You can also return any error you want in the SCT reply or just throw
exception and let WSE handle it back. If using WSE, you probably need to
turn on Full Errors in the policy file otherwise you only get the Server not
available error. Not real sure how this will propagate back, so you have to
test and see. If you propagate the error yourself in the SCT reply message,
then you can code it anyway you like and have full control and
understanding. IMO, SCTs are more secure anyway and you also have the
option to use DerivedKeyTokens from the base SCT for even more security in
the conversation. I have a sample of doing this very thing at:
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry
Not this works with fw 1.1. I have a FX2.0 sample working, but need to
clean it up a bit and will post.
Possibly another option would be to encrypt the password with the server's
public key (embedded in your code or other), convert to base64, and send as
Send.PlainText in the UT. Using rsa PKI, the text will not be a simple pw
equivalent and WSE will handle replay attacks (so I think is pretty good
unless I missed something). Then you can decrypt pw (using server's rsa
private key) in your custom UTM and verify with LoginUser api and log as
needed. Return the same text pw in the method on logon success or exception
or null otherwise.
--
William Stacey [MVP]
"Avi Douglen" <AviDouglen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C06C0B5F-E593-466D-8F60-EA1BA1EF59EF@xxxxxxxxxxxxxxxx
>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,
>
> --
> Avi Douglen
> Application Security Consultant
>
.
- Follow-Ups:
- Re: Authentication in WSE
- From: Avi Douglen
- Re: Authentication in WSE
- References:
- Authentication in WSE
- From: Avi Douglen
- Authentication in WSE
- Prev by Date: Re: Authentication in WSE
- Next by Date: WSE 2.0 Kerberos Token retrieval Issue
- Previous by thread: Re: Authentication in WSE
- Next by thread: Re: Authentication in WSE
- Index(es):
Relevant Pages
|
