Jagiellonian University Norm DTI/01-2

Similar documents
MAINTENANCE HELPDESK SYSTEM USER MANUAL: CUSTOMER (STAFF) VERSION 2.0

SAML-Based SSO Solution

Trusted Login Connector (Hosted SSO)

SAML-Based SSO Solution

Using VMware Horizon Workspace to Enable SSO in VMware vcloud Director 5.1

How to Configure Authentication and Access Control (AAA)

Suomi.fi e-identification Technical interface description

Operating Level Agreement for NYU Login Service

Affinity Provider Portal Training Manual

VAM. CAS Installer (for 2FA) Value- Added Module (VAM) Deployment Guide

CA SiteMinder Federation

Business Online Banking. Remote Business Deposit Quick Start Guide

SAML Single Sign On Integration

Central Authentication Service Integration 2.0 Administration Guide May 2014

Nimsoft Service Desk. Single Sign-On Configuration Guide. [assign the version number for your book]

System Administrator s Guide Login. Updated: May 2018 Version: 2.4

IDENTITY MANAGEMENT & SINGLE SIGN-ON (SSO) HELP GUIDE UPDATED JUNE 2018

Person Proxy Information

Oracle Utilities Opower Solution Extension Partner SSO

Webthority can provide single sign-on to web applications using one of the following authentication methods:

User Management: Configuring User Roles and Local Users

Isi Net User Manual for Bank customers

How to Edit General Institutional Preferences

User Guide. Version R92. English

Radius, LDAP, Radius used in Authenticating Users

Qualys SAML 2.0 Single Sign-On (SSO) Technical Brief

Applying for a Position

CA Single Sign-On and LDAP/AD integration

First Data ServiceCenter Web

The Ethic Management System (EMS) User guide

DESIGN OF WEB SERVICE SINGLE SIGN-ON BASED ON TICKET AND ASSERTION

User Guide. Version R94. English

Integration of the platform. Technical specifications

Enhancing cloud applications by using external authentication services. 2015, 2016 IBM Corporation

Contents. Table of Contents

Connect-2-Everything SAML SSO (client documentation)

MotionPro Android Release Note

Technical Query (TQ) Application - Vendor Documentation

VMware Identity Manager Administration

CA SiteMinder. Federation Manager Guide: Legacy Federation. r12.5

OSF UnifyCOMMERCE for Commerce Cloud. OSF UnifyCOMMERCE COMMUNITY Integration. User Guide

Customer Care Portal User Guide

Griffith Service Manager (GSM) Using Bomgar Remote Access

Setting Up Resources in VMware Identity Manager (SaaS) Modified 15 SEP 2017 VMware Identity Manager

TAS Self Service Reporting Overview

Acceptance Test Plan and Cases (ATPC)

How to Login, Logout and Manage Password (QRG)

Implement SAML 2.0 SSO in WLS using IDM Federation Services

Secure Access Manager User Guide December 2017

Entrust GetAccess 7.0 Technical Integration Brief for IBM WebSphere Portal 5.0

Liferay Security Features Overview. How Liferay Approaches Security

SAML Authentication with Pulse Connect Secure and Pulse Secure Virtual Traffic Manager

User Guide Version 1.3

Secure single sign-on for cloud applications

How to social login with Aruba controller. Bo Nielsen, CCIE #53075 (Sec) December 2016, V1.00

Click E Money Laravel Application

E-Learning Portal Online User Manual

maxecurity Product Suite

Secure Access Manager User Guide September 2017

April Understanding Federated Single Sign-On (SSO) Process

Integrating IBM Security Privileged Identity Manager with ObserveIT Enterprise Session Recording

User Manual for Testing Accounts

Configuring Alfresco Cloud with ADFS 3.0

Single Sign-On (SSO)Technical Specification

Radius, LDAP, Radius, Kerberos used in Authenticating Users

Test Plan for Liberty Alliance SAML Test Event Test Criteria SAML 2.0

Person Proxy Information

Microsoft Office 365 Integration. Administrator Guide

STEP 1. Go to the CNR Virtual HelpDesk at Then select Student Network Accounts

Design document for CSC/ECE 517 Fall 2002 Semester Project Security & Visibility for PG

System and Software Architecture Description (SSAD)

ForgeRock Access Management Customization and APIs

PassKey Manager Guide

GOBENCH IQ Release v

Department of Health & Family Welfare, Govt. of Odisha

13241 Woodland Park Road, Suite 400 Herndon, VA USA A U T H O R : E X O S T A R D ATE: M A R C H V E R S I O N : 3.

How to Configure SSL VPN Portal for Forcepoint NGFW TECHNICAL DOCUMENT

Aaple Sarkar DBT Portal

CA SiteMinder Federation Security Services

Network Configuration Example

Load testing with WAPT: Quick Start Guide

LDAP Synchronization Secure Coding Guide

Regions OnePass USER GUIDE. It s time to expect more. Regions Bank Member FDIC Revised

Supplier Response Guide. Access Supplier Portal to Review and Respond to Bid Opportunities

Users. LDAP Synchronization Overview

Single Sign On through PingOne. Go to and click on the Change Healthcare IdentityIQ icon.

Business Manager Net. Supplemental Manual

AppScaler SSO Active Directory Guide

User Guide. For. The EDB Portal

How to Use Your EV Connect Account

Cloud Access Manager How to Configure for SSO to SAP NetWeaver using SAML 2.0

Secure Web Appliance. Basic Usage Guide

Introduction... 5 Configuring Single Sign-On... 7 Prerequisites for Configuring Single Sign-On... 7 Installing Oracle HTTP Server...

School Referral User Guide

AAI Login Demo. SWITCHaai Introduction Course Bern, 1. March Daniel Lutz

Enterprise Access Gateway Management for Exostar s IAM Platform June 2018

User Guide of PIP System for Employers

MyRA Quick Guide Version 4.0

NETOP PORTAL ADFS & AZURE AD INTEGRATION

Enhanced OpenID Protocol in Identity Management

Transcription:

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 https://aplikacja.uj.edu.pl/ and clicks on the Login button 2. Next, the user is redirected to the site: https://login.uj.edu.pl/login?service= https://aplikacja.uj.edu.pl/ 3. Once a correct login and password is provided, the user is redirected to the site: https://aplikacja.uj.edu.pl/?ticket=st-xx-yyyyyyyyyy 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: https://login.uj.edu.pl/samlvalidate?target=https://aplikacja.uj.edu.pl/ 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.

Description of the login and data received upon authentication Users may login with identifiers: firstname.familyname@uj.edu.pl login@usosweb.uj.edu.pl (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 email 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 email 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 e-mail 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 (https://login.uj.edu.pl) test context (https://login.uj.edu.pl/uj_ldap) In addition, there is a simplified test context https://login.uj.edu.pl/uj_simple 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

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 https://login.uj.edu.pl/logout. 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.

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. 50 + 5 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).

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 {E-mail 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: https://login.uj.edu.pl/login?tab=zmianahasla A link to the list of services: https://login.uj.edu.pl/login?tab=listaserwisow

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: https://login.uj.edu.pl/login?locale=pl English version: https://login.uj.edu.pl/login?locale=en 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.

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 (https://login.uj.edu.pl/). 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 e-mail 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