Skip to content

Single Signon

back to web hosting

Single Signon infrastructure is designed as a flexible security framework for configuring institution and/or group-level access to web applications and individual endpoints (sub-urls).

All UFIT Research Computing web interfaces like RC Support System, Open OnDemand, JupyterHub use the same SSO available for your web applications.

The SSO works by preventing access and redirecting unathenticated and unauthorized users from a protected endpoint. Unathenticated users are redirected to their identity provider service (UF Gatorlink or another InCommon Federation Member Instituation) where they log in with their institutional credentials. Once authenticated, users are either redirected back if they have membership in the authorization scope configured for the endpoint or redirected to the main RC website with an "Unauthorized" error message.

Authorization Scopes

There are two scopes/levels of authorization:

  • Institutional level. Available choices include

    • All HiPerGator Users.
    • All UF GatorLink Users. Users log in with UF GatorLink credentials.
    • All InCommon Federation Users. Individuals log in with their own institutional credentials.

  • HiPerGator Group level. Any combination of HiPerGator groups can be configured for access to any endpoint hosted on RC web infrastructure.

Authorization configuration

Endpoint protection with SSO is set in the reverse proxy webserver vhost configuration by RC staff on request.

Authorization scopes can be set on individual enpoints and the entire web application in various combinations. Application URL looks like https://something.org or https://something.rc.ufl.edu whereas individual endpoints are paths/URLs within the application like /do/something with the full URL looking like https://something.rc.ufl.edu/do/something.

For example, a pubapps application can be completely open to the Internet or set to institional level, while its sensitive endpoints like the admin interface are configured to only allow the members of the research group on HiPerGator that's developing and maintaining the application to reduce its attack surface.

Web Application Data

For any protected endpoint SSO will set several request headers:

  • REMOTE_USER - email address
  • REMOTE_USER_DATA - A triplet of HiPergator username,Full Name,EPPN
  • REMOTE_USER_TOKENS - a list of authorization identifiers like the HiPerGator group(s) and institutional tokens.

These headers are set by the proxy server for every request, but only for the protected endpoints.

Server-side web applications can read these headers and use the provided user identity and authorization data.

Limitations

  • JavScript Front-End / API Backend applications known as Single Page Application architecture has pecularities that impact the server-side SSO use. While SSO can protect the backend the front-end may get cached in the browser and show the cached data to unathenticated users or throw an unexpected error on the next visit until the browser window or tab with the front-end is reloaded.
  • Only protected endpoints have SSO headers set, which can lead to surprises if protected endpoints are not documented or identified well by the application developers.
  • SSO session is cookie-based, which makes it difficult to use with APIs. APIs should employ a different authentication/authorization method.
  • Only two scopes (institutional and HPG group) are available for now. UF Department ID or UFAD group scopes are not available, yet.
  • Endpoint authorization change requests must go through RC Support as they are configured in the reverse proxy virtualhost configs, so they are not immediately changeable by the developers.