Contact Us
Recently I came across a client who wanted to provision the Salesforce user on their system, the criteria was to allow the target system to push data from their end without the use of Salesforce Session Id. This problem was unique such that the target system does not have any username password stored in their system so the problem requires some thought. I decided that I will create a POC that will allow the target system to be able to talk to Salesforce. One point to note here is that the target system has to be from a trusted organization and should require user’s approval.
The first thing that people would discuss is to make use of SSO, this my colleague Vilas have blogged earlier. I on another hand have taken another approach that to make use of Oauth 2.0 on Force.com it involves making use of Remote Access functionality. I will go through the exact steps to establish the initial handshake and thereby have target application push data to Salesforce. The target application will be written in C#.
The first step here is to set up the Remote Access, I have covered the Consumer Key but an entry here will provide a Consumer Key and Consumer Secret.
Step 1
Navigate to
Setup -> App Setup -> Remote Access
Step 2
I then went ahead and created a Visual Force page called Admin Screen:
Here I have created two different buttons, one that will open a separate window using javascript and another that will open a tab and make use of the PageReference, both performing similar functionality.
Visual Force Page for the Admin Screen
Step 3
Admin Screen Controller
The code reference above provides two links, one that calls VisitConcur, on Click of that button the url will include isNewUser=true and sessionId is passed to the target website.
I have inserted a breakpoint where the session id is captured, and if it is a newUser, the GetRefreshToken(); function is called, this will inadvertently ask the user to insert the Salesforce username/password:
Step 4
Target Web site
Target Website (written in C#)
Step 5
Insertion of Salesforce Username/Password
On insertion of Salesforce username/password, the user will be prompted to the user to all the target application to be trusted:
Step 6
User prompted to trust the target website
Once the user clicks on Allow will send the control back to the Target website and this time the call back script that I have created will have the access and refresh token that will allow the target application to push data to Salesforce:
Step 8
Access / Refresh Token
Access / Refresh Token in Debug Mode
Target Website ASPX page
Call back script in code behind
Onload of the page, the javascript function CallServer is called passing in the url that contains the access and refresh token and its context (i.e. alert in this case).
Step 9
Now that we have the access and refresh token retrieved, we can make use of the access token to make API calls to Salesforce and retrieve or push data to Salesforce under the user’s credentials:
The URI here can be concatenated with token.instance_url + “/services/data/v20.0/query” and then we create a soql query to retrieve opportunities or any other object within Salesforce.
Post or Get information from Salesforce
Step 10
Refresh Token to retrieve access token
Finally there is one more point to note here, if the access token expires we can make use of the old refresh token to get a new access token without the user having to enter their username and password again. Instead of passing the access code we pass the refresh token, and pass the grant type as refreshToken instead of authorization_code. The function will return the new access token that we can make use of to communicate with Salesforce.
For more information visit:
http://wiki.developerforce.com/index.php/Digging_Deeper_into_OAuth_2.0_on_Force.com
