Single Sign-On solutions

Single Sign-On is a session/user authentication process that allows a user to provide his or her credentials once in order to access multiple applications. The single sign-on authenticates the user to access all the applications he or she has been authorized to access. It eliminates future authentication requests when the user switches applications during that particular session.
When single sign-on works strictly with applications accesses with a web browser, the request to access a web resource is intercepted either by a component in the web server, or by the application itself. Unauthenticated users are diverted to an authentication service and returned only after a successful authentication.

Single Sign-On services reviewed in this post:

1. SSOGenius (http://www.vlegenius.com/)
2. JA-SIG Central Authentication Service (CAS) (http://www.ja-sig.org/products/cas/)
3. Java Open Single Sign-On (JOSSO) (http://www.josso.org/)
4. Collaborative Single Sign-On (CoSign) (http://www.umich.edu/~umweb/software/cosign/)
5. Pubcookie (http://www.pubcookie.org/)
6. Stanford WebAuth (http://www.stanford.edu/services/webauth/)
7. Open Web SSO (OpenSSO) (http://opensso.dev.java.net/)

1. SSOGenius (http://www.vlegenius.com/)

SSOGenius is a simple Single Sign-On solution for Blackboard, enabling users to move from an external site into Blackboard and visa versa, without needing to login.

1.1 Features:

• Pass authenticated users into Blackboard
• Pass Blackboard users into an external site
• No need to modify the Blackboard configuration
• Independent of domain and time zone
• Easy to implement

1.2 Latest Build: 1.0.12

1.3 Implementation:

We need to create two scripts of our own, LoginFromBlackboard and LoginToBlackboard on external system. These will send and receive requests to and from Blackboard via the SSOGenius building block.

1.4 How it works:

A user logs onto Blackboard. The user clicks on a special link to the external site. (These can be placed anywhere in Blackboard where links or HTML text can be added) SSOGenius intercepts the request then adds authentication parameters and redirects the user to a special SSO script on the external site. The external SSO script authenticates the user with the new site, using the details sent by SSOGenius. The script should then redirect the client to the desired page on the external system.

1.5 System Requirements:

• Java: JDK1.4.2 or higher.
• Operating System: Linux, Sun Solaris, Microsoft Windows
• Access to an external system (Add/modify the existing code).
• 1.6 License (One year site licenses):
• Standard License: £700.
• FE/School License: £525.

2. JA-SIG Central Authentication Service (CAS) (http://www.ja-sig.org/products/cas/)

A cookie based model. CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. CAS became a JA-SIG project in December 2004.

2.1 Features:

• An open and well-documented protocol.
• An open-source Java server component.
• A library of clients for Java, .Net, PHP, Perl, Apache, uPortal, and others.
• Community documentation and implementation support.
• LDAP authentication handler, X.509 Certificates support.

2.2 Latest Build:

• CAS Server Release: CAS Server 3.0.7 GA
• CAS Client Release for different platforms.

2.3 License: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the copyright notice (Copyright © 2000 The JA-SIG Collaborative.), this list of conditions and the following disclaimer.


2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.


3. Redistributions of any form whatsoever must retain the following acknowledgement: “This product includes software developed by the JA-SIG Collaborative (http://www.ja-sig.org/).”

2.4 Implementation (Proxy Authentication):

• S (Service): A web application that authenticates users via CAS.
• C (Ticket-granting Cookie): A ticket encapsulated by a cookie that is sent to the user’s web browser and returned only to CAS, and only over a secured channel.
• ST (Service Ticket): A ticket sent by CAS, through the user’s browser, to a service. Each ST may be used only once, and must be combined with the unique identifier for one specific service in order to be useful.

2.5 System Requirements:

• Java: JDK 1.4.2 or higher.
• Apache Tomcat 5.x.

3. Java Open Single Sign-On (JOSSO) (http://www.josso.org/)

JOSSO is an open source J2EE-based SSO infrastructure aimed to provide a solution for centralized platform neutral user authentication.

3.1 Features:

• 100% Java with JDK5 compatibility.
• JAAS-based Transparent Single Sign-On across multiple applications and hosts.
• Built-in with a Pluggable Framework to allow the implementation of multiple authentication schemes and stores.
• Provides Identity information to web applications and EJBs through the standard Servlet and EJB Security API respectively.
• Supports Strong Authentication using X.509 client certificates.
• Comes with a Reverse Proxy component that can be used to create n-tier Single Sign-On configurations.
• Support for transparent cross-organization/cross-domain Single Sign-On.
• LDAP support for storing user information and credentials.
• Microsoft Active Directory support for LDAP integration.
• Database support for storing user information and credentials.
• XML support for storing user information and credentials.
• Client API for Microsoft ASP.

3.2 Latest Build: 1.5

3.3 License: BSD License.

3.4 Implementation: Please check JOSSO’s website for diagrams.

3.5 System Requirements:

• JDK 5.0 or higher.
• Apache Tomcat 5.x.
• JBoss 3.2.6+ and JBoss 4.

4. Collaborative Single Sign-On (CoSign) (http://www.umich.edu/~umweb/software/cosign/)

4.1 Features:

• Passwords are sent only to the central weblogin service over SSL.
• Users need only authenticate once per session to access any number of CoSign-protected sites.
• Optional per-service re-authentication.
• X.509 certificate support.
• No domain cookies used.
• Sessions have both idle and hard timeouts.
• Users can logout of all CoSign-protected services by visiting a single URL.

4.2 Latest Build: CoSign 2.0.1

4.3 License: © 2002 – 2004 Regents of the University of Michigan.

4.4 Implementation (check CoSign’s website for diagrams):

• User visits weblogin before accessing a service
• User attempts to visit a protected service directly

4.5 System Requirements:

• Apache 1.3.x or higher/Apache 2.x or higher.
• OpenSSL 0.9.7a or higher.

5. Pubcookie (http://www.pubcookie.org/)

A cookie based model. Pubcookie is an open-source package for intra-institutional Single Sign-On end-user web authentication. It is an approach to identifying users as they browse to an institution’s many websites that require authentication. It helps an institution reuse existing authentication services (LDAP, Kerberos), and it limits the exposure of end-user passwords by ensuring they’re only sent to a trusted login service.

5.1 Latest Build: 3.3.2c

5.2 License: Apache License (Version 2.0).

5.3 Implementation: Check Pubcookie’s website for diagrams.

5.4 System Requirements:

• Web Application Requirements:
• HTTPS connections: Pubcookie flags all cookies “secure”, so applications should be written such that browsers use SSL-protected (https) connections.
• Session creation by HTTP GET requests: Applications should be designed such that sessions are created from a HTTP GET request. Applications should not be designed such that a user’s initial request is a HTTP POST.
• Login Server Requirements:
• Unix platform
• Web server with CGI support
• SSL server certificate
• User-Agent Requirements:
• SSL support
• Cookies supported and enabled

6. Stanford WebAuth (http://www.stanford.edu/services/webauth/)

A cookie based model. WebAuth is an authentication system for web pages and web applications. The first time a user attempts to access a web page protected by WebAuth, they will be sent to a central login server and prompted to authenticate. Once the user has logged in, the weblogin server will send their encrypted identity back to the original web page they were trying to access. Their identity will also be stored in a cookie set by the weblogin server and they will not need to authenticate again until their credentials expire, even if they visit multiple protected web sites.

6.1 Features:

Supports any browser that supports SSL/TLS and cookies and requires no special browser configuration.
Implemented as an Apache authentication mechanism.
Built-in LDAPv3 integration.

6.2 Latest Build: WebAuth 3.5.3

6.3 License: © 2002 – 2006 Board of Trustees, Leland Stanford Jr. University

6.4 Implementation: Implemented as Apache 2.0 modules.

6.5 System Requirements:

• Apache 2.0.43 or higher.
• OpenSSL 0.9.7
• cURL 7.10 or higher.
• OpenLDAP or Cyrus SASL for LDAP authentication.

7. Open Web SSO (OpenSSO) (http://opensso.dev.java.net/)

The Open Web SSO project (OpenSSO) provides core identity services to simplify the implementation of transparent Single Sign-On (SSO) as a security component in a network infrastructure. OpenSSO provides the foundation for integrating diverse web application that might typically operate against a disparate set of identity repositories and are hosted on a variety of platforms such as web and application servers. OpenSSO is based on the code base of Sun Java System Access Manager, a core identity infrastructure product offered by Sun Microsystems.

7.1 Features:

• Single Sign-On (SSO)
• Centralized authorization services
• Federated Identity support
• J2EE architecture and comprehensive APIs
• Enterprise-class scalability and reliability
• Real-time audit

7.2 Supported Standards:

• Java Authentication and Authorization Service (JAAS)
• Kerberos
• Lightweight Directory Access Protocol (LDAP)
• Secure Sockets Layer (SSL)

7.3 Supported Authentication Modules:

• Active Directory
• X.509 Certificate
• Java Database Connectivity (JDBC)
• LDAP

7.4 License: Sun’s Common Development and Distribution License (CDDL)

7.5 Implementation:

OpenSSO contains four modules: Access Manager, Open Federation Library, Open Federation, and J2EE Agents.

7.6 System Requirements:

• Sun JDK 1.5.0 or higher
• Apache Tomcat 5.5.x or higher
• Apache 2.0.x or higher