Single Sign-On Integration Scenarios

Example Integration Scenarios

Approach 1: SSO Protocol Support

Single Sign-On’s integrated CAS^® SSO server natively supports a number of standard and common SSO protocols for applications integration, including CAS^® 1, CAS^® 2, SAML 1.1, SAML 1.2, and Open ID 1.0. This allows easy integration with any applications supporting those protocols, typically simply through a matter of enabling an administrative configuration.

Advantages: Standard, supportable, allowed tight integration & capabilities, typically protects user credentials

Disadvantages: Difficult to do if not supported by manufacturers/service providers, potential incompatibilities in implementation

Approach 2: Custom SSO API Integration

The Quicklaunch framework provides a number of adaptors to custom SSO APIs (like Datatel^® WebAdvisor^®) which serve as a bridge between Single Sign-On SSO and vendor-supplied integration points. This scenario is often similar to Approach 1 above from an implementation standpoint.

Advantages: Supported, typically protects user credentials

Disadvantages: Configuration and setup on the product side can be difficult

Approach 3: Automated Credential Replay (Common Sign-On Services)

Many systems either do not natively integrate with SSO systems, or provide hooks for authentication via external mechanisms, but do support integration with an LDAP or enterprise directory or IDM provisioning flow.

In these scenarios (where username/password are the same, but the login process is separate) Single Sign-On provides a Quicklaunch adaptor which supports Credential Replay –where Quicklaunch can take the username/password used to login to the portal, and pass that along to other applications as well, resulting in simplified login for the user.

Advantages: No modifications to target systems required, no credential storage required

Disadvantages: Parameters and formats can change between different software versions, may require specific network/domain settings to support some login processes

Steps in this approach:

• User logs into the Single Sign-On Service (which caches their username/password in the current session)1, and clicks on a Quicklaunch link to the target system
• Quicklaunch (behind the scenes) uses the user’s password to generate the appropriate login request for the target system, and then redirects the user’s browser to a page that securely submits it, as if the user had logged in directly
• The user is processed through the applications standard login process, just as if they had logged in manually

User names and passwords in this scenario are not written to disk, database, or other persistent storage medium, but retrieved at the beginning of every user session

Approach 3a: Stored Credential Replay (Separate Services)

A variation of Approach 3 can also be used against target systems that do not share common- sign on with the portal server. This scenario is especially common with hosted or departmental systems. In this approach, the mechanisms of communicating with the service are identical, with the exception that the first time a user attempts to access the service, they’ll be prompted to store their username and password, which will then be encrypted and used to support future login attempts.

Advantages: No modifications to target systems required, may be the only way to integrate some systems

Disadvantages: Parameters and formats can change between different software versions, may require specific network/domain settings to support some login processes, requires storage and management of user credentials

Steps in this approach:

• User logs into the Single Sign-On Service and clicks on a Quicklaunch link to the target System
• Quicklaunch looks up the user’s service username/password from the Secure Credential Repository (DES Encryption) in the portal database.
• If no username/password are present, user is prompted for username/password and they are encrypted and saved. Otherwise the username/password are passed along to the Stored Credential Replay Adaptor
• Quicklaunch (behind the scenes) uses the user’s password to generate the appropriate login request for the target system, and then redirects the user’s browser to a page that securely submits it, as if the user had logged in directly
• The user is processed through the applications standard login process, just as if they had logged in manually

Approach 4: Out-of-Band Agreements

A number of services may support out of band agreements for Single-Sign-On. Examples of this type of authentication include: IP-Address range based access, referrer-based access, shared- secret/token based access, or other mechanisms put in place between systems without direct participation by the parties involved.

This approach is only appropriate in a few contexts, generally being used when authorization or access controls needed are relatively weak and best-effort security or protection is deemed sufficient.

Advantages: No modifications to calling systems required, common with vendors of licensed Content (library content providers, others)

Disadvantages: Generally not appropriate for personalized authentication or highly-secure systems, requires setup outside the SSO system, and requires specific support in target applications

Steps in this approach:

• User logs into the Single Sign-On Service and clicks on a Quicklaunch or other link to the target system
• A check is done by the target system for compliance with an out-of-band agreement. Common agreements include:
• Client IP-Address Check
• Referrer (from HTTP header) check
• Shared Token Check (e.g. secret key passed along with the request URL)
• Shared-cookie based schemes

For more information about myCampus Single Sign-On, please send an e-mail to membership@campuseai.org