WebISO: Web Application Agent (WAA) Questionaire A-Select Authentication System SURFnet, Netherlands http://a-select.surfnet.nl December 4, 2002 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 [*] Developer's API [ ] C/C++ [ ] Java/JSP [ ] Perl [ ] Python [*] Other, socket based 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_delegation-02.html): A-Select is based on a single user-id concept. This user-id is available to all applications that use A-Select. With this, N-tier applications may "become" the user to their likening. This also means that non-A-Select applications at tier N can get information about the user from A-Select aware applications at tier N-1. Generally, in a pure A-Select environment, the ticketing mechanism of A-Select provides an SSO environment where A-Select front-ends to tier-applications are run. A-Select also provides cross-organizational features, where users are authenticated by their own organization when they wish to access another organization's applications as guests. The A-Select Server of the originating organization is one tier in such an environment. Note: A-Select uses a single user-id for identifying an authenticated user. When actually authenticating a user, another user-id may be used. For example, if the user is authenticated using RADIUS, a radius user name (e.g. user@realm) may be used as part of the identifying information when authenticating the user with the back-end RADIUS server. 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? A-Select offers an API for applications that is implemented by the A-Select Agent. The A-Select Agent handles API calls with the A-Select Server. The A-Select Agent also generates tickets that applications can use to implement their application tickets. Applications can use this socket based CGI-syntaxed API directly. Applications may also be integrated with the higher level integration components for a Web server. In that case there is no real API. Applications will get information about the user *after* authentication. Authentication is initiated by an application when it gets a request that does not contain user credentials (an A-Select application ticket). There are two authentication initiation functions (i.e., requests). The application will send a request=authenticate message to the A-Select Agent when it wishes to initiate authentication of a local user. It will send a request=cross_authenticate request when it initiates authentication of a user from another organization. The A-Select Agent will on its turn initiate authentication with the A-Select Server. If initiation is successful (i.e., the A-Select Server is willing to honour the request), the A-Select Agent will reply to the application the URL of the A-Select Server. The application must redirect the user to that URL to let the user enter the authentication process with the A-Select Server. The parameters for the request=authenticate are as follows: request=authenticate& \ app_url=& \ app_id= specifies the full url to the application. When the A-Select Server has finished authentication of the user, he will redirect the user back to the application at this URL. is an id that uniquely identifies the application. This id is registered with the A-Select Server. The A-Select Agent will return with the following reply (on success): rid=& \ as_url=& \ result_code=0000 specifies a request id for this authentication initiation. specifies the URL of the A-Select Server. The application should redirect the user to this URL to start the authentication process. result_code=0000 specifies success, other values specify errors. For Cross Organization A-Select, the request is as follows: request=cross_authenticate& \ remote_inst=& \ app_url=& \ app_id= In addittion to the authenticate request, is now a parameter that identifies the organization that the user belongs to. This is registered with the A-Select Server. The application provides this information, so it will probably get it from the user from a form interaction where the user can select which organization he belongs to. 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? Applications can kill tickets with the A-Select Agent (useful for applications that implement their own authorization and log out purposes). Addittionally, they can kill ticket granting tickets with the A-Select Server, usefull for scope-wide log out. A note on cross organizational A-Select: When an organization wishes to authenticate a user from another organization, the A-Select Server of the requesting organization will supply a "required authentication level" to the originating organization's A-Select Server. 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? Applications that use the A-Select Agent directly, get the following information after the user is authenticated. rid=& \ ticket=& \ ticket_start_time=& \ ticket_expiration_time=&uid=& \ uid=& \ inst_id=& \ tgt=& \ authentication_level=& \ authentication_service_provider=& \ result_code=0000 is the request identifier generated earlier by the A-Select Server. is the application ticket that the WAA has generated. The application must use this ticket to set it as a cookie in the user's browser. Each subsequent request from the user's browser will contain this ticket. The ticket should be verified with each request with the A-Select Agent (the A-Select Agent manages the validity of the ticket). Summarizing, the ticket is the credential that user uses to use the authenticated session to get access to the application. is the UTC time when the ticket was generated. is the UTC time when the ticket expires. is the user id of the user that the user has been authenticated with. is the identifier that identifies the organization that user belongs to. is the ticket granting ticket that the A-Select Server has issued to this user. This is for informational purposes only. is the level of authentication ("strength") that the user was authenticated with. This level is defined by the A-Select system. is information about the authentication service provider that authenticated the user. Applications that are integrated with a high level integration module, get information stored in a non-persistent browser cookie: aselect-ticket: aselect-uid: aselect-inst_id: This information is the same respective information as above. Note that, the is the A-Select user-id and is not necessarily the user-id that the user used when he was authenticated with an Authentication Service Provider. See Note 1.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? No, not in addition to what is delivered in 3.1.1. 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. As described briefly in 3.1.1, once a user is authenticated, the A-Select Server will redirect him back to the application with information about the authentication (such as the ticket granting ticket). The application will verify this with the A-Select Agent. The A-Select Agent will check the ticket granting with the A-Select Server. If ok, then the A-Select Server will return the information about the user and the authentication to the A-Select Agent. This information is shown in 3.1.1. Upon this, the A-Select Agent will generate a large number, the ticket for this application. It will return it to the application. The application is responsible for making this ticket a "real ticket". Actually, the common practice is that the application will store this ticket, the uid and perhaps other information returned by the A-Select Server as a cookie. The higher level integration components that we've developed do this too. 4 Authentication Session 4.1 Briefly describe how authentication session information is maintained (if not already covered in section 2 above): The application ticket (as well as the ticket granting ticket) is stored as a non-persisten cookie in the memory of the browser. For a complete flow, see http://a-select.surfnet.nl/ and chose "Functional flows" from the menu at the left. 4.2 Is it possible to for an application to set the session duration? If not already covered above, please describe: Two aspects: 1) Ticket granting ticket: no. This is a site-wide config option. 2) Application ticket: not by the application but is configured in the A-Select Agent. 4.3 Is it possible to terminate authentication session globally? How is that information conveyed to the application? No. But, note that the ticket granting ticket can be destroyed by logging out at the A-Select Server that issued it. Applications may implement similar functionality by mapping a logout functionality to a destroy of the application ticket. If a session is terminated, the application will be notified by a error response from the A-Select Agent. Note that, the application is responsible to verify each request that contains an application ticket with the A-Select Agent. 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 messsage format between application and A-Select Agent is in CGI-syntax (key=value) ASCII strings and is exchanged through a TCP/IP Socket based request response protocol. The A-Select Agent communicates with the A-Select Server with the same format and syntax but uses HTTP(S) as protocol. The A-Select Server communicates also with the same format and syntax with Authentication Service Provider's but here, redirection is used and parameters are sent as URL parameters. 5.2 Describe the protocol used by the WAA to handle the above (e.g. SAML POST Profile): The A-Select Server effectively chooses an Authentication Service Provider and uses the protocol required by the Authentication Service Provider. 6. Wish List 6.1 What changes or additions to the services provided by the WAA would you like to see in your system? Free format additional attribute additions. 6.2 At a high level, what other changes would you like to see in your system? 1) SAML bridge to the A-select Agent 2) Other protocol support besides http APPENDIX: See a-select.surfnet.nl for more information. Maarten Koopmans SURFnet