There's been some confusion around about what's known as SSO (single sign-on), I want to clarify a couple things, first, the definitions:

SSO (single sign-on)

As the name implies, this functionality allows a user to "sign-in" (a.k.a. authenticate) once and then travel between different applications without being asked again to sign-on.  A variety of applications can participate in SSO, these systems could be on the web, in your enterprise or both - the point is that the systems are linked in such a way that allows the user to not need to re-authenticate.
This mechanism is often implemented with protocols like SAML or the integrated windows authentication system.  In the enterprise world, this is often implemented by creating custom software to speak to the variety of applications and tie membership together (sometimes through their APIs).

Shared Authority

This mechanism allows users to use the same authentication credentials on two or more applications, for example a web application and your desktop (windows) login.  While this mechanism is not quite as seamless as true SSO, it does have many of the benefits, a key benefit being that the user does not have to remember multiple username/password combinations.  Shared authority is often called "SSO" as even though the user must sign-in twice, he will use the same credentials.
This mechanism is often implemented with protocols like LDAP, OpenID or Facebook connect.

Profile Synchronization

Another feature that is sometimes discussed in the same breath as SSO is the ability to synchronize profile information between different applications, while this has nothing to do with authentication, it does have some relationship since LDAP/AD/OpenID/etc. contain information about a user's profile this is a logical next step


As you may know, we've developed our platform's LDAP connector, this will enable your community to connect to an your LDAP server (or a Microsoft Active Directory server) for the purpose of "shared authority".  The LDAP connector will allow a community's membership to login to IGLOO using an LDAP server owned by the community.  The best way to describe what this will provides is to give an example:  if we connect your www.yourcommunity.com community to your active directory server at the office, it will allow the staff to login to your community using the same credentials as you use to login to your desktops every day. 

Oh, and don't worry, we created the LDAP connector to address the current business needs, but in doing so, we've made it easier for us to connect using other authentication mechanisms in the future.