Technical Details

When a user of the web site encounters a protected directory, he is presented with the standard Basic Authentication prompt screen. Instead of an NT username/password, the user will enter the username/password that will be sent to RADIUS for authentication.

As this prompt is part of the Basic Authorization protocol, it is supported by all versions of the major browsers. This includes Netscape and MS Internet Explorer.

With RadIIS, IIS directories are still configured to use an NT username/password for access. This username/password is hidden from the user. It is assigned to requests only after successful RADIUS authentication from the RADIUS server. The user of the web pages has no access to this information. The username/password, as typed into the browser, are readily available via ASP.

RadIIS maps any number of username/passwords to a single NT username/password (just as all anonymous users are mapped to a single username/password). This dramatically reduces the CAL requirement for users authenticating through their browsers. The username, as typed into the browser, appears in the server logs for all items accessed. This information is also available via asp and/or scripts.

RadIIS is implemented as an ISAPI filter, which is loaded by IIS. The only other component required is a simple configuration file in the standard Windows .ini format. A basic, fully operational configuration can be achieved by the specification of as few as 6 items in this file. RadIIS was designed to be simple to install and configure.

 

A variety of additional features and facilities are available to the user. These include:

  • New with version 2.5: Support for cookie based session control. The server will re-query for stale username/passwords and allow for instant logout.
  • Username/password (as typed into the browser) are accessable from ASP pages. A section in the documentation illustrates both access and creation of cookies containing this information.
  • Specification of a secondary RADIUS server, for use when the primary gets congested or a failure occurs.
  • Protected directories may be specified as 'SSL only'. Even users with proper credentials are rejected unless they are accessing the directory via an SSL connection.
  • The ability to specify fields in the RADIUS authentication request packets.
  • Up to 10 separate directories (and their subdirectories) may be specified for RADIUS authentication on a single web site.
  • An attribute/value pair, to qualify authentications, may be specified on a per-directory basis.
  • Cache size may be specified.
  • Timeout can be specified for accessing either primary or secondary servers.
  • 3 levels of logging.
  • Since RadIIS is built on top of  IIS's Basic Authentication facilities, the user may specify custom error pages (HTML) to be posted to the user upon failure/rejection.

Customized Application

RadIIS has been customized to meet customer needs for novel/special application. Such customization has been done for nominal charge or even free. Prospective customers are encouraged to inquire about their special needs. Recent examples include:

  • A version that contains an external calling interface. This version allows application programs to use the ISAPI filter as an application level dll to query RADIUS.
  • Dual verification version. Used where simultaneous authorization by RADIUS and Windows is required.

Please proceed to the licensing page for details of how to obtain a free 15-day demo. Also, we can provide a free SSL test certificate.

Recent Revisions of RadIIS

2.50 Session support: High security cookie based sessions work in a manner similar to, but completely independent from, ASP sessions. A new encrypted cookie is generated every request. There is also a log-out mechanism.

2.51 Secure log: Sensitive information is no longer printed to the logs at startup at low (production) log level. Also, passwords are optionally not printed to the log on failed authentication requests. These facilities were added in colaboration with Sandia National Laboratories.

2.52 Cache upgrade: The cache mechanism has been enhanced. Cache entry timeout is now specified in minutes rather than hours. This makes RadIIS useful in 'one time' password applications. This option was worked out with our Canadian reseller (TH Consulting) and the staff a McGill University.

uudecode fix

The uudecode COM object has reportedly failed to work properly with certain versions of .NET. The following links provide asp/vbscript alternatives for decoding the uuencoded authorizaton header obtained via:

Request.ServerVariables("HTTP_AUTHORIZATION")

Note that the authorization header is sent in all subsequent http requests to the server after Basic authorizaton is obtained. It is this header that is decoded to provide AUTH_USER, and related server variables, in past versions of asp/asp.net. An authorization header, as returned by Request.ServerVariables, looks like:

Basic dGVzdF9icmFuY2g6cGFzc3dvcmQ.

The second string is the uuencoded username password with a ':' delimeter: username:password.

ASP decode: An asp script to decode this can be obtained at the following:

http://www.motobit.com/tips/detpg_Base64/

Microsoft published method: Microsoft published a scripting solution to decode this header to solve a related problem. Its Knowledge Base #835388:

http://support.microsoft.com/default.aspx?scid=kb;en-us;835388

2.53 New uudecode and ini file encryption: This release contains the uudecode fix discussed above. In addition, it supports file encryption of the ini file. The ini file contains sensitive information (NT username/password(s), Radius server location, Radius shared secret). This greatly simplifies installation since no special precautions are now necessary for directory access priveleges.