The Authentication Service provides a secure web Single Sign On (SSO) platform for application to delegate the authentication that enables users to access application without needs of supplying credentials every time. The service supports the following protocols:
- Central Authentication Service Protocol (CAS)
- Security Assertion Markup Language (SAML)
- OpenID Connect
CAS is the simplest and lightweight from developer point of view amongst all these protocols. It is adequate for mostly all kind of web-based applications and this is recommended by ITSC. SAML, on the other hand, is a well-established XML-based standard for exchanging authentication and authorization data between systems. Unlike CAS, which is a protocol, the SAML standard defines the XML document structure and how applications should consume it. SAML is popular in the cloud-based applications that are likely to be supported. OpenID Connect built on-top of the OAuth2 framework is a lightweight authentication protocol which uses REST based message flows using JSON web tokens (JWT). OpenID Connect is well suited towards single page applications, native mobile apps, and other non-browser user-agents.
These protocols are all supported by ITSC. The application developer or service owner shall choose the right protocol accordingly to add authentication service to the application or service.
Scope of Services
Besides the protocols and server-side technologies, ITSC also provides the following services around the SSO platform:
- Initial application integration consultation and support related to SSO best practices such as crypto, protocol and authorization
- Highly-available production authentication service
- Development and testing authentication service
- Change management and release schedule communicated via the email@example.com mailing list
- ITSC shall communicate planned changes at least a week in advance for minor changes (e.g. security patches), and at least a month in advance for major changes. Minor changes SHOULD NOT impact users; major changes MAY impact users
In order to provide the services above, application owners are responsible for the following:
- Identify business and technical requirements sufficient to complete an SSO integration. ITSC offers consulting services to fill gaps in technical knowledge and to facilitate requirements gathering
- Identify and maintain a technical contact for your application
- Engage with ITSC as needed in response to planned service changes via the firstname.lastname@example.org mailing list
- Stand up a non-production application environment to facilitate SSO testing
The following sections describe technical and policy requirements that consumers must fulfill in order to use the Authentication Service.
Any application, either on-premises or cloud-based, for the HKUST community is eligible for performing SSO via the Authentication Service. This includes CAS protocol and the loosely-supported SAML 1.1 protocol for ticket validation and attributes retrieval. Click CAS to register a new application.
Consuming services MUST be over a secure channel, which means that the service must be accessible exclusively over HTTPS. ITSC will confirm that the requested service URI/URL to be registered conforms to this requirement. Any X.509 certificate issuer may be used to provide SSL/TLS server certificates to secure the service, though we recommend the Certification Service, which provides SSL server certificate at no cost to any HKUST websites. Use of self-signed certificates are allowed, but strongly discouraged for production services.
Sessions and Security
Authentication Service maintains a session to facilitate accessing services without having to reauthenticate.
Single Sign-on Session
When a user logs in to the Authentication Service, a single sign-on session is started. Users will not be prompted again for credentials (i.e. username/password/2FA) for 8 hours unless a service explicitly requires users to re-authenticate (i.e. forced authentication).
It is vitally important to understand that the single sign-on session is entirely independent of application sessions created as users access services via Authentication Service. Indeed, it’s entirely possible for an application session to be created and expire due to inactivity while an SSO session is still active. In many cases if the user attempted to access that application again, he or she would be permitted without having to reauthenticate. Upon reentering the application, a new application session would be created. Most users would perceive this as a glitch, not realizing that they are creating new application sessions seamlessly due to SSO.
Single Logout (SLO)
Though Authentication Service provides a logout protocol to end the sessions of all applications used during a user’s single sign-on session, ITSC do not recommend using it because it is hardly done correctly in reality, and this will cause confusion to users. We recommend users to close the browser windows to completely sign out the SSO session as well as application sessions to be created via the Authentication Service.