WebISO: Web Application Agent (WAA) Questionnaire WebAuth Stanford University Prepared by Roland Schemers, 2003-01-08 Note: this questionnaire is based on version 3 of the "WebAuth" system, which will be entering beta shortly. The current version in use is version 2.5. The spec for WebAuth V3 is available at: http://webauthv3.stanford.edu/webauth.html The terminology in the WebAuth V3 spec uses WAS (WebAuth-enable App Server) and WebKDC where this questionnaire uses WAA and WLS. -- 1. Model & Capabilities of the Web Authentication Agent (WAA) 1.1 Which high-level integration model(s) does your WAA support? [x] Server module [ ] Apache 1.3 [x] Apache 2.0 [ ] Java Servlet [ ] Microsoft ISAPI [ ] Other [x] Developer's API [x] C/C++ [ ] Java/JSP [x] Perl [ ] Python [ ] Other --- An Apache 1.3 module will also be provided if there is enough demand. We may also implement a PHP interface for implementing the login server, as well as Java APIs for implementing a Java WAA where Apache is not an option. --- 1.2 If applicable, describe the method(s) your WebISO solution provides for the WAA to handle N-tier (proxied, delegated) authentication. --- Normally, the WAA will request an "identity" token which will provide the authenticated identity of the user. If authorized, the WAA may instead request a "proxy" token, which it can then use to communicate with the WLS (via an HTTP/XML protocol) to request credentials on behalf of the user. For example, it may obtain Kerberos5 credentials for LDAP or mail access. The WLS maintains an ACL that describes which credentials a particular WAA is allowed to request using a "proxy" token. --- 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? --- Currently, all this work is done internally to the Apache 2.0 WebAuth module. The application developer just needs to configure Apache such that the AuthType is WebAuth, and have a Require directive. For example: AuthType WebAuth Require valid-user It is of course possible to use the low-level C/Perl API to do this directly from an application, but is expected most people will use the Apache module to do all the work for them. --- 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 WAA (i.e., Apache module) has a number of directives that control the authentication behavior. One, called WebAuthForceLogin, requires that the user always be prompted for their username/password (effectively bypassing single-sign-on) if the WAA redirects the user to the WLS. This would normally be used in conjunction with directives that enable inactivity timeouts. For example, if a "session" with a particular WAA hasn't been used with 5 minutes, the user could be forced to re-login. Another directive is "WebAuthSubjectAuthType". This controls the type of the "subject authenticator" returned by the WLS. The first type is "webkdc", in which the WLS returns the username (AES-encrypted) to the WAA. With this type, the WAA trusts that the WLS has already verified the user's identity. If the WLS is compromised, then the attacker can impersonate any user. The second type is "krb5". With this type, the subject authenticator returned is obtained by using the user's Kerberos5 credentials (on the WLS) along with the krb5_mk_req call. The WAA will then use its K5 keytab with krb5_rd_req to verify the user's identity. This benefit of this type of subject authenticator is that a compromised WLS can't impersonate any user, as they won't be able to forge the result of krb5_mk_req. The downside is the information returned in the URL is about 500 bytes longer (when including the base64 overhead) then when using "webkdc". --- 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 value of the username (REMOTE_USER and WEBAUTH_USER) is currently obtained using the result of krb5_aname_to_localname on the WLS (or locally by the WAA if the subject authenticator type is krb5). Though not yet pluggable, the code within the WLS that handles username/password is modular enough that other mechanisms (shadow, PAM, LDAP) could be used instead of Kerberos V5. See also 3.2. --- 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? --- Current plans are to have a separate module to enable this on the application side. This module will obtain information via LDAP, and cache it locally (most likely in an AES-encrypted cookie using the same mechanisms that the WAA uses). --- 3.1.3 Can additional information be delivered on request? --- currently the WLS is used only to convey the subject name and/or a special proxy-token which is used to obtain credentials on behalf of the user. --- 3.2 Describe the means by which your WAA provides authentication information to your application. Please be as specific as possible. --- The application gets most of its information via environment variables: REMOTE_USER=schemers AUTH_TYPE=WebAuth WEBAUTH_USER=schemers WEBAUTH_TOKEN_CREATION=103872393 WEBAUTH_TOKEN_EXPIRATION=1038759389 WEBAUTH_TOKEN_LASTUSED=103872393 The WEBAUTH_TOKEN_* variables are all maintained locally by the WAA. WEBAUTH_TOKEN_LASTUSED is only present if inactive expiration is enabled. If the WAA requests credentials, then an environment variable will be set that contains a path to the credentials. The application will be able to configure the path and under what circumstances the cached credentials get stored in a file (i.e., it doesn't make sense to create the credentials cache file on every single request). --- 4 Authentication Session 4.1 Briefly describe how authentication session information is maintained (if not already covered in section 2 above): --- the username, expiration time, creation time, and (if configured) the last-use-time are all maintained in a cookie that is encrypted using a 128-bit AES key known only to the WAA (or to a pool of WAA servers). --- 4.2 Is it possible to for an application to set the session duration? If not already covered above, please describe: --- Upon authentication, the application (via Apache directives), get to decide on how long the session is valid for. By default, the expiration time returned from the WLS will be used, and is normally tied to the epxiration of the underlying credentials (i.e., Kerberos TGT). The application can also request that a session times out if not used within a certain period of time. Note that session timeouts and lifetimes are only useful if the application also requests a "forced login", otherwise single-signon would just re-login the user. --- 4.3 Is it possible to terminate authentication session globally? How is that information conveyed to the application? --- no. each application may individually "logout" a user (only useful if "forced login" is also used). Tthe user may destroy their single-sign-on credentials via the WLS, but this will not log them out of any applications they have already visited. --- 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: 5.2 Describe the protocol used by the WAA to handle the above (e.g. SAML POST Profile): --- these are both described in the protocol spec: http://webauthv3.stanford.edu/webauth.html --- 6. Wish List 6.1 What changes or additions to the services provided by the WAA would you like to see in your system? --- Probably Windows support (which is possible using a proxy server, though not ideal). --- 6.2 At a high level, what other changes would you like to see in your system? --- Currently a lot of information is passed around between the WLS and WAA via URLs (see the spec), and the WLS is stateless (other then its own private key and ACLs, it maintains no keys or long term information). Some information is also kept in server-specific cookies (TGTS, credentials). It might be worth investigating a more stateful approach, where more session-based information (credentials, TGTs, etc) are stored on the WLS, and a unique session ID is used to gain access to that information. Such an approach would probably make it n-tier delegation a little easier, as well as global events like logging and logging out, etc. This of course has its own set of issues. ---