How to roll your own authentication for an external Salesforce App?

Question

Background

If you're building an app, that involves

1. Doing some very basic actions on behalf of non-Salesforce users, i.e. creating a Quote
2. Is hosted externally (in other words, not APEX, but rather PHP, or Node.JS Heroku app)
3. Requires some basic authentication for the non-Salesforce users (username and credentials stored in salesforce)
4. Doesn't violate Salesforce Terms of Service

What's the quickest route to build that app, and what best practices should be employed to develop fast and securely?

Inspiration

After reading this question and running into this sort of app architecture several times myself, felt like this would be great to get the voice of the community on.

Answer 1

The key to solving this problem lies in two parts:

1. Having a dedicated SF User to handle all requests from your 3rd Party to SFDC
2. Creating your own User DB + Code to that verifies your 3rd Party user credentials. Once verified, they will then have access to the SF User. The extra code you'll have to write is to manage what kind of processes you want to expose to/from SFDC.

(Essentially, I am saying to write code that creates and manages your own SessionId -- roll your own "oAuth" (it's not that hard and quite empowering))

I wrote a watered-down version of what you are looking for (but it's managed on SF). What I did was create a Custom Object called Portal__c that stores Site information as well as User and Session information (in different Record Types).

Then, I wrote a class called Portal that manages all of my user activity in its static methods. On top of that, as an instance, Portal acts as a pseudo-controller that gathers Portal, User, and Session information from a Cookie I create when a user logs in. (This way, my Site doesn't use URL Parameters to determine which User is logged in -- the UserId and SessionId are "hidden" in the Cookie.)

After the backend work was completed, I could then build my VF Pages. This is where I decide what parts of the SFDC I want to expose to my 3rd Party (my Site Users). I wrote the Portal code so it's a breeze to login, register, gather User/Session/Portal data, and verify the Session in my VF controllers. (I also added methods like

public static pageReference Portal.getPortalPage(Portal.Page myEnum){...}

to stream-line page Navigation in my Site [as well as limit which Site pages are accessible]. Also, I created a basic Session History tracking mechanism. The sky's the limit!)

Note that my creation follows the schema of my solution:

1. My dedicated SF User is a "Site User" that SF automatically creates for site users
2. The real meat & potatos -- creating Portal__c to manage Portal/User/Session data and creating the Portal class were the key to my problem, and this is where the real work takes place. As my example shows, it can be done completely in SF, and it is not difficult to abstract this to a different platform

---

I elaborate in more detail here:

SSO of a force.com site with another force.com site in same org

Answer 2

Don't take this as gospel, but if your users 'own' data in Salesforce then they need licences. If however, your users can submit quotes but don't need to own the data as such, then you can use an integration user, i.e. one user you setup and use in the connecting application which submits requests on behalf of all users.

I've created this exact setup using Node.js on Heroku, using nForce to manage the connection to the salesforce org. You simply create a connected app in Salesforce and put the app details into an config JSON object that nForce uses. You can use the username/password flow which means you just have the username, password and token stored in the Heroku code itself. For the end-user authentication you could roll your own or use something like Twitter/FB authentication managed by the Heroku app.

Answer 3

Users that use the system need to have a license. Custom authentication schemes are against the rules. However, it's very easy to be in compliance, although it will probably cost you a little bit in terms of service fees. Consider a Chatter Plus (or Chatter Only) license type-- they're intended for light user access and are inexpensive.

You can also review the other types of licenses available in Help & Training-- one of those might be more suitable for what you're trying to do (e.g. Partner Portal licenses, which come in packs of 5 for about $1500/year, or $25/user/month, last I heard). Licenses can start as low as $5/user/month or less, depending on the exact features you need. Most licenses include optional API access at no additional cost (API is an all-or-none feature, not per license).

It sounds like you simply need some Chatter Only licenses. Of course, since you want your code to be external, you'll probably be using Salesforce Identity to have the users log in through OAuth; this is deadly simple to implement in modern languages such as PHP. Heroku can be a no-brainer if your development skill set lies in Java or Ruby, since the templates for the page are git-cloned when you start a new app, literally leaving you with nothing to do but build logic and UI, with all the basic dependencies built-in and resolved ahead of time. Of course, with REST, it'd be pretty easy to do this all in normal PHP if you have your own server available.

Answer 4

Ok, so not only can you utilize a oAuth2 / chatter license authentication system to authenticate users on your site to SF and provide your application with a session limited access token to data scoped to the user that just logged in, you can also do the following:

Utilize an api (only) account that maintains a constant connection between your application and your Salesforce org. This is accomplished by using a server-side oAuth flow and will establish a set of credentials your application can utilize to query SF. Once you have established this connection your workflow would look like this:

End user visits website and enters credentials Your application accepts the credentials from the user, and submits a query to salesforce using your previously established connection. It's important to note that you should probably construct this query to match on username AND password (hashed accordingly ... because you are hashing AND salting passwords, Right?) 0 rows = invalid password. 1 row = valid password, 2+ rows = you're doing hashing wrong.

At this point, you've now established that the end user is, (or is not) in possession of a valid username and password which, if you've done the query right will also give you the Id of the object you were querying. I'm assuming that you'll want that Id to do other kinds of work.

All that said -- THIS IS THE WRONG WAY TO DO IT, PLEASE DON'T DO THAT. --

Let me say that again. -- DO NOT DO IT THE WAY DESCRIBED ABOVE --

To do so is to leverage almost NONE of the platform's rich and vibrant feature set, it's security and permissions features and is incredibly limiting, and prone to data-f'd-up-ness.

If you are building an application where users will be allowed to login and then access Salesforce data, let salesforce be the manager of Identity and Authentication and piggy back your application on it. In the inspiration question, the user should oauth each user to SF, and accept the salesforce asserted identity id as a FK lookup to the local user table. Ie: SF user abc1234567890defgh returned as part of the oAuth hash is matched to local user 'Awesome User'. That oAuth access token should be used for that users' data access.

Yes, this requires a change in thinking and architecture, but is safer from both a security and data sanity aspect.

Answer 5

Ralph,

I think the easiest/best way to do this authentication bit, would be to rely on the oAuth Authentication services provided by salesforce. I can only speak in depth to the Ruby side of things but I am sure there are node and php analogs.

Rails has an add-on gem called "Devise" and another called "OmniAuth" you can use OmniAuth by itself -- there's a OmniAuth-Salesforce provider pre made in fact -- or you can couple it with devise for a pre-build set of routes etc.

If you go this route, you'll need to create a "connected app" in your org, with oAuth info. These two keys (consumer key, secret key) will be needed by your external portal to start the oAuth flow.

Once you've completed the oAuth flow against Salesforce with an authenticated user (even chatter free) you'll get back the refresh, and access tokens as well as the user GUID (18 character id) that you can use to query against your external db model on a 1:1 lookup to match SFDC user to Local user.

If you have questions I can probably stand up an example rails app pretty quickly using OmniAuth to salesforce.

Additionally, if you chose to go down the enlightened ruby path, I can help you get setup with RestForce, a ruby Gem that provides brilliant sObject api access.

Answer 6

Use JWT Bearer Token Flow to authenticate the remote host into Salesforce as a community user.

http://doingpoorly.blogspot.com/2014/11/jwt-bearer-token-flow-can-be-used-for.html