SSO Easy Blog

Not too many users are aware that when they sign on to their Windows desktop in the morning, by providing their main ID and Password to the machine, they are generating accessing a Windows security function called IWA.

Google Apps is being rolled out to many of these same users, and, for a variety of reasons, Single Sign On (SSO) function is needed or wanted for those users.  Google requires implementation of the SAML 2.0 standards protocol in order to enable Single Sign On to Google Apps.

More and more organizations desire the option of leveraging the IWA security information that is generated by the user when login to the Windows desktop is completed as the main mechanism for enabling SSO support to Google Apps.

If you enjoyed this post, make sure you subscribe to our RSS feed!

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.

If you enjoyed this post, make sure you subscribe to our RSS feed!

SAML 2.0 – Who wants to learn 1300 pages of the SAML 2.0 Spec?

Many clients don’t realize that the SAML 2.0 Specification document is about 1300 pages long. 

Whether their environment is based on ASP.net, Java / J2EE, or another technical platform, SAML based Single Sign On projects using either SAML 2.0 or SAML 1.1 can be a nightmare. 

In addition to the 1300 page specification, there are lots of logical interdependencies,, so you have to become a master of the in’s and out’s of the entire doc in order to effectively implement a SAML solution.

SSO Easy has built all of that SAML intelligence into our turnkey SAML product solution.  Out-of-the-box support is provided for .net and Java / J2EE platforms.

The result – you don’t have to become a SAML 2.0 expert in order to implement your SAML solution.  SSO Easy’s EasyConnect SAML solution abstracts you from the SAML 2.0 complexity.  You don’t have to be a SAML 2.0 expert to implement your SAML solution if you use SSO Easy’s Enterprise SAML product. 

Those project deployments are now easy to complete.

If you enjoyed this post, make sure you subscribe to our RSS feed!

The good news:

• ADFS 2.0 now supports SAML 2.0.
• As a result, the demand for SAML Single Sign On (SSO) deployments is rapidly growing.

The bad news:

• SAML 2.0 is still difficult to implement,
  • Especially for certain use cases, and
  • Especially for complex SAML deployments.

• SAML 1.1 demand continues to grow along with the demand for SAML 2.0

SSO Easy’s EasyConnect SAML solution offers a number of significant advantages over ADFS 2.0 for SAML 2.0 and SAML 1.1 deployments, including:

• No Coding required – rich out of the box SAML function
• Integration – rich out of the box integration, including support for both .net and JAVA/J2EE applications
• Multiple SAML Connection Support – designed and built to enable and support enterprise SAML needs, including easy configuration and management of multiple SAML connections
• Flexibility – easy to enable and support varied SAML use cases, including easy enablement of both IDP and SP use cases
• SAML 1.1 Support – with EasyConnect, both SAML 1.1 and SAML 2.0 use cases are supported using the same EasyConnect implementation.  (With ADFS 2.0, there is no support for SAML 1.1 use cases.)

If you enjoyed this post, make sure you subscribe to our RSS feed!

Few users are aware that when they sign on to their Windows desktop in the morning, by providing their main ID and Password to the machine, they are generating a security token.  That security token is known as a Kerberos ticket.

Many of these same users, and countless more to come in the future, are using Google Apps.

Google Apps offers the promise of cost savings for the organization, while providing the potential to increase user productivity and improve sharing of information among users through the organization.

The promise of Google Apps can only become reality, however, is user adoption is very high.  Providing Single Sign On support for

Google Apps users dramatically increases user adoption, and helps ensure that the goals of a Google Apps implementation will be realized.

In order for an organization to provide SSO function to Google Apps, Google requires adherence to the SAML 2.0 specification and standards protocol.

As an attractive implementation option, more and more organizations are embracing the optional model of leveraging the Kerberos ticket that users generate when logging on their Windows machine each morning, as a preferred mechanism for enabling seamless SSO support to Google Apps.

If you enjoyed this post, make sure you subscribe to our RSS feed!

Integrated Windows Authentication is a Microsoft security product.  When users login to a Windows desktop each morning, providing their ID and Password, Microsoft’s Integrated Windows Authentication security product helps to manage the process.

More and more Windows users are using Google Apps, and most organizations that are implementing Google Apps are also looking to provide support for Single Sign On (SSO) function to Google Apps for their users.

Adherence to the SAML 2.0 standards protocol is required by Google in order to facilitate support for SSO to Google Apps.

As an optional deployment solution, many organizations desire to leverage the security information that is captured by Microsoft’s Integrated Windows Authentication security product as the means by which they can trigger SSO for its users accessing Google Apps.

If you enjoyed this post, make sure you subscribe to our RSS feed!