WebISO: Web Application Agent (WAA) Questionnaire

Distauth System
UC Davis
January 6, 2003

1. Model & Capabilities of the Web Authentication Agent (WAA)
    1.1 Which high-level integration model(s) does your WAA support?
    [X] Server module
        [X] Apache 1.3
        [X] Apache 2.0
        [ ] Java Servlet
        [X] Microsoft ISAPI
        [X] Other (NSAPI)
    [X] Developer's API
        [X] C/C++
        [ ] Java/JSP
        [X] Perl
        [ ] Python
        [ ] Other

    1.2 If applicable, describe the method(s) your
	 WebISO solution provides for the WAA to
          handle N-tier (proxied, delegated)
	 authentication (cf
http://middleware.internet2.edu/webiso/docs/draft-lajoie- 
trust_and_delegation-02.html):
We use proxy kerberos authentication to set a cookie in the user's  
browser and deposit a TGT on the authentication server. The ticket is  
then forwarded to an application server where it is used on behalf of  
the user when they make use of the application. (We run a kerberized  
imap php module that talks to kerberized imapd's.)

2. Authentication Request
    2.1 Describe the API your WAA provides to Web
        applications to initiate authentication.
        What functions can it invoke? What parameters
        can it pass?
We use basic http authentication. All we can use are username and  
password.

    2.2 Describe any other options your WAA provides
        to Web applications to influence the authentication
        process.  For example, can it request the
        technology or policy used to handle authentication?
None.

3. Authentication Delivery
    3.1 Describe the information delivered by your
        WAA to Web applications:

	 3.1.1 What user information is provided to the
           application? What is the format?  How does it
           relate to the identifier presented to the
           verification backend?
A cookie contains the authenticated username, a hash of the IP address  
from which the cookie was set and a hash of some stat information of a  
flag file set by the WAA in AFS space. The flag file also contains the  
client IP address.

        3.1.2 Does the WAA deliver additional user attributes
           (e.g., lookup key value associated with login
            identifier, studentid, group membership)? What is
            the format of this?
No.

        3.1.3 Can additional information be delivered on request?
No.

    3.2 Describe the means by which your WAA provides
        authentication information to your application.
        Please be as specific as possible.
The only information provided is username. This can then be  
authenticated using the hashed values in the cookie and the flag file  
in AFS space.

4 Authentication Session
   4.1 Briefly describe how authentication session
       information is maintained (if not already covered
       in section 2 above):
See above discussion of cookie.

   4.2 Is it possible to for an application to set the
       session duration?  If not already covered above,
       please describe:
Not directly. We are implementing a function that will force a  
reauthentication when a browser is sent to a specific URL. When this is  
implemented (in a couple of weeks), we will also set a time stamp in a  
separate cookie. An application will then be able to implement its own  
policy for reauthentication.

   4.3 Is it possible to terminate authentication session
       globally? How is that information conveyed to the
       application?
The method discussed in 4.2 will be global since the same cookie is  
presented to all applications.

5. Messaging (Weblogin Service (WLS) <-> WAA)
    5.1 Describe the message format used between your
        WAA and weblogin service to request and
        receive authentication information:
Basic http authentication.

    5.2 Describe the protocol used by the WAA to handle
        the above (e.g. SAML POST Profile):
See above.

6. Wish List
    6.1 What changes or additions to the services provided
        by the WAA would you like to see in your system?
Support for different methods of authentication that would be reflected  
in the resulting credential, along with authentication time. An  
application could then set its own policy with pretty fine granularity.

    6.2 At a high level, what other changes would you like to
        see in your system?


Submitted by: 
Tom Arons <tgarons@ucdavis.edu>