Google Apps is being rolled out to countless users and organizations each day.

For many various reasons, Single Sign On (SSO) access to Google Apps is desired by those organizations.  Google requires compliance with the SAML 2.0 security protocol in order to provide support for Single Sign On into Google Apps.

From the user perspective, they do not want an awkward, intrusive, difficult, or time-consuming experience.  In short, they want to be able to operate and act as they always have done in the past.

Innovative IT organizations have recognized that these users are accustomed to (and widely accept) the notion that they need to sign in to the desktop machine each day, providing an ID and a Password.

These innovative IT organizations have embraced the optional deployment model of leveraging the ID and Password that the user provides when logging in to his desktop each morning, as the mechanism for triggering SAML 2.0 based Single Sign On (SSO) to Google Apps.

A recent representative case study implementation by an SSO Easy client involved the following interesting use case:

• SAML 2.0 EasyConnect product
• OpenID to enable additional Single Sign On (SSO) function
• Amazon EC2 was the platform on which the EasyConnect SAML 2.0 was running.

The customer completed the implementation within a few hours.

With ever-growing popularity, users and organizations are looking to leverage the promise of Google Apps.  The hope of increasing security, increasing user productivity, and improving collaboration among users is extremely attractive to many organizations.

Enabling Single Sign On (SSO) function for Google Apps users is a core component of the overall strategy for organizations who intend to rollout Google Apps to its users.

Google requires adherence to the SAML 2.0 specifications in order to enable support for Google Apps SSO.

A variety of access methods are required in order to effectively address the needs of the wide variety of Google Apps Single Sign On use cases that exist in various environments.  One critical option that must be provided lies in the ability to optional support for Form based authentication.

…I built the first 90% myself, but I realized I was never going to figure out the last 10%…” 

One of our clients shared with us recently shared this representative project challenge, after he had tried building his own SAML solution, using ADFS 2.0. 

After working on that SAML solution for some time, he approached us and said: 

“…I got through the first 90% pretty easily.  It was that last 90% that was going to kill me…”

He recently became an SSO Easy client, and went into production in less than 1 week following our initial discussion together.

Like many of customers, this client realized that the best way to address a key project challenge associated with implementing a strategic Single Sign On project is to implement an enterprise SAML product that supports all SAML 2.0 and SAML 1.1 use cases.