Salesforce IdeaExchange

Integration Comments | Integration Ideas | Force.com Platform Comments | Force.com Platform Ideas

300

API Authentication List

With the ever increasing amount of integration occurring, I feel there needs to be an extra level of authority for accessing Salesforce data via the API. Currently, someone with a bit too much user authority and some basic programming skills could do some destruction if they wanted to. They wouldn't do this manually because it would take too long. However, with a quick script they could delete all their data (if they had delete rights).

It's worth thinking about adding an additional layer of security around accessing the system via the API. Some ideas are:

- An "API Access" permission on the Profile
- An "API User" checkbox on the user record
- An API Authentication List

The last one would be a list of applications that have the authority to access Salesforce via the API. Within that, you could also restrict them to only having read access. I am not sure exactly how this would/should work, but a good reference for this sort of thing is on Flickr. In the picture above, you can see how they do it. For each application, you say whether you want to grant it read, write or delete access. With Salesforce it'd be a bit more complicated, but something along these lines would be good.

With that in place, it'd be great to see things like access history per application.

Also, you could add additional system fields called Created By App and Last Updated By App which would show the application name that was used to create/update a record. This does not replace the current system fields. It only adds to them. The default application with full access would be "Salesforce Client" or you could use the name from the Custom App list. This way, even records created from within the application would be tagged with an App Name in those system fields.

patm 11/28/06	It would be even better if you could specify which users can use which tools through the API. For example I wan all my administrators to use the salesforce data loader and not my standard users, but I want everyone to use the outlook edition.
hemm 11/28/06	After thinking about how this could work some more, here are some additional thoughts: - Every application has its own "application profile". Within this application profile, you can give that application permissions . For example, for each object would have read, create, edit, delete rights. When making calls via the API, the API would assess whether you as a user have rights to do things AND whether the application has those rights. Additionally, you could turn on/off rights to perform other API calls (describe calls, etc.) - Applications would be tied to users or to user profiles. This would basically say which applications a user can use. - Certified applications on the AppExchange would have pre-defined profiles with access to the objects they need. Part of the install process would be tying users/user profiles to the application profile. - And I really like the idea of additional system fields!
CRMfusion_-_GW 11/28/06	I love the application profile concept. If you could also put in a "Session Expires" field in here that would be great. Glenn Wilson - CRMfusion Inc.
PeteD 11/28/06	For next year, we are working both on access controls for client applications and on "white listing", which would allow admins to limit profiles to a specific set of client applications. What we have planned is very similar to what's been described. Keep the comments coming -- It's great to have your input on how these features should work!
mike@cubiccompass.com 11/29/06	I think a boolean checkbox that enables/disables API access would be sufficient to handle the 80% use case. Perhaps managed at both the Profile and User levels (with the Profile setting overriding the User).
hemm 11/30/06	I agree. The checkboxes at the user and profile level would help with API security tremendously and would cover the 80% use case. That would be a quick fix. The Auth list (or something of that nature) would require more time to plan and implement.
patm 12/03/06	The problem with the check boxes is that I want to allow the use of outlook edition - But not Data Loader. Maybe disable API actually allows the same tools that can use PE? But that includes the Excel tool. Do you really want to totally disable the API for some users?
Upside_HQ 01/19/07	What about the possiibility of adding access rights to methods (API Verbs). That way in addition to the applications based profiles proposed by Scott you could have the ability to expose certain verbs and not others. You could even have the concept of "public" verbs and use this to provide your own web-to-lead style authentication free services...
tesii 04/12/07	I would like to see both the checkbox to disable all API access, and also a way to restrict access of certain services that leverage the API. (Outlook/LN connectors, ajax, Dataloader, and even custom services). There will need to be a way to register the services to prevent spoofing another service. In addition, being able to assign a different profile for API access to each User/Profile will provide even more flexiblity.
kesco May 13	We have a need to allow API access for users to use the Outlook Sync plugin, however we want to disable their API access from other applications. Therefore we'd love to see the ability to grant API access only via specific applications. I see all of the comments on this idea are over a year old. Is this idea still being considered? What PeteD mentioned on 11/28/06 sounds like what would help us.
hemm Jul 14	What about something along the lines of how oAuth works where permission is explicitly granted to an application? I assume that the application then gets a token, which represents a login. However, it's very easy to delete that token without disrupting the password of a user and affecting other things.
richard_vanhook Nov 12	My vote is OAuth support.

track comments for this idea

Please log in to post a comment

recently promoted by:

craskulinecz
raver
AlexCRMmanager
kesco
Rusty12
tesii
TheSwami
Upside_HQ
ccrawford
xmlchris
Brian00001
patm
mike@cubiccompass.com
joeydavis65
E.J._Wilburn
The_Fox
PeteD
rpr
jtasaki
CRMfusion_-_GW
PatientKeeper
RikvdW
AC4IdeaExchange
PeterJCooper
Kingsley
mspohn
benjasik
AMartin
Scott_Jorgensen
hemm

Resources

Successforce.com

API Authentication List - Salesforce IdeaExchange

Salesforce IdeaExchange

API Authentication List

Search Community

Categories

1-800-NO-SOFTWARE | Privacy Statement | Security Statement