Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Implementing Secured Web Applications with IIS5

This article goes behind the basics, and describes what the X.509 protocol (IETF standard) is and how IIS implements it, how server certificates and the CRL (certificate revocation list) work, and many non-obvious details of IIS client authentication security options. Enrico also explains IIS mapping and AD mapping, and its two flavors: UPN mapping and explicit mapping. Finally, the article contains a discussion on flowing identity in COM+ based internet apps, including IIS integrated security, IIS Basic security, and 1-to-1 client certificate mapping.


advertisement

You may have read my previous articles on the VB2TheMax site where I described COM+ and the basics of Internet security [1]. In the last article of this series I will discuss about implementing a secured Internet based application using the security options provided by IIS5 to achieve:

  • Secured data transmission and integrity



  • Client and server authentication.

IIS Server authentication and data protection

The X.509 protocol (IETF standard) is the standard server authentication mechanism used over the Internet. IIS, of course, adheres to this standard. This protocol is based on certificates signed by a Certification Authority. 
When the client requires server authentication the web server passes its certificate to the browser. Server authentication will succeed if all the following steps will complete successfully:

  • The client computer trusts the certification authority that signed the provided certificates.
  • The client uses the Certification authority public key to open the certificate and then verifies that the common name within the certificate match the URL the browser is pointing to.
  • The client verifies that the certificate is not expired.

Eventually the browser may check the CRL (certificate revocation list), whose URL is contained within the certificate, to see if the certificate has been revoked before its expiry date.
If the client accepts the server certificate, then it will start the handshake phase of the Secure Sockets Layer (SSL) protocol to set up secured data transmission (the SSL -aka TLS- protocol is a private key algorithm based on a session key).
During the handshake phase the client sends a session key to the server encrypted using the server public key. Only the server can decrypt the session key knowing the corresponding private key.
When the server and the client have shared the session key securely, the communication can proceed protected as desired. 
Asymmetric encryption (based on certificates) is limited to the handshake phase only because symmetric algorithms (like SSL) are far more efficient in encrypting and decrypting data if compared to asymmetric ones.
Note that server authentication and data encryption are tightly coupled. Theoretically SSL can be used without server authentication, but in the real world this never happens since it's pretty useless to require data protection when you are possibly talking to a rogue server. 
The use of certificates and SSL in the way described above is commonly referred as the HTTPS protocol.

IIS client authentication security options

IIS client authentication is all about mapping identities that hit the web server via the HTTP protocol to an identity recognized within a windows domain. According to the IIS application security setting, the IIS thread serving the request will impersonate a particular identity, thus all access checks (file access, ASP scripts, etc) will be done against the thread identity, not the IIS process identity.
This identity will be used to apply access checks for:

  • File system access checks on NTFS drives when requesting HTML or ASP pages
  • Access checks required during the execution of ASP scripts (the identity flows transparently to the ASP execution context)
  • Activation and access checks for standard and configured COM+ components
  • Apply Role based security for configured COM+ components (use Server.CreateObject, not CreateObject or the process (IIS) identity will be used instead) 
  • Database access executed within the ASP script when connecting to SQL Server using Windows integrated security.

There are 5 possible security settings you can define for your IIS application to provide client authentication:

  • Anonymous: All requests are mapped to a single domain user. The default user is IUSR_<MACHINENAME> but you change it if you like.
  • Basic: When you request a resource (HTML or ASP page) residing in a virtual directory that requires Basic authentication, the browser prompts you for username and password. The thread that IIS picks up to fulfill the request tries to perform a logon into a domain defined in the virtual directory settings (not necessarily the one where the IIS server is registered in) using the information typed by the client. This security mechanism works with IE and Netscape but has a big drawback: the user password is sent in clear text. This issue is generally solved requiring HTTPS communication; in this way the whole communication, hence the password as well, is sent encrypted.
    The IIS thread can be configured to perform different logon types into the domain, that is, you can instruct IIS to call LogonUser with Interactive -the default-, Batch logon or Network logon. These settings cannot be configured using the IIS administrative snap-in; they are accessible only through the IIS ADSI. Programming interface. For further details see [2].
  • Digest (not available under IIS4): It's a new standard security protocol based on a challenge response mechanism. It's supported on IE5 and IIS5 only. Digest authentication is not so appealing because the Web Server must reside on the PDC to work.
  • Integrated (SPNEGO): This Microsoft proprietary authentication protocol performs a standard logon session over http (just like when you hit ALT+CTRL+DEL); you are asked for a username, a password AND a domain. The actual protocol used is negotiated between NTLM and Kerberos. Kerberos will be used if the browser is IE 5 running on a Windows 2000 computer and the web server is IIS5 running on a computer registered in a Windows 2000 domain. Integrated authentication is supported only in IE and doesn't work across proxies, hence it can be used only in Intranet scenario.
  • Client Certificate Mapping: a virtual directory is configured to run over a HTTPS connection, you can instruct IIS to require client authentication via client certificates. If you do so, when connecting to the virtual directory the user is prompted to provide a certificate. This certificates is mapped then by IIS to a domain account in a 1-to-1 or many-to-1 way. 
    There are two ways to setup certificate mapping: 
    • Proprietary IIS mapping
    • Active directory (AD) mapping


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date