Verifying Username and Password Credentials
The one thing we haven't discussed is how the authentication details are validated by the Web service. If you're using X509 certificates as the credentials, no checking is done by the Security input filter to validate the certificate you passed—another nail in the coffin of using X509 certificates for authentication!
If you're using username and password security credentials, once you receive a <wsse:UsernameToken >, you must verify that the username and password are correct. If you don't pass a password, no authentication check is made and the user is assumed to be authentic.
Toauthenticate the username and password combinations received at the Web service, you must provide an implementation of the IPasswordProvider interface—if you don't, any requests that contain username and password credentials will be rejected and an exception of type ConfigurationException will be thrown. The IPasswordProvider interface has one method,GetPassword , that accepts the username that is being authenticated and requires the password to be returned. WSE then accepts or rejects the security credentials by comparing the password that was received in the message to the password returned from the GetPassword method.
TheGetPassword method can be as complex or as simple as is required by the application. In our example Web service, we have only two valid user accounts and a simple switch /case statement that returns a hardcoded password:
public class authPassword : IPasswordProvider {
public string GetPassword(UsernameToken token) {
switch (token.Username) {
case "userl":
return ("passl"); case "user2":
return ("pass2"); default:
return (null);
We must inform the Security input filter of the details for our implementation of the IPasswordProvider interface. We do this in the configuration file:
<microsoft.web.services> <security>
<passwordProvider type="_15.authPassword, 15" /> </security> </microsoft.web.services>
Once we configure WSE to use our implementation of IPasswordProvider , all requests to the Web service that have username and password credentials attached will cause the authPassword class to be instantiated and the GetPassword method to be called.
Note As you've probably guessed, the GetPassword method presents us with a problem. We're most likely to store the passwords for a user in one-way encrypted form—be it in Active Directory, an SQL Server database, or any of a number of other locations. The GetPassword method must return the plain-text password so WSE can compare it to the password that is received. We have only one solution at present, and that is to store the passwords in plain text—this is possible in an SQL Server database but is generally not recommended.
Post a comment