+ Start a Discussion
TKDudeTKDude 

Using API to validate Session (Single Sign-on)

In order to implement single sign-on between SalesForce and our custom webservices application.  I maintain a map for each user between Salesforce login and the custom application login.

I'm willing to use Salesforce's login as the primary login for the user.  The strategy is to retreive the Salesforce session using an s-control and send it to my custom application which will call getUserInfo() from the server to retrieve the Salesforce LoginId.  If the Id is found in the map, then the Salesforce user is considered authenticated with respect to the custom application.

Here's the problem:

The server cannot call getUserInfo() to a well known Salesforce SOAP endpoint.  The call requires a "serverURL" header parameter.  The only way I can obtain this URL is to pass it along with the session Id to my web service.

There lies the problem... I'm trying to authenticate the client (that he is a valid user in my system)  I cannot trust him to tell me the SOAP endpoint to call getUserInfo(). 

Any hacker worth his salt, will just pass a URL to his own server, which implements getUserInfo().

Of course, there are a few things I can do to improve the situation.  However they require that Salesforce "put in writing and support it forever"
   - I can check that the server URL is to "salesforce.com" domain (this assumption fails if Salesforce is ever going to be installed within an enterprise)
   - Salesforce can suport a "well known, secure" web service call to "decode the session ID" (this is more-or-less required if Salesforce wants to be the authenticator for single sign-on.)

Any suggestions?

 

 

SuperfellSuperfell
ensure the URL is https, ensure the domain part is salesforce.com
TKDudeTKDude

Understood.

I'm taking that this is the "official" statement of Salesforce.com ?

There will _never_ be an API server with url outside of the salesforce.com domain.

SuperfellSuperfell
Nope, not offical, that would at least require Benji to agree with me.

We're aware of the issue you raised, and also aware that the only sensible thing you can do today is what i outlined, and we work really hard to not break existing integrations.