WebISO: Web Application Agent (WAA) Questionnaire eIdentity Web Authentication Colorado State University January 6, 2002 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 [ ] Apache 2.0 [ ] Java Servlet [ ] Microsoft ISAPI [x] Other (Microsoft IIS and ColdFusion 5.0) [x] Developer's API [x] C/C++ [x] Java/JSP [x] Perl [?] Python [x] Other (ColdFusion, ASP) 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_deleg atio 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? Web applications develop their own login page look and feel but use an HTTP GET request to embed an eIdentity login form on their web page. Any developer API that supports HTTP GET requests can be used. Tokens are used on both ends to verify 1) the web site that is calling the login page is authorized to do so and 2) the response sent back from the authentication web site did indeed come from there. Only one function, embed login form, is supported. Parameters can be sent to determine how the login form will be displayed on the page including it's justification (left, right or centered), which type of login form (Colorado State supports eIdentity and/or PID/PAC logins), and how the 'Submit' button looks. The only required parameter is a URL that the authentication information should be sent to once complete. 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? No other options are available. The application MUST come from and return to an SSL encrypted page or an error is generated. 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 following information is returned from eIdentity web authentication: - A token that was originally passed to the eIdentity web authentication system by the calling page. The token should be checked against the original value sent to prevent spoofing. - A Yes/No value indicating if the authentication attempt was valid. - The eName (network ID) of the individual if they successfully authenticated. - The eIdentity internal reference ID of the individual. The eIDIRID is the unique numeric identifier for an eIdentity. - The student system internal reference ID. - The human resource system internal reference ID. - The associates database internal reference ID (Colorado State's database for handling all individuals associated with the University but that cannot be added to either the student or human resource systems). - A value indicating if the authenticating account is a primary or secondary eIdentity. Every person at Colorado State must have one and only one primary eIdentity. Individuals may have as many secondary eIdentities as needed. - A Yes/No value indicating if any errors occurred. - A detailed error message describing the exact error that occurred. In most cases, developers simply display this error message to the user if an error occurred. - An error number. Each error type has it's own unique number that can be trapped by the developer to display a custom error message. 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? Yes. The additional information that is passed is detailed in 3.1.1. Unique reference numbers are passed for all major information systems. Additional information (name, address, title, etc.) will not be passed. Developers are expected to utilize the unique identifiers and look up any additional data required from either databases or LDAP. 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 current implementation submits information back to the originating application using a standard web form post. All returned elements are generated as an HTML form with hidden inputs. The form is then automatically submitted back to the originating application using a JavaScript document.form.submit() command. Currently, applications must check for a returned token and check the http_referer to prevent spoofing. There are plans for redesigning the way eIdentity web authentication passes back information to increase security. 4. Authentication Session 4.1 Briefly describe how authentication session information is maintained (if not already covered in section 2 above): eIdentity web authentication does not currently maintain session state. Applications independently handle all of their own session state. 4.2 Is it possible to for an application to set the session duration? If not already covered above, please describe: Yes in the sense that each application manages it's own session state. No in the sense that there is some global session state for the authentication. 4.3 Is it possible to terminate authentication session globally? How is that information conveyed to the application? No. 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: User credentials are encrypted and stored in an Oracle database. The WAA uses ODBC to connect to and receive the credentials. The credentials are decrypted, compared to what the user entered, and the results are sent back to the application. 5.2 Describe the protocol used by the WAA to handle the above (e.g. SAML POST Profile): ODBC calls to a database. 6. Wish List 6.1 What changes or additions to the services provided by the WAA would you like to see in your system? A new version of eIdentity web authentication is planned for Summer '03 to support the following: - Greater security: + Better identification of the site that requests the authentication + Passing the information back without using a JavaScript submit so the applications token is never revealed to the end user - Additional display options: + The login form is currently rather large. A small version of the form will be created as an option for applications that want/need to embed the login form in tight places - SSO between sites that opt in: + Applications will be able to 'opt in' to single-sign-on between sites. Each application will be able to select which other SSO enabled applications they are willing to accept authentication from and how long a session can remain valid. The eIdentity web authentication system will make the determination for the application and send either a valid authentication, if the SSO criteria are met, or send a login form if the applications SSO criteria have not been met. + Applications will send eIdentity web authentication a continuous 'keep-alive' to allow session length information to be determined and passed to other sites participating in SSO. 6.2 At a high level, what other changes would you like to see in your system? Ideally, I would much rather NOT support eIdentity web authentication at all. I hope the MACE WebISO team is able to find and recommend a WebISO standard that meets our needs. Additional details about eIdentity Web Authentication can be found at: http://www.colostate.edu/Services/acns/eid/eIDWebAuthV1.0.doc Submitted by: Eric Galyon Colorado State University Academic Computing and Networking Services etg@colostate.edu