Re: Custom Authentication with WSE 2.0
From: Softwaremaker (msdn_at_removethis.softwaremaker.net)
Date: 06/09/04
- Next message: ByronKim: "Re: Implementing load balancing"
- Previous message: munjobbi: "Re: Custom Authentication with WSE 2.0"
- In reply to: munjobbi: "Re: Custom Authentication with WSE 2.0"
- Next in thread: Manuj Aggarwal: "Re: Custom Authentication with WSE 2.0"
- Reply: Manuj Aggarwal: "Re: Custom Authentication with WSE 2.0"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 9 Jun 2004 12:47:43 +0800
Hello,
Yes, I know exactly what you mean...
>From my point of view, there are a few options you can take and it depends
on how much control you have of the invoking client
1) Get the Client to hash the password before sending the password over. In
this case, employ the same HASH algorithm that you use to store the
passwords at the server DB AND send the password over using the
PasswordOption.SendPlainText.
In this case, WSE will pull the string [DigestValue] returned from the
AuthenticateToken method and compare it against the Hashed password
[DigestValue] that you are sending over the wire.
[I have not exactly tried this...so you got to experiment this yourself :)]
2) Encrypt the entire UsernameToken to send over. At your custom handler
a) Extract out the ClearText Password property
b) Hash the ClearText Password by employing the same HASH algorithm that
you use to store the passwords at the server DB
c) Compare option[b] with the [DigestValue] taken from the userDB
d) If it matches, return the ClearText Password for the
AuthenticateToken method
[Cheap and easiest way altho it doesnt scale and extend well]
3) SSL
4) You may have to look at some of the great extensibility that comes with
implementing your own usernameToken and see if it fits in the context
of the whole solution
Do let me know which helps the most.
-- Thank you very much Warmest Regards, Softwaremaker Architect | Evangelist | Consultant +++++++++++++++++++++++++++++++++ "munjobbi" <anonymous@discussions.microsoft.com> wrote in message news:756C8A6E-40A4-4B04-9D18-691A716F2875@microsoft.com... > That is exactally what I have. This is my understanding of the process. > > 1. The client constructs a UsernameToken object with a username and password (Hashed or not). > 2. The client adds the UsernameToken to the request context and makes a call to the wse'd web service. > 3. Based on the custom handler in web.config Wse instantiates the custom handler and calls the overridden AuthenticateToken method. > 4. The custom handler retrieves the password (or equivalent) from some store (SQL Server in my case) and returns the password (or equivalent) from the AuthenticateToken method. > 5. WSE performs some sort of password verification. > > Step 5 is where I am stuck. What I would like to do is perform the rest of the authentication and also have the ability to create a custom IPrincipal object that is defined by our system. Based on the way my passwords are stored (with corresponding salt values) there is no way that WSE will know how to perform the password matching. I could somehow use a different salt to encrypt the passwords (the username for example), so that way I can come up with the same hash on the client, but that seems to go against the best practices for storing passwords in a database. > > I hope this clarifies my problem. Any ideas? > >
- Next message: ByronKim: "Re: Implementing load balancing"
- Previous message: munjobbi: "Re: Custom Authentication with WSE 2.0"
- In reply to: munjobbi: "Re: Custom Authentication with WSE 2.0"
- Next in thread: Manuj Aggarwal: "Re: Custom Authentication with WSE 2.0"
- Reply: Manuj Aggarwal: "Re: Custom Authentication with WSE 2.0"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
