Search
Twitter
« Dallas User Group Meeting | Main | An Essential Data Quality Tool »
Thursday
Apr072011

Authentication Strategy with Ruby

To clear up apparent confusion regarding authentication when connecting to the Force.com database from a Rails 3 app, Quinton Wall posted some really helpful information on force.com yesterday.  He was responding to discussion boards. He lays out 3 scenarios, then gets specific about the technical solution that applies to each.

  • ·  I'm writing a mobile app where information presented is based on the role or profile within Force.com.      

Quinton’s post lays out two options—provide the ability for the app to store user credentials, or use OAuth to delegate out that responsibility. He likes the latter and here is his recommendation:

I would use Omniauth to delegate the OAuth dance, and spend my time building the killer app. I recently wrote how-to on using Omniauth with Rails3 and Httparty to build mobile apps which should get you started. What's more, Cloudspokes recently ran a competition to build a Force.com Omniauth strategy. The winner was Michael Bleigh, the author of Omniauth github project. I'm excited to say Omniauth now includes Force.com support in the official gem! (note: the author missed an important response variable, refresh_token, in the custom strategy. I'm in the process of making a pull request to fix it)

 

  • ·I'm writing a public website or app that presents the same information to everyone.

In this case, the post reminds the user that Force.com doesn’t need to provide information based on specific users. Here is the detail:

Your website or app can connect as a single 'integration' user. Ray Gao's asf-rest-adapter is a good fit for this, you just need to include the integration users credentials in the yaml file, just as you always have with the active-salesforce adapter. Or you could use the OAuth2 username-password flow  (see below) which works very well especially if you want a lightweight REST solution.

 

  • · I'm writing a website or app which contains both public and private (authenticated) information.

This case highlights an application where the ease of configuration and the abilities of a Cloud platform and database show up as distinct advantages. The post details why:

My first requirement would be configure the security settings in the Force.com database to identify public vs. private data. My app or website should not need to know anything about what information is public or private, save for perhaps sections of the site which require authentication (note: this means I am encapsulating authentication details in my apps configuration vs. data views). Keep in mind to make all 'public' information also available to the private roles and profiles you set up. I'll explain why in a bit.

Next, I know my app needs to connect and authenticate. I don't want to have two different strategies for authentication. Again, OAuth is the trick. We can handle this requirement using the integration user strategy described above, but use the Username-Password flow (check out Digging Deeper into OAuth 2.0 for more info) for 'public' access. This approach will allow a visitor to view data as defined by the public roles in the database.

Lastly, whenever a user goes to an authenticated page, we can purge the 'public' token obtained from the Username-Password flow and require the user to login via our Omniauth strategy defined in #1 above. Upon successful login, the user now has access to both the private and public information. (remember we configured our database security to allow the private user profile to see all private and public data)

The nice approach to the strategy described above is that you are always using the one authentication mechanism, OAuth, but adjusting the flow based on the state of the application.

I know you will find this information and the practical way that it is laid out as helpful as I do. “Keep it Simple” is a mantra you find in his posts. He actually attributes that thought to Frank Lloyd Wright, who said, “Think simple” but it is harder than you think! The examples above are a good picture of that mantra. Set aside the information not necessary to the solution—what are the basics—and look at it again with an eye toward a solution instead of the problem.

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.