I am working on a salesforce feature, where we are trying to expose a single web Service method in a custom class to a "Partner" so they can generate leads.
The class/method has been created/tested and functions as expects, so we are working on implementation.
I have been poring over all of Salesforce's Web Service documentation and cookbook recipes, but everything I see only talks about using either the Enterprise or Partner WSDL files, which would give them more access then I believe should be required.
If I import the WSDL file that is generated off the class itself, I have access to the methods, but I can't seem to find any way to log in (using their examples as reference).
I have 2 basic questions here.
- Do I really need to give full access to my instance to expose a single method?
- What is the bare minimum I need to provide?
The WSDL itself is just a definition of the web service and does not control actual access to your org. To get access to your org, a session id must be included in each request to the web service. Session ids are tied to a given user in your org, so you can also control what they can access by giving them their own profile and locking down access to only what they need to get to. The profiles are associated with objects/fields, not the web services themselves, think about what they will need to access in terms of data, because they could always use that same session to access other web services. There are also Apex class-level access controls on the profile, but this doesn't stop them from doing the same data operations through the SOAP APIs, so make sure you have their profile only expose what they need access to and that will be enforced everywhere.
As far as obtaining the session id, it somewhat depends on how you are interfacing with them and what their application is like. In general, the recommended way is to use OAuth (called "Remote Access" in Salesforce Help), which will make it so usernames and passwords don't have to be used in their application, but are rather sent directly to Salesforce by the end user. There are a few different flows to choose from depending on the app and are explained in Help. The REST API doc has a nice intro to using OAuht to get the session id (aka "token" in OAuth). Speaking of REST, you might even consider using the new Apex REST API, which allows you to make similar custom web services from Apex, but with REST interfaces.
The Partner and Enterprise APIs also have a login() method, which is convenient since it is also SOAP-based, but is losing favor because the app has to directly handle the username and password. If you do this option, you would login with either the Partner and Enterprise API, get the session id, and then switch over to your custom web service. So, yes, for this option you would have to consume both your WSDL and either the Partner or Enterprise WSDL, and just ignore the other methods, but again, the methods just being there does not mean they can access them (e.g. if you remove Delete from their profile for a given object type, they would not be able to use the delete() method for it).
What you provide, and what they can do are 2 separate things, if you give them a users credentials, then they can do anything the user can do regardless of which WSDL they use. So you'll want to create a user with restricted permissions that has the bare minimum rights to do what you want.
Once you've got that, it doesn't matter if you give them the enterprise, partner or a custom WSDL.
If you give them the apex class WSDL, then they'll need some way to login, which could be login from the partner WSDL, one of the OAuth2 flows, or a webtab or custom link. (depending on the exact scenario).
Finally, have you seen the web2lead feature, that allows for leads to be created in your salesforce account without needing a WSDL or credentials.
