Authentication | Improving Web Application Security: Threats and Countermeasures

If your Web service outputs sensitive, restricted data or if it provides restricted services, it needs to authenticate callers . A number of authentication schemes are available and these can be broadly divided into three categories:

Platform level authentication
Message level authentication
Application level authentication

Platform Level Authentication

If you are in control of both endpoints and both endpoints are in the same or trusting domains, you can use Windows authentication to authenticate callers.

Basic Authentication

You can use IIS to configure your Web service's virtual directory for Basic authentication. With this approach, the consumer must configure the proxy and provide credentials in the form of a user name and password. The proxy then transmits them with each Web service request through that proxy. The credentials are transmitted in plaintext and therefore you should only use Basic authentication with SSL.

The following code fragment shows how a Web application can extract Basic authentication credentials supplied by an end user and then use those to invoke a downstream Web service configured for Basic authentication in IIS.

 // Retrieve client's credentials (available with Basic authentication) string pwd = Request.ServerVariables["AUTH_PASSWORD"]; string uid = Request.ServerVariables["AUTH_USER"]; // Set the credentials CredentialCache cache = new CredentialCache(); cache.Add( new Uri(proxy.Url), // Web service URL           "Basic",            new NetworkCredential(uid, pwd, domain) ); proxy.Credentials = cache;

Integrated Windows Authentication

You can use IIS to configure your Web service's virtual directory for Integrated Windows authentication, which results either in Kerberos or NTLM authentication depending on the client and server environment. The advantage of this approach in comparison to Basic authentication is that credentials are not sent over the network, which eliminates the network eavesdropping threat.

To call a Web service configured for Integrated Windows authentication, the consumer must explicitly configure the Credentials property on the proxy.

To flow the security context of the client's Windows security context (either from an impersonating thread token or process token) to a Web service you can set the Credentials property of the Web service proxy to CredentialCache . DefaultCredentials as follows .

 proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

You can also use an explicit set of credentials as follows:

 CredentialCache cache = new CredentialCache(); cache.Add( new Uri(proxy.Url), // Web service URL           "Negotiate",         // Kerberos or NTLM            new NetworkCredential(userName, password, domain)); proxy.Credentials = cache;

If you need to specify explicit credentials, do not hard code them or store them in plaintext. Encrypt account credentials by using DPAPI and store the encrypted data either in an <appSettings> element in Web.config or beneath a restricted registry key.

For more information about platform level authentication, see the "Web Services Security" section in "Microsoft patterns & practices Volume I, Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication " at http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp?frame=true .

Message Level Authentication

You can use WSE to implement a message level authentication solution that conforms to the emerging WS-Security standard. This approach allows you to pass authentication tokens in a standard way by using SOAP headers.

Note	When two parties agree to use WS-Security, the precise format of the authentication token must also be agreed upon.

The following types of authentication token can be used and are supported by WSE:

User name and password
Kerberos ticket
X.509 certificate
Custom token

User Name and Password

You can send user names and password credentials in the SOAP header. However, because these are sent in plaintext, this approach should only be used in conjunction with SSL due to the network eavesdropping threat. The credentials are sent as part of the <Security> element, in the SOAP header as follows.

 <wsse:Security          xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">   <wsse:UsernameToken>     <wsse:Username>Bob</wsse:Username>     <wsse:Password>YourStr0ngPassWord</wsse:Password>    </wsse:UsernameToken> </wsse:Security>

User Name and Password Digest

Instead of sending a plaintext password, you can send a password digest. The digest is a Base64-encoded SHA1 hash value of the UTF8-encoded password. However, unless this approach is used over a secure channel, the data can still be intercepted by attackers armed with network monitoring software and reused to gain authenticated access to your Web service. To help address this replay attack threat, a nonce and a creation timestamp can be combined with the digest.

User Name and Password Digest with Nonce and Timestamp

With this approach the digest is a SHA1 hash of a nonce value, a creation timestamp, and the password as follows.

 digest = SHA1(nonce + creation timestamp + password)

With this approach, the Web service must maintain a table of nonce values and reject any message that contains a duplicate nonce value. While the approach helps protect the password and offers a basis for preventing replay attacks, it suffers from clock synchronization issues between the consumer and provider when calculating an expiration time, and it does not prevent an attacker capturing a message, modifying the nonce value, and then replaying the message to the Web service. To address this threat, the message must be digitally signed. With the WSE, you can sign a message using a custom token or an X.509 certificate. This provides tamperproofing and authentication, based on a public, private key pair.

Kerberos Tickets

You can send a security token that contains a Kerberos ticket as follows.

 <wsse:Security          xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">   <wsse:BinarySecurityToken            ValueType="wsse:Kerberosv5ST"            EncodingType="wsse:Base64Binary">     U87GGH91TT ...   </wsse:BinarySecurityToken> </wsse:Security>

X.509 Certificates

You can also provide authentication by sending an X.509 certificate as an authentication token.

 <wsse:Security          xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">   <wsse:BinarySecurityToken           ValueType="wsse:X509v3"           EncodingType="wsse:Base64Binary">      Hg6GHjis1 ...     </wsse:BinarySecurityToken> </wsse:Security>

For more information about the above approaches, see the samples that ship with WSE.

Application Level Authentication

You can design and build your own custom authentication by using custom SOAP headers for your application. Before doing so, review the features provided by the platform and WSE to see if any of these features can be used. If you must use a custom authentication mechanism, and you need to use cryptography, then use standard encryption algorithms exposed by the System.Security.Cryptography namespace.