1

I am looking at connecting two Salesforce organizations. The issue we are running into, is what these two organizations have access to needs to be completely separate.

We don't want to store login information in one organization, to connect to the other organization.

I was thinking of creating a lightweight REST Api to perform the one specific function we are trying to accomplish.

The organization can then do a Callout to this REST Api to do this specific function on the other organization.

The challenge is around authentication. If I go the standard OAUTH route, then I need a user and I have to worry about the different profile level security etc etc. Then this login information is stored as well.

What if I just create a token that is required in the Rest APEX class, that you cannot use the APEX class without. Then I could make this APEX class public and forgo the OAUTH.

Would this be an absolutely horrible idea? Maybe I'm missing something here.

1

Have you looked at Salesforce to Salesforce? It allows you to set up a connection between two orgs. You still need to do authentication, but the system manages the connection and allows UI-based configuration of objects and fields to synchronize across the orgs. If you need something more complicated, then you'll probably want to look at Named Credentials, which lets you connect via OAuth, and the connection is managed by Salesforce. Yes, you need to worry about field/object security in both orgs, but you should be doing that anyways. I wouldn't recommend making a public endpoint with a "secret token", as this is just rolling your own security, and you're bound to get it wrong. In addition, unless you take some care to hide your secret token, anyone in that org with access to setup can see the token, which is arguably less secure than using a Named Credential or preferably a Salesforce to Salesforce connection.

  • both great answers! I wish I could select both. This is awesome. – takklz Apr 2 '18 at 17:25
  • One thing we are definitely trying to limit, is the ability of and Admin on the source org to get information from the destination org. Does this make sense? Looking at the named credential, I am now worried that any admin could write some apex to use this named credential for whatever they would like. Unless, I completely revoke all access to salesforce except for this rest api apex class. Hmm. – takklz Apr 2 '18 at 19:57
  • @takklz yes, I'd advise Salesforce to Salesforce; whatever permissions you attach to that token can be used, but S2S is a mediated experience. – sfdcfox Apr 2 '18 at 20:20
  • Ok, this makes sense. It then looks like I can programatically determine which records to share via Salesforce to Salesforce. As with other Salesforce features, are there any crazy gotchas around this? Haha – takklz Apr 2 '18 at 20:37
  • @takklz It's a relatively "tame" feature, but there are gotchas. See Guidelines for Using Salesforce to Salesforce for details. – sfdcfox Apr 2 '18 at 20:49
2

I think it is not a great idea.

You have to worry about profile configuration anyway. If you expose your REST API to the unauthenticated public, it's still running in the context of one of your Sites users, which does have a profile and which is completely capable of accidentally disclosing data to which it has access if your Apex is sloppy. So you can't use this as a dodge to get out of security issues, per se.

You're also still storing a secret, it's just a different secret - that token. If you hard-code it, your solution becomes fragile (and the secret's not really hidden). If you don't, you have to do secure secret storage yourself, risking exposing that value to users with the right permissions, instead of using a Named Credential and letting Salesforce worry about the secrecy of your authentication values.

If your token doesn't have a lot of entropy to it or has a small keyspace, an adversary could try to walk the keyspace and brute-force it. Is that likely? Probably not, but why open yourself to that type of attack if you don't have to?

You also lose the ability to review, report on, and take action upon login sessions via OAuth, because there isn't one. That diminishes your visibility on the connection and potentially is a security risk because it's harder to get eyes on any misuse of the connection. This goes double if the Site you're linking the API to is also used to serve a website - how are you going to sort out those logs?

I would recommend using a different solution, specifically, configuring a Named Credential as the target of your callout. This allows Salesforce to handle the hard work of managing your secret values, and also insulates your code against fragility on the endpoint.

  • both great answers! I wish I could select both. This is awesome. – takklz Apr 2 '18 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.