WebISO: Web Application Agent (WAA) Questionnaire

Web AuthN/AuthZ system
Michigan Technological University
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
        [ ] Apache 2.0
        [ ] Java Servlet
        [ ] Microsoft ISAPI
        [ ] Other
    [x] Developer's API
        [x] C/C++
        [x] Java/JSP
        [x] Perl
        [ ] Python
        [x] 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_delegatio
n-02.html):

           Not Applicable


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?

Applications simply redirect to the authentication URL.  If authN is 
successful at the login site, a cookie is issued.  The cookie serves as 
the user's credential.  The authentication site then redirects the user 
back to the application he/she came from and the credential may or may 
not allow the user access depending on the application's authZ.

The module itself is a mildly patched auth_ldap that can be found at 
www.rudedog.org.


    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?


The cookie credential is a PEM encoded X.509 version 3 digital 
certificate.  I've added a few Michigan Tech specific extensions to 
provide the application with some minimal, central authZ information.


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?

The user information provided to the application is the userid/net ID, 
the user's distinguished name in the enterprise directory server, and an 
opaque, unique, numerical identifier we call a PIDM.

As mentioned earlier this information is contained in an X.509 version 3 
digital certificate extension.  Well, each piece of information is a 
separate extension so there are 3 extensions in the certificate.

The userid in the certificate is identical to the one necessary for 
authN and verification.


        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?

Not at this time.


    3.2 Describe the means by which your WAA provides
        authentication information to your application.
        Please be as specific as possible.

It provides all information in the form of a cookie which has a payload 
containing an X.509 version 3 digital certificate in PEM format.  All 
authN/authZ information is provided within the certificate.


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

The session is maintained based on the expiration of the digital 
certificate within the cookie.  The digital certificate will expire 
after 10 hours and the user must then reauthenticate.

The user must reauthenticate as well, after pressing the Logout button 
or exiting his/her browser.


    4.2 Is it possible to for an application to set the
        session duration?  If not already covered above,
        please describe:

No, but that's a good idea!


    4.3 Is it possible to terminate authentication session
        globally? How is that information conveyed to the
        application?

Since the cookie resides in the user's browser it is NOT possible to 
terminate the authN session at all.


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:

I guess my WAA and WLS are one in the same so there is no format 
betweent them.  Unless you consider an HTML post a format.

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

6. Wish List
    6.1 What changes or additions to the services provided
        by the WAA would you like to see in your system?

+ The N-tier capability would be nice.
+ More features, like session timeout, configurable by the application.
+ An arbitrary number of extensions for an arbitrary amount of authZ 
data to be passed in the credential.
+ The ability to terminate a user's session.

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


That's about it I guess.  Feel free to publish this on a web site or 
whatever.

Submittedy by:
Todd Piket <tcpiket@mtu.edu>