The problem: I have to allow outside,  non-company users SSO (single sign-on) to a Salesforce Portal and I don’t know how to do this.

These users are external to the company and are not in any repository in the company, they are just in Salesforce as portal users. How can I make this work?

First, about the requirements. These users are people we do business with and the portal is a website Salesforce let’s us create that we expose data and reports to in the way we wish. We provide these users, these partners, with tools and data they need but keep them from accessing our Salesforce Org since they are not part of the company.

Our company uses Microsoft’s Active Directory to manage users and credentials. We SSO to our Orgs using AD and the ADFS (Active Directory Federation Services) product making this duo an IdP (identity provider). Works well and was easy to setup in Salesforce.

Second, the portal users are known in our Salesforce Org and not to our company. The company has a firm set of rules emmanating from our security folks that only company employee’s and contractors are permitted in our AD. Fine.

Third, SSO requires that a user, the principle, is known to something providing identity, his operating system or an app coupled with IdP, and sign onto SSO compliant SPs (service providers) which in this case is the Salesforce portal. But our partners log into their own computers in their own businesses. Possibly with their own ADs but more likely not. They just have small, local networks they sign into and there is no IdP on their end. And that’s the problem in a nutshell, they log into their own networks which are unknown to us. We simply do not have an identify for them that we know about.

What do we do to accomplish our goal?

The answer is we need to rethink our IdP and find another architecture that works. This article provides the solution.

What’s really interesting is there are many products out there that can be used and until I was confronted with this requirement I had no idea just how many there are.

Here’s a picture of what we have right now.

 

We have two authentication paths, Salesforce authenticated by ADFS for internal users and Salesforce Portal authenticated using the Salesforce username and password.

SSO for both paths is simple and requires two more products and some work. It never used to be this simple but it is now. We add an IdP and a private database to handle the external user case. This solves the problem at hand and possibly solves other related problem explained shortly. First, how does this solve our problem?

 

 

 

What do we use for the IdP? This really surprised me. There are quite a few IdP products, both commercial and open source. Wikipedia has a lovely article with an enormous list of just SAML IdP products.

Two examples of open source products are SimpleSAMLphp and Shibboleth. Don’t you love the names?

SimpleSAMLphp is a set of PHP scripts implementing both an IdP and a SP. If it works, WOW.

Shibboleth comes in two flavors, an IdP and a SP. WOW again.

Commercially you have a product like Entrust’s IdentityGuard.

The differences between commercial and open source products can be significant. Commercial products tend to enlarge the boundaries of the problems they solve. IdentityGuard can handle a large variety of credential repositories making it easy to take on all roles for Identity Providers. Open source products tend to be more surgical taking on core needs only. With that said, the array of products is astounding.

So in this case we put the Idp in front of ADFS for internal user identity and the IdP in front of a database for external user identity.

Opening the door for more solutions

Consolidating the interface to all IdP activity to the one IdP product, commercial or open source, permits you to build all your future solutions on this architecture. Seems like a no brainer doesn’t it? Well, you might miss this so lets discuss it a bit more.

First, you can shape programmatic interface to this IdP using your favorite stack. So if your a Java house, a .Net house or something else you’ll develop code and libraries talking to this one IdP rather two or more. This simplfies things today and down the road.

Second, you skew the next SSO requirement to this architecture rather than creating another point solution. Suppose you wanted to interface Salesforce or someother application to an internal web app and SSO from the external app, Salesforce, to the internal app, what would you do? Before this you’d be searchaing for the IdP solution just for it. Now, you think in terms of this architecture and plan the solution where you sso using this IdP.

If this IdP product supports at least one, well known and used protocol like SAML 2.0 you should be in good shape for some time just relying on this. You not only use the IdP product as a solution component you also develop code and processes to take full advantage of this consolidated architecture.

You will develop code to provision new service providers, manage both internal user credentials and external user credentials, and manage how processes use this product. Lots of opportunity to simplify your code base because you’ve moved the SSO and Identity solution from tactical point solutions (ADFS SSO for internal users and username/password external users) to one strategic enterprise solution (SSO for all).

What next?

I may implement a reference architecture just to show to all that this is right and doable. That remains to be seen. For now, I just introduce the concept to you and hope it helps shape your thinking.

Share your thoughts in comments. Cheers!