Jagiellonian University Norm DTI/01-2

Transcription

1 Jagiellonian University Norm DTI/01-2 Central Login of the Jagiellonian University ( Punkt Logowania ) rules for connecting applications As at: 11 th June 2015 Abstract This norm sets rules for all applications connected to the Central Login ( Punkt Logowania ) that implements a Single Sign On mechanism for web services at Jagiellonian University. How does the authentication work? The Central Login of the Jagiellonian University service is based on Central Authentication Service (CAS) software with SAML validation and basic integration rules that follow these standards (off-theshelf available client modules may be used). By login to the Central Login Point the user receives a session identified by a TGT cookie (Ticket Granting Ticket). CAS maintains a repository of active sessions with TGT as the key. Once the application redirected the user to the Central Login in order to authenticate it, a Service Ticket (ST) is generated. It is a one-time ticket and enables the application to obtain user data. CAS stores all ST assigned to corresponding TGT. A sample authentication process: 1. The user enters the site and clicks on the Login button 2. Next, the user is redirected to the site: Once a correct login and password is provided, the user is redirected to the site: where the ticket is a one-way ticket of the ST type 4. While loading the webpage the application code sends a POST request to the address: that contains a SAML message with the ST ticket (details of this process are described in the CAS and SAML documentation) If ST is an existing ticket issued for this application, the CAS will return the logged in username and their attributes. Based on these data the application the application authenticates the user.

2 Description of the login and data received upon authentication Users may login with identifiers: (where login is the USOSweb 1 ) Following cases are possible: 1. user logged in using firstname.familyname@uj.edu.pl 2. user logged in using login@usosweb.uj.edu.pl, his/her USOSweb account is authorized by LDAP and he/she has activated account firstname.familyname@uj.edu.pl 3. user logged in using login@usosweb.uj.edu.pl, his/her USOSweb account is authorized by LDAP and he/she has NOT activated account 4. user logged in using login@usosweb.uj.edu.pl, his/her USOSweb account is NOT authorized by LDAP Provided the user has given the right password, the following data will be returned: Ad 1. login: firstname.familyname@uj.edu.pl attributes: first name, family name, uid, mailuserstatus, usos_id *** Ad 2. login: firstname.familyname@uj.edu.pl attributes: first name, family name, uid, mailuserstatus, usos_id Ad 3. login: uid@ldap.uj.edu.pl attributes: first name, family name, uid, mailuserstatus, usos_id*** Ad 4. login: login@usosweb.uj.edu.pl attributes: first name, family name, usos_id As may it may be seen from points 2 and 3, when only possible, the login is cast on the address or uid@ldap.uj.edu.pl for better flexibility. The data will be return with SAML protocol only. This mechanism is available in: production context ( test context ( In addition, there is a simplified test context available which enables authorization of any given login with the password sso. Remark: Local application should handle in a correct way all the situations in which a person is authenticated with CAS, but not authorized in the local application (does not have or cannot have there an account). *** usos_id will be return for for case 1 and 3 under the condition that user has an USOS account 1 USOSWeb Deanery System at Jagiellonian University

3 Sign out from Central Login and associated applications Central Login supports a Single-Sign-Out mechanism following rules described in the CAS documentation. Signing out from Central Login is the result of calling the URL Its execution may be initiated by the user (e.g. by clicking on the logout link on the Central Login page) or by an external application (by redirecting the user to the sign out page). Signing out from CAS results in: 1. closing the uses session in CAS, 2. broadcasting to all services to which the user logged in during the session a LogoutRequest message with Service Tickets of logged-out sessions. The message is sent to the application using POST method to the URL given initially in the service parameter while logging in. The request contains following data: <samlp:logoutrequest xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" ID="[RANDOM ID]" Version="2.0" IssueInstant="[CURRENT DATETIME]"> <saml:nameid xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">@not_used@</ saml:nameid> <samlp:sessionindex>[session ID: ST-xxyyyyyyyyyy]</samlp:SessionIndex> </samlp:logoutrequest> Remark: one request may contain many SessionIndex items. Each of those comprise of a session identifier same as the ticket used for authenticating the user in the application. We recommend that the sing out mechanism works the following way: 1. on clicking logout signs out from the application 2. after signing out from the application, sign out from CAS This order guarantees that even in case of CAS failure the user will be signed out from the application for which the user pressed the logout button.

4 Rules for session sustaining in Central Login and associated applications The session time duration in login.uj.edu.pl and associated application is defined by CAS. This is governed by following principles: Session time duration in CAS is set to 50 minutes; The session is prolonged on every activity of the user on the CAS page; When the session time in CAS is over, the user is logged out from CAS and all associated applications (a sign out message is broadcasted to all applications); Session time duration in associated durations is set not less than in CAS e.g minutes (so that the user will not lose his/her session before the end of CAS session); Before the CAS signs out it sends a request to all associated applications asking about the time of last user activity. If there was such an activity the session time is prolonged so it will end 50 minutes later. Technical details: CAS queries associated application using the URL from which the user logged it (submitted to CAS in the service parameter). The request is sent using POST with the parameter: lastaccessedtimerequest=<lastaccessedtimerequest><sessionindex> ST-xx-yyyyyyyyyy</SessionIndex></LastAccessedTimeRequest> where ST-xx-yyyyyyyyyy is the ticket that authenticated the user for the application. In response you are supposed to send a Unix timestamp (in miliseconds) in the form: <LastAccessedTimeResponse><LastAccessedTime>TIMESTAMP</LastAcce ssedtime></lastaccessedtimeresponse> where TIEMSTAMP is the numerical value of the timestamp. Applications should have already a built in logout mechanism, so the session control may be implemented in a similar way. You should consider that the service parameter sent to CAS while login may change so it is not enough to detect POST requests under a given address (same as in the case of logging out).

5 Tabs on the Central Login page The Central Login page contains information grouped in tabs (on clicking on a tab name the content of the panel is displayed without reloading the page). By default the tab About Central Login is displayed. However, it is possible to display a different tab when given a specific value in the tab parameter of the GET request. The permitted parameter values are: opunkcie {About Central Login} pomoc {Help} listaserwisow {List of services} aktywacja { activation} zmianahasla {Password change} Example how to use it: A link for changing the password to be placed in the application for logged in users: A link to the list of services:

6 Different language versions of Central Login The Central Login page is available in the Polish and English language version. Selection of a language version may be enforced by the locale parameter. Polish version: English version: In case the locale parameter is not given, the application will select the language base on web browser setting or based on cookies (in case the user has changed the language version of Central Login before by clicking on one of the national flags presented on the web page). We recommend to redirect to the English version of the application always including the parameter locale=en.

7 Requirements for connecting applications to Central Login The following requirements should be met in order to connect your application to the production version of Central Login ( From the technical point of view the application should: implement authentication via Central Login implement a single sign out mechanism implement previously describe mechanisms for sustaining user session In interaction with the user: the application should facilitate a log out possibility (log out link visible on all pages of the application) the application should never ask the user for a password in case is required to log out just from the application but not CAS, the user should be presented with an adequate message and an opportunity to select the log out type if the application would like to provide the user with an opportunity to change password, it has to be implemented by redirecting the user to the Change password tab of Central Login Before release of the application it is required that at least one person is declared to ZAiIS 2 as responsible for the technical and formal issues of the application (e.g. the head of the unit). It is required to provide first and family names and addresses. Before the production release the application has to be tested by the ZAiIS staff. In order to do that the staff has to be given access to the application. After a positive verification the application will be granted access to the Central Login. The ZAiIS staff may preform regular test of the application and in case of detecting inconsistency with the above described procedure withdraw access of the application to Central Login (after the application owner has been informed about the detected issues). 2 ZAiIS - Section for Architecture and Integration of the IT Department of Jagiellonian University