Security and Authentication with Web Connection

Topic: How do I Authenticate users through NT Security with IIS?

Authentication is the process of verifying users against the NT user database. IIS supports two mechansims for verifying user identity via the Web server:

Basic Authentication
This is an HTTP specific protocol that allows verification via an HTTP header that is sent back by the server and forces the browser to throw up an 'Authentication' dialog.
NT Passthrough Security
This type of security works through the NT file system access rights. Any rights assigned to a file are automatically passed on to the Web page that is being loaded. So if you restrict access to a particular page to only ADMIN users, IIS will request authentication before accessing that page. The user has to respond with a valid Admin user account and password to get onto the page.

Basic Authentication works only for dynamic requests while NT Passthrough works only on static files that are loaded from disk. It's important that Basic Authentication is a non-secure protocol that passes the password over the network when you log in. The password is encoded, but not in such a way that is easy to crack. However, Basic Authentication is the only way you can get authentication to work from a dynamic Web request.

Basic Authentication is disabled by default, so if your Web Connection application requires this feature you need to turn it on in the IIS service manager. Without this setting Basic Authentication will always fail as if the password was incorrect!

Here's how it works: If you're accessing the server that wants to make sure you are who you say, the request first sends a request for Authentication to your browser. The browser responds with the Login box into which you type your username and pass word and sends it back to the server. The server retrieves these and passes them on to your backend application as a server variable called Authenticated Username. This server variable is set only if the Authentication succeeded, otherwise it is not set. Once set, this user name stays with and is returned by your browser on each request for this particular virtual path on the Web server. So, once you've typed your password you can continue to check for the user name on each subsequent request and not force the user to type the password over and over again. If the user types an invalid password he won't get in and receives an error message.

In Web Connection the code looks like this:

*** Try to retrieve the username - strip off any domain prefixes with JustFname
lcUserName= JUSTFNAME( Request.GetAuthenticatedUser() )

IF EMPTY(lcUserName) && Any additional validations against password here...
   *** Not Validated - Send Password Dialog
   Response.HTMLAuthenticate(Request.GetServername())
   RETURN
ENDIF 

THIS.ErrorMsg("You've been validated for this request...",;
              "Your username is: " + lcUserName)

This code works by checking whether you are already authenticated first. If you aren't a call to HTMLAuthenticate() is made to force the browser to pop up the login dialog. The output from this method looks like this:

HTTP/1.0 401 Not Authorized
WWW-Authenticate: basic realm="localhost"

<HTML><h2>Gotta enter your password to get in!</h2></HTML>

Now the user types his username and password. If OK, this very same request is automatically re-run. lcUserName will contain the user's username and your code can continue to execute. If the authorization failed the HTMLAuthenticate is called again and not allow the user in until a valid password is typed and after 3 tries the Error message of the request is displayed.

Version 2.97 of Web Connection adds a new wwProcess::Login method which simplifies this process even more by wrapping this interface completely into a single method call. With 2.97 you can simply do:

LOCAL lcAllowedUser, lcUsername

*** Retrieve the user who's allowed to administer from wc.ini
lcAllowedUser = Request.GetWcIniValue("AdminAccount")

*** The following checks the authenticated user agains the passed

*** user. If not authenticated a password dialog is brought up
IF !THIS.Login(lcAllowedUser)
*** Password dialog will be popped up on the client
RETURN
ENDIF

THIS.StandardPage("...","...")

RETURN

What about SSL and Secure HTTP connections?

Above I told you that IIS passes passwords over the wire. As you might have gathered that's potentially dangerous as somebody could monitor your network traffic and pick out those passwords. It's not easy to do this since you need to figure out what constitutes a password first, but if someone is determined it can be done. The same applies to any content that you send over the wire, like credit card information and other sensitive info.

To avoid these problems there's SSL (Secure Socket Layer) that can encrypt the traffic between the browser and server. SSL uses private and public key encryption pairs to encrypt requests, which are nearly impossible to crack. Installation of SLL involves purchasing a Secure Server Certificate from a Certificate Authority (CA) such as Verisign. Certs are $250 a year. You install the certificate on your Web server using the Key Manager in IIS.

Using SSL in your requests is easy: All that really needs to happen is that the URL is changed from http:// to https://. That's it! Everything else works the same way as before including requests to Web Connection. In Web Connection you can test for a secure connection by checking the Server Port Server variable which you can retrieve with wwCGI::IsLinkSecure().

Note that encryption slows down requests significantly as each request communicates with the CA's server to verify the server and certificate. So, don't use it unless you have to. Good uses for SSL are to use it only on forms where sensitive information is passed - leave all other requests running without SSL. Also, to protect passwords it's a good idea to use Basic Authentication on password validation requests. I tend to set up requests to log in and then only check the password on subsequent links without forcing the user to login - if they're not logged in they can't access the link.