What user to login to Salesforce with in a connected app that monitors the realtime API

Question

I'm developing a connected app that will be available in the App Exchange. I'm struggling to understand what user my app should connect to Salesforce as. The app has a component that monitors the realtime API for events. This process needs to run continuously.

My remote service is NodeJS and I'm utilizing the NForce library to connect to PushTopics on the Streaming API. I'm monitoring for inserts and updates on certain objects, e.g. Opportunities.

If a new org installs my app from the App Exchange, do I use my existing system user to monitor the new org or do I create a new user for the new org? If I create a new user what is the sequence of steps from app install to my remote application connecting to the realtime API?

I've started working on an APEX post install script that creates a user and sets a password. That way I will have a user in the org that I can use. I'm planning to use an Apex callout to trigger my application to connect to the realtime API with the newly created user.

I'm concerned that this is the wrong approach and might be rejected by Salesforce on security grounds.

Post install script:

global class PostInstallClass implements InstallHandler {

  String Password = 'pword' ;   

  global void onInstall(InstallContext context) {
  if(context.previousVersion() == null) {
    User u = new User();

    u.username = 'uname.com';
    u.email = 'email.com';
    u.lastName = 'lname';
    u.firstName = 'fname';
    u.alias = 'alias';
    u.languagelocalekey = 'en_US';
    u.localesidkey = 'en_US';
    u.emailEncodingKey = 'UTF-8';
    u.timeZoneSidKey = 'America/Los_Angeles';
    u.profileId = '00ei00000013M1P';
    insert u;

    system.setPassword(u.id, Password);

    pushData(context.organizationId(), context.installerId()) ;
 }
}

Answer 1

Connected Apps require your subscriber (your customer) to go through a oAuth authentication flow (with a user of their choice) to allow your application to connect to their org. You cannot and should not attempt to cicrumvent this process for a variety of reasons, most of which security based as you hint at in your question. This however does not mean you cannot implement what you need, you just need to ensure a user goes through this process and that you receive the oAuth token. After that you can use the token in a 'headless' way to monitor activties via the Salesforce API in the subscriber org.

Connected App Architecture? You don't state what technology your building your Connected App in, however Salesforce provide a number of SDK's to help you perform the oAuth authentication flow from within a Java environment, there are a number of articles on this, using Heroku to host your application. In this case you may have a web worker process and a number of background workers perhaps. Also worth looking at is the Salesforce Streaming API which is ideal for monitoring events in orgs.

Native Architecture. Have you considered building a native solution? This runs completely in the Force.com platform and does not require any external configuration or management by yourself. You've not really stated what you want to monitor, so the limits of what Apex (the platforms native language) can see might prevent this. But you might be able to achieve what you want via an Apex Scheduled job perhaps? This again must be run by a designated existing user in the subscriber org, though in this case their is no authentication flow to deal with as the solution is already hosted on the platform.

Hope this helps!

Answer 2

You can't actually create a user and specify a password for it so you're going to run into a dead end right there.

It sounds like the real time API will be running on the clients' orgs and you'll be connecting to those to consume data. If that's the case then things are definitely going to get complicated. You can not create a new user in the client org, doing so would pose a security risk plus would cost the client as well for a new licence.

If that is what you're thinking, then you're going to have to consider a different approach, most likely with the client orgs making callouts to a webservice to push data out. There will still be install steps involved with that like having the user authorise end points.

If I'm way off base with all this I think you're going to have to edit your question to clarify the setup.