Identity

This diagram provides a high-level overview of Salesforce Identity Architecture concepts and platform capabilities. This is the fifth and final part of a Salesforce Architecture reference series covering core application and system architecture topics.

Salesforce Identity Architecture (PDF)

Miro Board

The Summer ’13 release brought an interesting new feature in the area of identity management – Multi-Provider Single Sign-On. The general principle being (to my initial reading of the release notes) that a single Salesforce org can perform federated authentication to multiple identity providers. Useful indeed where SSO is desirable but the Salesforce implementation spans multiple IT environments within a single enterprise. For example a subset of the user base may have their identities managed by Active Directory whilst the remainder are Google Apps users and have no AD user principal. Prior to Summer ’13 an org could only be configured as a service provider in relation to a single identity provider (IdP), therefore in the example the Salesforce SSO settings could be configured to point to an ADFS endpoint, enabling authentication by AD but what about the Google Apps users?

So, Summer ’13 seemingly addressed this limitation enabling multiple service provider-to-identity provider relationships to be configured. All this made great sense and appeared to improve the flexibility of a native Salesforce solution. In reality this issue has historically been resolved externally to Salesforce using tools such as Ping, Okta, Janrain etc. which additionally provide extension functionality such as multi-factor authentication, finer grained access control, device access policies, user data replication etc..

The main question I’ve had with Multi-Provider Single Sign-on, since the release notes were published earlier this year, is how the authentication interaction would inform the Salesforce org which IdP to use. Would this be a querystring parameter on the My Domain, additional sub-domain or an additional My Domain perhaps? Note, the SSO process is initially anonymous, accessing a My Domain (e.g. force365blog.my.salesforce.com) allows Salesforce to check for an active SSO configuration and initiate the SSO sequence with the configured IdP. Unfortunately, it would appear that the answer to this question is straightforward, the Multi-Provider SSO functionality is limited to the new Communities functionality. In this context each active SSO configuration can be optionally enabled within a Community, the result of this being an additional button appearing on the Community login page as below.

It therefore becomes possible for Communities users to authenticate against multiple identity providers, internal app users remain limited to a single provider, selected from the active SSO configurations using the Authentication Service field on the My Domain page. Hopefully a future release will extend this functionality to internal app users. In the meantime the SSO documentation needs to clearly define the context of this functionality, i.e. Communities only. If I’ve missed something here, I’d appreciate a correction..

Winter ’14 Update (thanks to Leon de Beer)
With Winter ’14 it is now possible to enable multiple Authentication Services for a My Domain via Login Page branding. In doing so Service Provider Initiated SSO (SPI) no longer functions in a seamless manner, instead an Authentication Service selection page is displayed. If the “Login Page” Authentication Serivice is enabled then the login page is shown with buttons for each additional enabled service, if not then just the buttons are displayed on an otherwise empty page. So Winter ’14 opens up Multi-Provider SSO to internal users, however I don’t currently see a way to drive the automated selection of a specific Authentication Service such that SPI SSO can work in the case where multiple services are enabled.