Single Sign-On (SSO)
Single Sign-On (SSO) is an authentication process that allows a user to access multiple applications through a single log in screen even though each application requires a separate log in. After the initial log in, the user can switch applications without having to log in again. By the same token, when a user logs out, the system logs them out of all the applications at once.
Using SSO for your Socialcast community provides several benefits:
- Authentication – All user passwords are stored in a secure central location on-site, with no access from outside the system. You can easily enforce corporate policies on Socialcast passwords, without having to configure the Socialcast community.
- User Provisioning – SSO automatically creates Socialcast accounts for new users as needed. The first time a company user attempts to access Socialcast, SSO will create a new Socialcast account for that person.
- User Profile Management – Every time a user accesses Socialcast within your environment, SSO updates the user’s Socialcast profile with the most up-to-date information from a central repository. You can exercise even more control over the user’s profile through the use of Directory Integration (LDAP). For keeping the basics in sync, however, SSO is a great alternative.
Note: SSO is not available for Socialcast Free accounts; it is only available for paid communities.
Socialcast SSO requires an Identity Provider in order to work properly. You can use any number of different SSO products including Active Directory ADFS 2.0, Shibboleth, Tivoli, Open SSO, and PingFederate, as long as they support SAML 2.0.
Socialcast SSO does not require a direct connection to the company Identity Provider. If your Identity Provider is deployed behind a standard firewall, Socialcast SSO will continue to work for the Socialcast browser application (see SSO Limitations
How It Works
To take advantage of Socialcast’s SSO feature, you must have an Identity Provider (IdP). When a user attempts to create a Socialcast session, the Identity Provider and the Socialcast Service Provider interact to authenticate the user. Socialcast SSO supports two different user experiences during the log in process: a Service Provider-initiated workflow and an Identity Provider-initiated workflow.
Browser Access (Service Provider Workflow)
During the Service Provider workflow, a user opens a web browser and navigates to their Socialcast community. Before displaying the community, Socialcast redirects the user to their company’s Identity Provider. If the user is already signed into the Identity Provider, then control returns to Socialcast and the community home page appears. If the user is not currently signed in, the Identity Provider prompts the user to log in. After a successful login, the Identity Provider redirects the user to Socialcast, which creates the user’s Socialcast session and takes them to their home screen.
Intranet Access (Identity Provider Flow)
During the Identity Provider flow, the user accesses Socialcast through a link on the company’s intranet. In this case, the intranet directs the user to the company’s Identity Provider first rather than going to Socialcast. If the user already has a session with the Identity Provider, control passes to Socialcast which creates the user’s session and launches the community. If the user has not logged in, the Identity Provider prompts the user for their credentials and then redirects the user to Socialcast. Socialcast, in turn, creates a user session and then displays the user’s home page.
Socialcast provides a number of API client applications that support SSO through the use of OAuth 2.0. These applications include the iOS application, the Android application, the desktop application, and the Reach Extensions. If you have created your own applications using Socialcast’s API, you must implement OAuth 2.0 on the application in order to use Socialcast SSO.
However, if your Identity Provider is deployed behind a firewall or if it requires VPN access, only the clients on your company’s intranet will be able to log in. As a result, Socialcast’s mobile applications will not have access to the Socialcast community, however, Socialcast’s browser application will continue to function.
To self-configure SSO for your community, please see instructions here
If additional help is required, a VMware consultant can be engaged to perform the Socialcast SSO configuration. This process involves a kick-off meeting to review your Socialcast implementation and discuss the requirements of your current Identity Provider. You will need to supply a SAML 2.0 metadata XML file that describes how your Identity Provider is configured. When the consultant has all the required information, they will set up the Socialcast SSO service and ensure that the two different login workflows function properly.
For more information about this consulting service, read the data sheet from VMware Professional Services