Single Sign-on

This short article is an abstract on the concept of Single Sign-On and the types of SSO depending on the usage context. FireWebSSO, only covers some aspects and not all the requirements of a full SSO solution. More information and related links can be found on wikipedia.

Principles

The main goal of the Single Sign-On is to facilitate the handling of the multiple authentications required every day to access authenticated applications. One authentication, the primary authentication, is used to unlock multiple secondary authentications.
In the best case, these secondary authentications are totally invisible to the user and the application access seems to be direct without any additional user operation. The second objective of the SSO, is to store securely all the credentials of the users, without any risk to be compromised or lost.
The third objective is to keep up-to-date these credentials and to control the applications access without any operation of the end-user.
These different objectives are not necessary reached in the same way, if the SSO is deployed for Enterprise access or only for individual purpose.

Enterprise SSO

The generic name of Enterprise SSO covers two aspects of the Single Sign-On:
  • SSO for all applications; mainly graphical/desktop applications under Windows.
  • SSO for Web Applications.

In enterprise environment, the motivation to deploy SSO solution is the cost reduction introduced by the centralization of the user's credentials, and of course the increase of level of security. (remember in Enterprise the ROI is the king).

From Wikipedia :

General Requirements for E-SSO

  • The solution needs to be highly available.
  • The solution needs to provide interfaces for backup, 24x7 monitoring and operations, etc.
  • The solution needs to be able to scale to many thousands of users accessing enterprise software.
  • The solution should be able to support the company-internal standards defined for efficient operations and integration without problems (e.g., directory server standards, authentication standards, etc.).
  • The solution should be able to easily integrate in related IT solutions, for example existing identity management solutions, security event management solutions, application management solutions, or desktop software distribution solutions.

Therefore, to cover the diversity of applications available inside enterprise environment and the previous requirements, the technical solution requires many times to install dedicated SSO-client on user's desktop. E-SSO can be deployed in the enterprise network where all the desktops are under control, but this deployment may become more difficult on nomad clients in a heterogeneous context. Of course in a full Microsoft Windows world, the use of Kerberos authentication in a Microsoft Windows Domain, is an alternative, not really open. (note that Kerberos may also be deployed with other systems than Windows).

Fortunately, applications are becoming more and more Web-aware, and supply Web interfaces. (For example: Outlook Web Access, Lotus Notes...). These applications can then be accessible from any (almost) navigator from any point of the network. For a dedicated access from the Internet to the Intranet application, the Enterprise Web SSO is the infrastructure solution.

The list of the major competitors, providing professionnal solution for E-SSO can be found in Gartner's Magic Quadrant for Enterprise Single Sign-On

An other list can be found in the dmoz directory.

Enterprise Web SSO (or Enterprise Web Access Management.)

Accessing the Enterprise Web applications from any navigator, from intranet or internet:

Technology approaches:

  • Modify the Web applications in integrating SSO frameworks (Central Authentication Service (CAS) , Java Open Source Single Sign-On (JOSSO), Security Assertion Markup Language (SAML), OpenID...). An analyse of different Web SSO protocols can be found in the paper Web Single Sign-On Systems. In any case, the modification of existing Web application is not easy and it costs, and it is some time impossible (how do you modify the Web administration interface of a Wifi Access Point?).
  • Intercept HTTP/HTTPS communications with a reverse proxy (LemonLdap based on apache as a reverse proxy), and inject authentication based on the pages analyze. It requires making the full inventory of all the Web sites used by all people, because it requires application-by-application configuration and definition.

The list of the major competitors, providing professionnal solution for Web Access Management can be found in Gartner's Magic Quadrant for Web Access Management

User Web SSO and FireWebSSO.

The objectives of FireWebSSO are to satisfy main requirements of an Enterprise SSO but with a very minimal cost. It is an answer of the question "how do I manage securely all my passwords without giving always the same identifier and password to all the Web server I use".

The approach is navigator centric, the navigator injects the passwords when needed, without the need of deploying desktop application. But the identifiers and the passwords are securely stored in a remote server. All the cryptographic are done inside the navigator and the server doesn't have the ability to look at the user's data.

The communication between the navigator and the FireWebSSO is done using SSL encryption to increase session security and prevent Man-In-The-middle risks. You may read the Security features of FireWebSSO for more details.

It is clear that FireWebSSO cannot compete with Enterprise Web SSO, due to lack of features in the server side:

  • user provisioning
  • password synchronization with external sources
  • use of Enterprise Directory (LDAP, Active directory)

The main missing feature of the client side of FireWebSSO is:

  • The ability to connect securely to intranet servers in protecting the connections to achieve Enterprise Web Access and SSO.

The FireWebSSO roadmap of FireWebSSO Server and client contains the previous missing items, even if the current developments are focused on general Internet usage and user password management.

FireWebSSO project Roadmap

  • client :
    • Port on different FireFox and SeaMonkey version
    • Better mechanism for import/export passwords
    • Full navigator's bookmarks backup/restore and synchronization. The objective is to synchronize thousands of bookmarks per-user. It needs improvement in the cryptographic codes of the add-on, without using any binary library (.so or other system dependent .dll).
    • "Proxy-in-Proxy" connections for intranet access, based on sites configuration.
  • Server:
    • ODBC interface to use any SGBDR
    • Complete administration interface, the monitoring interface already exists.
    • User/password provisioning.
    • User/password synchronization with external sources.
    • Integration with LDAP servers.
    • Support of the "Proxy-in-Proxy" protocol.

    • Note: "Proxy-in-Proxy" is a feature to do tunneling of HTTP or HTTPS connections inside an HTTPS connection even if the navigator use a dedicated proxy to access the "outside" network.

April 15, 2009