Take a look at the contributed cold fusion downloads.

General Middleware Characteristics
We have tested the distributed authentication service with Cold Fusion 3.x on the NT. We expect other middleware applications that support the following chracteristics to be fully integratable with the distributed authentication service.

• In many cases, the middleware must be able to read a cgi-standard environmental variable called REMOTE_USER. This variable will contain the UCD LoginID of the authenticated user.
• The middleware may be called upon to handle authorization issues, and may use files such as the class-based UCDLoginID files in AFS space to help make these decisions. If the middleware needs to access the UCD LoginIDs associated with a particular class, then the web server must also be capable of running the AFS client software. Note that Macs and Windows 95/98 systems cannot run the AFS client software.
• The database security logic will affect the capability required by the middleware. If the database is accessible to anyone who has passed the Distributed Authentication Service authorization and authentication requirements, as implemented by the webmaster, then it is not necessary for the middleware to further evaluate the REMOTE_USER.

  If the database records contain authorization fields, then the REMOTE_USER variable must be evaluated by the middleware, and the pass-through option can be enabled so that the middleware has access to the REMOTE_USER variable even when this user did not pass the authentication step.

• If your .cfm or .dbm files are located in the restricted directory that you configure as part of the distributed authentication service, the distributed authentication module will be called ahead of the Cold Fusion module.

Cold Fusion and the Distributed Authentication Service (under development)
Since many members of the campus community use Cold Fusion as their middleware, we have studied how Cold Fusion and the distributed authentication service work together. In addition, for the NT platform running NT 4.0 and Cold Fusion 3.x, DCAS has conducted a series of timed trials.

There are a number of ways that Cold Fusion and the Distributed Authentication Service can work together, depending on the authentication and authorization requirements of the database. This flowchart shows how they interrelate. Here are a few common ways for them to interact:

• If all records in the underlying database are secured identically, the .cfm call can be placed in a restricted directory. The authentication and authorization required for database access can be managed within the distributed authentication cgi. In this case, the passthrough variable should not be set.

  Here are the details. When a browser requests the .cfm file in the restricted directory, the distributed authentication cgi will be invoked. Assuming the user's browser does not have a valid cookie, the local web server points the user's browser to the secure web server. The secure web server and Kerberos KDC negotiate the login process with the user. If the login is valid, the secure web server creates the AFS file and generates and sends the cookie to the browser. The local web server then redirects the browser to the restricted web page. Again, the local web server will check for a valid cookie and corresponding AFS file. If the cookie is authentic, the process passes to the middleware, and the content is generated and sent to the local web server, then displayed.

• Sometimes the records in the underlying database require authentication, but certain records are authorized for viewing by certain individuals or groups. In this case, the .cfm file can be placed in a restricted directory. The authentication can be performed by the distributed authentication cgi, and the authorization can be performed by Cold Fusion. The passthrough variable is not set in this case since all users are required to authenticate.

  Here are the details. When a browser requests the .cfm file in the restricted directory, the distributed authentication cgi will be invoked. Assuming the user's browser does not have a valid cookie, the local web server points the user's browser to the secure web server. The secure web server and Kerberos KDC negotiate the login process with the user. If the login is valid, the secure web server creates the AFS file and generates and sends the cookie to the browser. The local web server then redirects the browser to the restricted web page. Again, the local web server will check for a valid cookie and corresponding AFS file. If the cookie is authentic, the REMOTE_USER variable is set to the user's UCD LoginID, and the process passes to the Cold Fusion. Cold Fusion reads the REMOTE_USER variable, and determines whether the user is authorized to access the record that has been requested. If so, the content is generated and sent to the local web server, then displayed.

• In other cases, there are database records that are available without restriction or authentication (guest access). This same database may contain records that do require authentication and possibly authorization. When a database contains this mix of authentication and authorization, the .cfm file can be placed in a standard, unrestricted directory. The passthrough variable should be set in this case. When the .cfm file is accessed, the middleware determines whether authentication or further authorization is required. If authentication is required, the middleware can call the distributed authentication cgi.

  Here are the details. When the .cfm file is accessed, Cold Fusion determines whether authentication or further authorization is required. For records requiring only guest access, the content can be generated by Cold Fusion, then displayed. If the requested records require authentication, Cold Fusion can first evaluate the REMOTE_USER variable. If this variable is not set to a valid UCDLoginID, Cold Fusion can call the distributed authentication cgi. If Cold Fusion determines that the returned REMOTE_USER variable is valid, it can use this information to then determine if further authorization is required, and complete that authorization step. Next, the content can be generated and displayed. If Cold Fusion determins that the returned REMOTE_USER variable is invalid, it can generate an error notification.

• Lastly, if part of a web site is to restricted to the members of a particular UCD class, the middleware (rather than the distributed authentication cgi) can read the corresponding file of UCDLoginIDs. For example, if part of the records in the previous database require authorization against a particular classlist, Cold Fusion can compare the REMOTE_USER variable with the classlist.