WebISO: Web Application Agent (WAA) Questionnaire

Campus-wide Login (CWL) system
University of British Columbia
Prepared by Bruce Jolliffe, 2003-01-08

Here is the University of British Columbia's response to the webiso survey
response for its Campus-wide Login (CWL) system.

1. Model & Capabilities of the Web Authentication Agent (WAA)
   1.1 Which high-level integration model(s) does your WAA support?
   [ ] Server module
       [ ] Apache 1.3
       [ ] Apache 2.0
       [ ] Java Servlet
       [ ] Microsoft ISAPI
       [ ] Other
   [x] Developer's API
       [x] C/C++
       [x] 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_delegatio
n-02.html):

Proxied credentials

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?

The API provides an "authenicate" call that takes a login name and password
and and a set of optional parameters including: ticket lifetime, request for
associated roles, request for identity keys, and requests for session
tickets. Identity keys are special roles indicating that your identity
relationship with the university such as student, faculty, and staff. The
call responds a response code and if succesful the login key for the login
name and a ticket granting ticket. If session tickets, roles, or identity
keys were requested they will also be returned.

There are a number of other calls that work with the returned TGT and can be
used to query for the optional parameters listed above if they were not
requested on the original call. There is also a verifyTicket call than can
be used by an application that is given a proxied credential to check the
ticket and optionally get back most of the parameters that could be returned
from an initial "authenticate" call.

Our authentication service separates the externally visible name used by the
user (login name) from the application handle for the user (login key).

Only applications that we have in our "good guys" list can are allowed to
use the authentication service.

   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?

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 application gets the login key, the indentity keys (which can be used to
look up more information on the user) and the user roles.

       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?

Our identity keys can be used to find out membership, studentid, etc.

       3.1.3 Can additional information be delivered on request?

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

Through the values passed by by the API calls.

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

Our ticket granting tickets and session tickets are used to maintain
session.

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

Yes, by requesting a non-default ticket lifetime.

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

Yes. There is an "invalidateTicket" call.

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:

The application opens a socket connection to the CWL service. The message
format currently used is XML based.

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

The protocol, as noted above consists of a request/respond XML frame over a
TCP socket wrapped in SSL.

We also provide a RADIUS and LDAP interface for authentication against the
same repository. We store more than on hash string for the users password
(crypt, MD5, and MD4NT). The MD4 variant is with our VPN service to allow us
verify RADIUS connections that use MSCHAP authentication such as microsoft's
clients.

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

We plan to add interfaces that use a "web services" RPC atop a SOAP/HTTPS
transport.

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

In addition to our client authentication interface we are planning to
release a management API that will allow authorized applications to manage
login/role/identity creating.