WebISO: Web Application Agent (WAA) Questionnaire AuthPortal Virginia Tech Prepared by Daniel Fisher, 2003-01-07 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 [X] Java Servlet [ ] Microsoft ISAPI [ ] Other [ ] Developer's API [X] C/C++ [X] Java/JSP [X] Perl [X] Python [X] Other - Any language that supports: SSL Network Connectivity XML Parsing 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): N/A 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 client library requires application developers to implement three functions; login, logout, and getUser. A user id that the applicaiton will understand is the argument for the first two functions. These functions are invoked by the authPortal server via XML messages sent to the client library via HTTP. 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? Translation of principal ids from the id a user logged in with to the id used by the destination system (if this information is know by authPortal). 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 is given the user's principal id for that specific application. This is presented in a signed XML message, the contents of which are accessible through API calls (that is the appliation programmer doesn't need to parse the XML, it's handled by the authPortal client lib). This id may be the same id as the user presented upon authentication or it may have been tranlsated by the authPortal into the id that this application expected for this user, if such a mapping is available to the authPortal server. 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? No. 3.2 Describe the means by which your WAA provides authentication information to your application. Please be as specific as possible. Information is provided in signed XML message. The application requests this information via the submission of a ticket that the user has (in the form of a cookie) to the authPortal server. This request is also done as a signed XML message. 4. Authentication Session 4.1 Briefly describe how authentication session information is maintained (if not already covered in section 2 above): The authPortal server maintains a list of applications the user has signed on to (via the authPortal framework). Entries timeout after a certain amount of inactivity which is tracked by an image that is loaded, from the authPortal server on the application side. It should be noted that the authPortal has the concept of security realms. Any number of applications which participate in the authPortal framework can be added into any number of security realms. User's can only access applications in security realms they meet the requirements for. For example Application A may be in Realm A and may require the user to have used a client cert as it's credential, while Application B in Realm B may only require a userid/password pair for authentication. AuthPortal can be set such that if the user uses an id/password pair to authenticate it won't be allowed to access App A. Hierachries can also be set up, such that Realm B may be setup to trust user's that meet another realm's requirements. That is Realm B stipulates those other Realms have requirements at least as stringent as it's and therefore user's who meet those other requirements are good enough for Realm B. 4.2 Is it possible to for an application to set the session duration? If not already covered above, please describe: Yes, session timeout and duration is totally the responsability of the application. The authPortal system is NOT a session manager in any way. 4.3 Is it possible to terminate authentication session globally? How is that information conveyed to the application? Yes, a user may initiate a global logout. When this happens the authPortal server sends out a logout message to each application the user is currently logged into which in turns causes the application's client library to destroy the user's session on that system. 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: Currently we use HTTP Post to post the credentials to the authPortal server, but other options are available as well. 5.2 Describe the protocol used by the WAA to handle the above (e.g. SAML POST Profile): N/A 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 ability to send additional information/user attributs to applications. 6.2 At a high level, what other changes would you like to see in your system? None, we are happy with our high level design.