With the advent of the Identity Confirmation features in salesforce.com, partners with composite AppExchange applications need to have customers explicitely Trust their external services (only if the composite application uses the API Login() call).
A packaging feature is needed so that the partner can package the required IP address range in the approved package posted to the AppExchange. Since all applications are Certified for security, these IP ranges can be tested by Salesforce.com during the final review process and sanctioned as "trusted".
Upon installation by the customer, the installer wizard could present a confirmation panel to the user indicating that the packaged IP address range will be added to the customer org's Trusted IP addresses.
3 Comments » Posted by mike_kreaden
Posted 12/10/07
Categories: AppExchange App Suggestions, Web Services API, Force.com Platform, AppExchange, Application Distribution
|
SteveBower 12/10/07 |
I asked about this in the discussion boards as well to no http://community.salesforce.com/sforce/board/message?board.id=appexdirectory&...< idea. Steve. |
|
coling 12/21/07 |
Why use the packaging mechanism to address this issue? It just interferes with the upgrade/versioning process (and associated marketing, etc.) for an app. I think a better idea would be for Salesforce.com to set up a central registry of 'trusted' partner IP addresses. In my opinion this is a much more flexible approach. And its independence from app versions etc. would make it easier to manage by Salesforce.com. |
|
hemm 10/13/08 |
I hear what you are saying, but auto whitelisting apps like this could be a problem. Also, many customers may prefer to append their token to the password rather than white listing an IP. This way, a token reset can kill all external apps if they wish to do that. The bigger problem is the idea that Salesforce makes partners ask customers for login credentials in the first place. Salesforce should really look into a mechnism like oAuth to help allow Partners and Customers to "authenticate" with one another without the passing of username/password credentials. |