You may have read my previous articles on the VB2TheMax site where I described COM+ and the basics of Internetsecurity [1]. In the last article of this series I willdiscuss about implementing a secured Internet based application usingthe 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 CertificationAuthority. 
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 theSecure 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 communicationcan proceed protected as desired. 
Asymmetric encryption (based on certificates) is limited to the handshake phase onlybecause 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. TheoreticallySSL 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 awindows 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_ 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 acertificate. 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

  By default proprietary  IIS mapping is activated. You can switch to AD mapping just enabling the Windows Directory Service Mapper checkbox, as shown below (in this picture the checkbox is disabled because IIS is not registered in a Windows 2000 domain).

  

There are two kinds of AD mapping; UPN (Unique Principal Name) mapping and explicit mapping. 
The former is an implicit mapping done by Windows Security services when it finds a matching between the UPN field of the certificate (if present) and the UPN of a user (expressed in the form @) registered in the domain.
The latter must be defined explicitly on the Active Directory administrative snap-in. 
IIS proprietary  mapping involves more overheads if compared to AD mapping, but it offers more flexibility over the type of many to 1 mapping you can define (see figure below).

If you want to provide an Internet entry point to an application based on configured COM+ components, what you need is to set up proper IIS client authentication options so that each client identity flows transparently from IIS to the COM+ application. In this way the identity of the client is used when applying role based security (if not role based security would be pretty useless).
To do so you have three options:

• IIS Integrated security: as already said, this works for Intranet scenario only. 
  Note that if IE5 is used as client browser and IIS5 is running on a server registered in a W2K domain, you can hop the client identity to other servers (thank to the delegate impersonation level available when using Kerberos); if it’s not the case (e.g. the web server is IIS4 on Windows NT), you are forced to deploy COM components in an MTS package residing on the same server where IIS runs, otherwise the IIS process identity will be used when applying role based security.
• IIS Basic Security (requiring interactive or batch logon) over HTTPS: this works with any browser
• 1-to-1 client certificate mapping

The second option is the most widely used at present days, but expect secured solutions based on certificates getting more and more common in the future.

As you can see, IIS5 provides you different authentication options. I suggest you to find the one that best fits your application security requirements and use it, instead of implementing some custom security mechanism based on a proprietary user account database. A custom solution will likely be less robust and will augment the administrative burden required (nevertheless, I recognize that, if you host your application at an ASP site, this is unfortunately the only option you have).

[1] SecurityFor the Global Internet – vb2themax – Enrico Sabbadin
[2] Web Security part 2, MSDN magazine -June 2000, Keith Brown