5

We are developing our application as managed package. And there are few custom setting which should not be visible to the client when the package is installed, e.g. Amazon bucket credentials etc. To achieve this we've declared such settings as protected.

This approach works pretty well, but our application also includes mobile app, which communicates with SF using REST API reading/creating/updating data from package data structure.

Despite that mobile app is a part of our application from business and human perspective, for Salesforce it's just some external service trying to access something in client orgs, i.e. SF doesn't treat it as part of the package, of course.

That's why protected custom settings are not available for our mobile app to read. So far we've ended up with using Apex web service to let mobile app read those settings, but it looks like security hole to me.

The question here would be - how could we allow external service which is logically (but not physically) part of our app to access different protected artifacts? What other options except custom webservice do we have? And in general, is there any way to say SF - "Hey, this mobile app should be treated as a part of managed package, don't apply all that protection to it" ?

Any thoughts and ideas would be appreciated.

And thanks in advance for you help.

  • Why are those credentials stored in the managed package instead of server-side? – salesforce-hacker Oct 8 '17 at 17:32
  • @salesforce-hacker Cause our application (i.e. managed package) need to integrate with those external services, that's why it should know credentials. – wesaw Oct 8 '17 at 18:06
3

When you use a managed custom setting in a managed package, as you should in this case, no UI is provided, allowing you to decide who should access those settings and under which circumstances.

It's for you to decide what is and is not a security violation as these settings belong to you and you set the access policy. This is unlike standard objects that belong to the org admin. In that case, you have to respect the data owner's policy. But with managed custom settings in a managed package, you are the data owner.

The Security Review team will point out if you allow managed custom settings to be updated without authentication, or in a clearly bad way based on your threat model. For example, suppose these settings contain an API token that is used to authenticate to a paid service, and you serve this API token back to all end users in the org including those whose job is clearly not to configure the service and who have no need to see it.

But generally speaking, you have great flexibility to define the roles of who should be able to access the token and then enforce that with software interfaces you provide.

That means there is nothing wrong with creating a REST API service to update these settings, as long as the API enforces your own defined policy.

There is also nothing wrong with creating a visualforce page or AuraEnabled controller that updates these settings, again as long as it is in line with your policies.

If you are unsure as to who should be allowed to edit these fields, first figure that out. If you need assistance in coming up with a security policy for your app, you can book an office hour with the security team: https://security.secure.force.com/security/contact/ohours

2

Would making them a public setting but somehow encrypted be an option? Then both your apex and your mobile app could decrypt them as they see fit in runtime. You could also try talking with guys responsible for your appexchange security review, they must have encountered such external service dependencies in the past.

Apex Crypto class

And then, maybe, maybe... if you'll win a deal with particularly big client that would absolutely flood the service you're paying for - you could convince them to inject their own API keys into the setting to not kill your limits/usage? I guess you'd have to encrypt it for them unles you'll come up with regular (encrypted) + override (plaintext) fields.

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.