Sunday, February 12, 2012

Securing Enterprise Application Access : Learning from Salesforce


Securing Enterprise Application Access :  Learning from Salesforce 

1 :  SFDC Tab invokes the following url to access the application :

2 :  Web Request Verification : Load Balancer Level :
(a)  - We need to perform referral check and IP range check

Below is the regular expression to validate legitimate API Partner Server URL servers:
To summarize the above regular expression, it ensures that the URL starts with ‘https://’, followed by a character other than ‘/ ‘ or '?' for 1 or more times, followed by a ‘.’, followed by ‘sales’ or ‘visual.’ followed by ‘force.com/services/SOAP/’, followed by ‘u’ or ‘c’, followed by ‘/’. This will allow:

3 : Delegate the request to validator  (php / javascript / servlet filter ) 
             (a)  we can double-check if request coming from salesforce
           (b) validate the session-id by making a reverse call to SFDC.
                        i. - simply retrieve the UserInfo for that connection and extract the user-id.
                           if there is error condition, then forward to trial page or whatever relevant.verify if the (c) User Authorization : Verify if user-id is registered. (highly recommended by salesforce)
                        iii - another layer of security verify call is initiated by salesforce by using private security certificate from SalesForce
                           Include this certificate in every http / soap call to SFDC from validate.php.

4. Enable SSL in uat-apache

5. Use SalesForce Certificate :
This certificate is meant to identify that the request is coming from salesforce.com, not a specific user.


Your application (endpoint) server's SSL/TLS may be configured to require client certificates (two-way SSL/TLS), in order to validate the identity of the Salesforce server when it takes the role of client to your server. If this is the case, you can download the Salesforce client certificate from the Salesforce application user interface. 

6. Enable SSO (in future) :
Use - Delegated Authentication WSDL

If Single Sign-On (SSO) is enabled for your organization, users who access the API or a desktop client cannot log in to Salesforce unless their IP address is included on your organization's list of trusted IP addresses or on their profile, if their profile has IP address restrictions set. Futhermore, the delegated authentication authority usually handles login lockout policies for users with the “Uses Single Sign-On” permission. However, if the security token is enabled for your organization, then your organization's login lockout settings determine the number of times a user can attempt to log in with an invalid security token before being locked out of Salesforce. For more information, see “Setting Login Restrictions” and “Setting Password Policies” in the online help.




 Just like PHP Toolkit / Java Client API for SalesForce, the ajax toolkit is also very simple to use  http://www.salesforce.com/us/developer/docs/ajax/apex_ajax.pdf

No comments: