No image

Social SharePoint: The case for Social Authentication

When people speak about SharePoint as a social platform, they usually have the social features of SharePoint in mind. For instance, they think of user profiles and feeds (exposed through “My Sites” in SharePoint Servers) or the Facebook-like features implemented by third-party vendors such as NewsGator, Bamboo Solutions and others. In some cases, they would also mention cloud vendors such as Yammer, VMWare (with SocialCast), Neudesic (with XXX) and Tibco (with Tibbr) that all aim at making SharePoint more “social”.

In fact, the social features of SharePoint have already been discussed at length on many blogs and I would probably add little value if I wanted to share my 2 cents on this aspect of Social SharePoint.

That’s why I’d like to take a different approach today and make the case for another aspect of SharePoint, which I call “Social Authentication” (or more generally “Cloud Authentication”), which is simply the ability to connect to a SharePoint site with social accounts (such as Windows Live, Yahoo!, Facebook, LinkedIn, Yammer, Google, Twitter, etc) or cloud accounts (such as Office365/Windows Azure Active Directory).

I don’t pretend to be the first one to speak about this social aspect of SharePoint. As a matter of fact, there are quite a few blogs out there that have discussed the technical aspects of Social Authentication in SharePoint, and some (such as Steve Peschka’s blog) are among the Top 10 in the SharePoint blogosphere.

However, although technical details abound (mostly referring to the integration with Windows Azure ACS which I personally think is quite poor – a subject for another blog post, for sure), few actually take the time to explore the possible scenarios that Social Authentication can unlock and focus on the technical details of the implementation. I have yet to see a blog post that shows the value of using social accounts to connect to a SharePoint site. So here is a non-exhaustive list of scenarios that I think can make sense and open the door to new usages of SharePoint – mostly (if not only) outside of the firewall:

1. Partner, Vendor or Customer Extranets

Deploying a SharePoint extranet to improve communication and collaboration with partners, vendors, customers or contractors presents a unique challenge: how can these external users sign in through SharePoint? SharePoint natively integrates with Active Directory, but many organizations realize that the constraints of Active Directory don’t usually match with the business requirements usually associated with external-facing, authenticated sites (on-the-fly user provisioning, delegated administration, self-service capabilities such as password reset, online registration, etc…).
Today, a vast majority of these types of extranets are thus implemented with the now famous “FBA” (for “Forms-based Authentication”) functionaliy available since the SharePoint 2007 release. Some organizations leverage an existing directory of external users (such as an LDAP directory separate from the corporate Active Directory), but many don’t have any such directory and must create it from scratch.

Quite a few solutions are available that neatly integrate user management (usually backed by a SQL Server database) with SharePoint and automate the complex deployment steps associated with setting up FBA on SharePoint (our own Extradium for SharePoint is one of them).

But all share common pitfalls that affect both administrators and end users:

  • No matter how easy and flexible an FBA solution might be, someone still has to manage external accounts and take care of a few unavoidable tasks (such as unlocking or disabling/re-enabling accounts). This clearly is a productivity killer, especially as those actions typically must be handled on the spot, thereby disrupting the work flow of user managers.
  • Each external user must create and/or remember yet another login and password pair (as if she didn’t have enough of them already). In many cases, she will likely use the same email address and/or password she uses on other sites and thus increase the probability of compromising all of her accounts if only one of them happens to be cracked or leaked. Oftentimes, users also rely on files to store the clear text credentials of those accounts they typically use quite infrequently. As those “local” accounts get created over and over in multiple systems, the security risk becomes more and more important, for users and companies alike.

In contrast, there are multiple benefits associated with the use of social or cloud accounts for partner, vendor or customer extranets (from now on, I will refer to those partners, vendors and customers as “trusted parties”) :

  • Administrators can free themselves of the burden of user administration and can focus their time and energy on tasks more valuable to them and to their organizations.
  • Users get to use accounts they are familiar with and don’t need to store in clear-text files
  • If a social account gets compromised, the likelihood that the account owner will quickly realize it is much higher than if she has multiple, decentralized accounts she rarely uses. This in turn reduces the likelihood of illegitimate accesses to your SharePoint extranet.

If you choose to leverage cloud accounts stored in Windows Azure Active Directory, you get added setup and security benefits:

  • You avoid the political and technical headache of setting up a trust between your Active Directory and each of your trusted parties’ Active Directory. It will probably be much more acceptable for companies to establish a single trust with Windows Azure Active Directory and then grant specific applications (such as your SharePoint extranet) access to their “cloud” version of Active Directory.
  • As soon as your trusted parties add accounts, those accounts can sign in on your SharePoint site (they don’t necessarily get access permissions though). Conversely, when user accounts are disabled or deleted (for instance, when an employee leaves her job), those users stop having access to your SharePoint extranet. That’s an obvious benefit of identify federation, of course.
  • 2. Secure Collaboration Sites for Online Communities

    The rise of online communities in recent years has been unprecedented. LinkedIn groups are now hugely popular, while external Yammer networks (such as SPYam) garner more and more attention as organizations realize they must embrace the social wave. Yet, those communities don’t provide a satisfactory collaboration platform where community members can securely share and collaborate on documents and structured data sets (such as lists of events, contacts, tasks, etc).

    Because those social networks expose valuable user information such as group memberships (through their OAuth API), it is relatively to imagine that a state-of-the-art collaboration platform such as SharePoint can leverage such information (conveyed through “claims”) and automatically grant access to a specific SharePoint site, dedicated to that community.

    This is exactly what we’ve achieved with the SPYam collaboration site hosted at : while the site looks like an anonymous site, most of its content can only be accessed by members of the SPYamYammer network. If they sign in with their Yammer credentials, the SharePoint site will automatically grant them contribute permissions, simply based on the fact that they belong to the SPYam network. We’ll go over the technical details of how we managed to build such a dynamic, claims-based authentication and authorization platform in a later blog post, but suffice it to say that the main building blocks were theSocialConnekt Identity Server and our upcoming SocialConnekt for SharePoint product, which provides user registration and approval features, along with a claims-based authorization rules engine.

    In the same vein, you could imagine a SharePoint platform where LinkedIn group owners could create a dedicated site to be used by their group members only. Because LinkedIn shares both group memberships and member roles through its OAuth API, group owners could automatically be site collection administrators, group managers would be granted site owner permissions, while group members would be simple contributors.

    There are at least two main benefits to this novel usage scenario:

    • From the end user’s perspective, the sign in experience is completely seamless as he could easily navigate between the SharePoint site and the LinkedIn group with the same web identity, without the need to sign in with different credentials.
    • From the administrator’s perspective, the SharePoint platform enforces that only accredited users (ie. users who are members of the online community) have indeed access to the SharePoint site. This dramatically decreases the management efforts that would otherwise be required with a platform not able to leverage social claims.

    3. Web Marketing Initiatives on SharePoint-based web sites

    More and more external-facing web sites are built on the SharePoint platform. Yet, when it comes to their web marketing efforts (such as enticing a user to download a whitepaper in exchange for some information about the user), most of those web sites rely on traditional techniques such as long and boring contact information forms, which are well-known for significantly decreasing conversion rates. Furthermore, the locations of those whitepapers are typically not secured, and a clever use of a search engine can often help a user to circumvent the contact form and download the whitepaper without ever giving any information about him- or herself.

    Since requiring the user to create an account just for the sake of letting him download a whitepaper is inconceivable, using social networks seems like a good compromise:

    • Users no longer have to fill out tedious forms
    • Web marketers are able to get more reliable information about registering users
    • Whitepaper locations can be secured and made only accessible to users who are willing to sign in with a social account
    • While you might question why people would like to sign with a social account on a public web site, knowing that they are going to share potentially private information about themselves, you will be surprised to know that a recent study by Blue ResearchConsumer Perceptions of Online Registration and Social Login, showed that in 2011 41% of Internet users preferred to use a social account vs. 35% who preferred to create a new account. In 2010, only 28% favored social login, which shows a clear trend towards using social accounts in a more pervasive way.

      Interestingly, when asked to provide personal information through a registration form, 88% of survey respondents admitted they give incomplete or incorrect information. This is in stark contrast with the (usually) accurate information that can be gathered from social networks, especially those with rich profile data (such as Facebook, LinkedIn and Yahoo!).

      There are probably other scenarios that we haven’t thought of, but these are the ones that keep me awake these days. We are currently working hard on SocialConnekt for SharePoint to make those scenarios a reality very soon.

      Meanwhile, if you’d like to let us what you think or work with us on an early deployment, please contact us at or on our Contact Page.

      facebooktwitterredditlinkedinmailby feather