Protect custom settings in managed package but make them available for our mobile app (logical part of the package)

Question

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.

Answer 1

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

Answer 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.