2

We're writing an internal Apex REST webservice to accept POST requests from an external system to call. The kink here is that we cannot control the process in which the external system calls our webservice.

So we cannot have the external service authorize, get a token, then use that token to use our webservice and POST data into Salesforce. I've googled without much success, is there a way to maintain a "permanent" (quotes intended) token or a way to have a constant authorization instead of fetching a token each time (as we can't do that)?

I'm a noob on the security aspects and OAuth processes here. Thanks all.

Improve this question
1
  • 1
    I am not an expert on these things but could you do something like this: Set up a public webservice using sites and let your external system call this webservice and pass in some permanent unique number and your public webservice validates this and if it matches it will invoke the actual webservice and return the results. Like I mentioned, I am not an expert and I am sure others will have better solutions than this.
    – javanoob
    Commented Mar 11, 2016 at 17:15

1 Answer 1

Reset to default
2

There's several things you could do, assuming you don't mind the resources involved.

ESB

An Enterprise Service Bus application is something you (typically) install inside your network, and it acts as a proxy to transform data from one format to another. For example, we use Neuron ESB (note: this is not a product endorsement, so please do research before selecting a product) to transform requests to a local endpoint to a salesforce.com endpoint. It generally works like this: the external program makes a normal call to the ESB endpoint, the ESB either authenticates or reuses an existing token, proxies the call forward to salesforce.com, gets the response back, and transparently passes that back to the original caller. There's probably some web-based services that can do this for you, as well.

Costs: Licensing, Hardware

Public REST

You can set up a Site, configure the guest user profile to allow access to certain classes (of the @RestResource variety), and then call that endpoint through the public URL. You can, of course, introduce your own custom security, but be aware that you're possibly circumventing normal security measures, so this does have a potential drawback. Consider this option carefully, because if anyone discovers the endpoint, they could potentially post false data.

Costs: Potential Security Risks

Internal Proxy

You can roll your own proxy, much like a ESB, probably in about fifty lines of code if you use something like Node.JS. While I haven't specifically tried this, I would imagine that any developer with reasonable experience and a bit of Googling should be able to set up something up. I'd probably use the web-server OAuth flow in my code, so there'd be an initial one-time set-up cost to get a refresh token, and then your NodeJS proxy can repeatedly refresh as often as it wants until the refresh token is revoked (potentially never if configured correctly). Using refresh tokens even survives password reset/changes and user name changes, so the upfront initial investment in a refresh token can save time down the road. Remember to build in some sort of notification system in case the refresh token goes away.

Costs: Development, Hardware

Improve this answer
1
  • thanks for the supremely thorough response. It appears for our purposes we may explore the Public REST and then experiment with improving security from there.
    – GeorgeA
    Commented Mar 14, 2016 at 15:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .