| Table of Contents |
|---|
Beginning with SSP versions 2.0.0-b3 and 1.2.2, SSP supports a simple single-sign-on (SSO) protocol based on signed URLs. Historically it has been used primarily for "deep-linking" from a LMS to the SSP Early Alert creation form.
To use this feature, clients submit signed URLs via HTTP POST via back-channel requests (i.e. not via the end-user browser), to which SSP will respond with a JSON object containing a temporarily authorized URL to which to redirect the end-user's browser.
This document describes how to enable this feature in a SSP deployment and invoke it from an external system.
Deployment
Configuration
The following properties in {ssp-platform-src}/uportal-war/src/main/properties/portal.properties configure the SSO feature. Aside from forking and editing that file inline (a bad idea), properties set to ${environment.*} can be overridden in two different ways, depending on the version of SSP you're running:
...
Overview
| Info |
|---|
As of v2.5.2 and 2.6.0, SSP ships with a IMS LTI Provider implementation which provides effectively equivalent functionality as the mechanism described here, but in a standards-based way such that no custom development is typically required to achieve the same goals. Be sure you have a good reason to rule out the LTI provider before embarking on a implementing a client for the SSO protocol described below. (Even if you're not running 2.5.2+ or 2.6.0+, back-porting the LTI provider may end up being simpler and certainly cheaper to maintain over the long term than writing a custom "Signed URL SSO" client.) |
Beginning with SSP versions 2.0.0-b3 and 1.2.2, SSP supports a simple single-sign-on (SSO) protocol based on signed URLs. Historically it has been used primarily for "deep-linking" from a LMS to the SSP Early Alert creation form.
To use this feature, clients submit signed URLs via HTTP POST via back-channel requests (i.e. not via the end-user browser), to which SSP will respond with a JSON object containing a temporarily authorized URL to which to redirect the end-user's browser.
This document describes how to enable this feature in a SSP deployment and invoke it from an external system.
Deployment
Configuration
The following properties in {ssp-platform-src}/uportal-war/src/main/properties/portal.properties configure the SSO feature. Aside from forking and editing that file inline (a bad idea), properties set to ${environment.*} can be overridden in two different ways, depending on the version of SSP you're running:
- Prior to v2.2.0: At build time by setting corresponding values in your environment-specific filters file (
{ssp-platform-src}/filters/*.properties). - With v2.2.0+: At run time by setting corresponding values in (
{SSP_CONFIGDIR}/ssp-platform-config.properties).
...
| No Format | ||
|---|---|---|
| ||
[...]
## SSO Properties
##
org.jasig.portal.security.sso.mvc.SsoController.requireSecure=${environment.build.sso.requireSecure}
org.jasig.portal.security.sso.mvc.SsoController.sharedSecret=${environment.build.sso.sharedSecret}
org.jasig.portal.security.sso.JpaSsoTicketDao.timeToLiveMinutes=${environment.build.sso.ticketTimeToLiveMinutes}
org.jasig.portal.security.sso.mvc.SsoController.checkTimeStampRange=${environment.build.sso.checkTimeStampRange}
org.jasig.portal.security.sso.mvc.SsoController.signedUrlToLiveMinutes=${environment.build.sso.signedUrlToLiveMinutes}
.sso.mvc.SsoController.signedUrlToLiveMinutes=${environment.build.sso.signedUrlToLiveMinutes}
|
Starting with v2.5.2, the environment.build.sso.local.sharedSecret property also needs to be set to a non-empty value in {SSP_CONFIGDIR}/ssp-platform-config.properties. You can choose any value you like and it needn't be terribly complex: a banking-style PIN should be sufficient. If you are also using the LTI integration, a corresponding value needs to be set in SSP configuration. See the LTI provider documentation for more detail.
requireSecure
This setting should be set to true in production. It forces the SSO exchange to take place over SSL. Default is true.
...