WebISO: Web Application Agent (WAA) Questionnaire Cosign University of Michigan Prepared by Kevin McGowan, 2003-01-08 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 ( in development ) [+] Java Servlet ( in development ) [+] Microsoft ISAPI [ ] Other [ ] Developer's API [ ] C/C++ [ ] Java/JSP [ ] Perl [ ] Python [ ] Other Note: Applications are expected to be written to a standard environment ( CGI, J2EE, .NET, etc. ) as appropriate. As such, all WAA integration is managed within the authentication filter ( apache module, servlet filter, isapi filter ), making a developer's API innapropriate in this environment. 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): If the user-selected authentication module supports Kerberos 5 ( e.g. via a user name and password or with an X.509 certificate and KCT [ http://www.citi.umich.edu/projects/kerb_pki/ ], the credential may be stored on the WLS. Kerberos credentials may be retrieved from the WLS by permitted WAAs ( e.g. for our IMAP mail client, LDAP directory client, AFS file manager, password changing, and other applications ). The permission scheme is granular, e.g. the WAA hosting our AFS File Manager may only request afs@UMICH.EDU. 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? Authentication is initiated by the cosign authentication filter for a given CosignService. A CosignService can comprise a specific directory, location, or virtual host. 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? Preferably, authentication is initiated by the user ( by visiting the weblogin server ) prior to accessing any protected resources. The user dictates the technology used: Kerberos password, x509 certificate, guest account, etc. Protected applications are able to detect certain attributes of the initial authentication, e.g. whether the account is a guest account. Additionally, the WAA can be configured to retrieve proxy credentials if an application requires. 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? Authentication information ( username, realm, proxy credential information ) is provided to applications through server or environment variables, as appropriate. All cookies used in the system, including the service cookie identifier presented to the verification backend, are 128-byte random strings. 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. With the arguable exception of Kerberos credentials, Cosign is strictly an authentication system. Any authorization mechanism native to the WAA's host environment is supported, however ( e.g. mod_auth, mod_auth_ldap, etc. ). 3.1.3 Can additional information be delivered on request? Yes. A site can, if eligible, request Kerberos 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. REMOTE_USER username REMOTE_REALM ( if set ) KRB5CCNAME ( if using GSSAPI Credential Cache ) KRBTKFILE ( if using Kerberos 4 tickets ) Note that under ISAPI "REMOTE_USER" and "REMOTE_REALM" become "HTTP_REMOTE_USER" and "HTTP_REMOTE_REALM." 4. Authentication Session 4.1 Briefly describe how authentication session information is maintained (if not already covered in section 2 above): A cosign authentication session involves four main pieces: o user agent unmodified, no additional code, must be configured to accept cookies ( though domain cookies can be rejected as they are not used ). o weblogin ui The weblogin ui comprises the various login CGIs and the logout CGI. o cosignd Maintains authentication session state. Cosignd runs on each server in the WLS pool. o authentication filter ( WAA ) Runs on each web server participating in the SSO community represented by a given WLS. In a typical session, the user visits the weblogin server to authenticate. The weblogin server ui ( the user-selected login CGI ) generates and sets a 'cosign-login' cookie and presents the login screen. The user chooses to provide her login & password ( as opposed to an x509 certificate ) to authenticate herself via the weblogin ui. Assuming authentication is successful ( and the user has accepted the cosign-login cookie ), the CGI issues the LOGIN command to each available cosignd: LOGIN login_cookie ip princ realm kerberos This initiates the authentication session and the user is presented with what we call a service menu. The service menu is not part of cosign, per se, but lists the cosign-protected web sites the user may wish to visit after she has authenticated. In some cases, the service menu will never be displayed and the user will simply be redirected back to the WAA that referred her to login. When a user with an established cosign session visits a cosign-protected web server or application, the WAA on that server will check for the existence of a 'cosign-service' cookie -- a session cookie specific to that service ( a single web server can host multiple 'services' with a single WAA ). In this example the user has not yet visited this protected service ( the WAA finds no service cookie ) so the WAA generates and sets a service cookie and redirects the user back to the weblogin server with a url similar to: https://weblogin.umich.edu/?cosign-service=>=128RandomCharacters Note: the service cookie is a base64 encoded 128 byte number. These strings are generated using OpenSSL, and take the format: "cosign-=oFxNMqPjNuSraSYoO8i+lIqDA9ZrzU1J0Ca56uT+8*" The WLS checks if this user has a valid 'cosign-login' cookie set ( using the CHECK command to cosignd ). Since she does, in this case, the WLS will issue the REGISTER command to each available cosignd for this service cookie: REGISTER login_cookie ip service_cookie ( which associates the 'cosign-service' cookie with the 'cosign-login' cookie on each cosignd in the WLS pool ) and redirect the user back to the appropriate url on the WAA's web server. The appropriate url is either the original URL requested or, to help certain applications protect against XSS attacks, a pre-registered top-of-site url. This time, assuming she accepted the service cookie, the WAA is able to see its own service cookie and verify it with a cosignd using the CHECK command: CHECK service_cookie Which, in this case, verifies that the user is actively logged in and returns username and, if set, realm. The WAA is then responsible for caching this information as necessary ( typically long enough to complete a single request for a page and all of its associated content without having to CHECK the service cookie again ) and providing it to applications on its server ( see answers to 3.1.1 & 3.2 ). For more information, please see: http://www.umich.edu/~umweb/software/cosign/ 4.2 Is it possible to for an application to set the session duration? If not already covered above, please describe: No. All applications participating in the Cosign SSO community are available to properly authorized users for the duration of their SSO session. Allowing an individual application to dictate session duration for the entire SSO community does not make sense in our environment. 4.3 Is it possible to terminate authentication session globally? How is that information conveyed to the application? Yes. A user invokes the logout CGI on the weblogin service which expires and nulls-out the user's cosign cookie and informs all instances of cosignd of the change in status using the LOGOUT command: LOGOUT login_cookie ip Subsequent attempts by a WAA to 'verify' the user's cookie will result in a 'logged out' message. Additionally, it is possible for a user to implicitly logout by leaving her session idle for the "idle timeout" period configured in the WLS. 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: Each server in the pool of machines representing the WLS runs a daemon process ( cosignd ) to which individual WAAs maintain connections. All transactions are encrypted with SSL/TLS. The WLS daemons will only let hosts connect whose certificate subjects are listed in the WLS config file. This config file may contain wild cards, and governs which hosts can connect, which hosts are WAAs ( services ) and as such can issue the "CHECK and RETRIEVE" commands, which hosts are the login cgi and can issue "LOGIN, LOGOUT, REGISTER and CHECK," and which hosts are daemons and can replicate data. 5.2 Describe the protocol used by the WAA to handle the above (e.g. SAML POST Profile): The protocol used to communicate between the WAA and WLS is SMTP style, with numeric response codes. The WAA issues "CHECK " to get the users information. CHECK returns the following information: 2xx if the user is logged out ( either idle-logout or has chosen to logout ), CHECK returns 4xx. If the status of the user cannot be determined ( not in the database ) a 5xx is returned and a subsequent CHECK is issued to any other WLSes. RETRIEVE service-cookie TicketType If a service is authorized to retrieve any type of credentials, mod_cosign can issue the "RETRIEVE" command. The WAA ( mod_cosign ) issues "RETRIEVE ( e.g. ldap/ldap.itd.umich.edu@UMICH.EDU )" RETRIEVE returns the following information: 2xx Retrieving file number-of-bytes {number-of-bytes bytes} . as with CHECK, if the user is logged out ( either idle-out or has chosen to logout ), RETRIEVE returns 4xx. If the status of the user cannot be determined ( not in the database ) a 5xx is returned and a subsequent RETRIEVE is issued to any other WLSes. 6. Wish List 6.1 What changes or additions to the services provided by the WAA would you like to see in your system? None. 6.2 At a high level, what other changes would you like to see in your system? We will continue working to complete Java Servlet and Apache 2.0 authentication filters. -Kevin ... "drums, drums in the deep" ... On Tuesday, January 7, 2003, at 02:32 AM, Nathan Dors wrote: > > I've added responses from UC Davis, CSU, and MTU to > the website: > > http://middleware.internet2.edu/webiso/ > > I appreciate the volunteerism, and understand if > there are a few stragglers yet to come. > > -Nathan > > > -----------------------------------------------------------mace- > webiso-+ > For list utilities, archives, subscribe, unsubscribe, etc. please > visit the > ListProc web interface at > > http://archives.internet2.edu/ > > -----------------------------------------------------------mace- > webiso-- >