0

I am developing a native Android app that must interact with a Salesforce org through a SOAP API. Currently, for users of the app to login, they must provide a security token alongside their username and password. This makes the login/signup process uncomfortably long and complicated. As far as I can see, the only solution is to whitelist every IP address in my Salesforce org. I would have thought this is a security issue, so I was wondering if there was a better solution.

As far as I can tell, one solution could be to configure my app to log in through a proxy, and then just whitelist the address of that proxy. It was while researching this that I found this https://serverfault.com/questions/514716/whats-the-minimum-required-squid-config-to-make-a-public-proxy-server that made me think that perhaps there is some other more established way to do this, that I am not aware of.

Basically, my question is, is there any way for an android app running on any phone to make requests to an external API that all appear to come from one IP address (possibly through a proxy server) (without doing anything "dodgy")?

uptonogood
  • 113
  • 2

2 Answers2

1

Looks like you're solving wrong problem. Why do you want to bypass SF security features so badly.

Try logging in to SF using REST, not SOAP. The session id you'll receive can be used in any API. So if you log in with OAuth2 you might not need security token. You'd need consumer id and secret (but that's just a pair of values you securely generate in SF, not bound to any particular user. You can even use production's values to login to sandboxes).

There's A LOT of reading if you want to do it right. And some prerequisite step of creating a "Connected App". If possible check if your Android library doesn't have something built-in for OAuth logins (to SF, Gmail, Facebook, LinkedIn, Twitter... you can find OAuth/OpenId in few places)

If you want pure background connection without user realising he's communicating with Salesforce - probably the "Username and password" OAuth flow is best for you. That should be minimal changes in your code compared to SOAP login call. It's weak in a sense you still need to have a password (either user's password or some dedicated integration account) - but there's chance that no security token will be needed. Give it a go (examples below) and check user's login history for errors.

If your users have proper SF accounts then maybe another OAuth flow is better. One that ideally displays them with SF login page they trust and just redirects back to your app when login succeeded. (you probably saw something like this if you recently used SF Data Loader?). That way your app doesn't see the password, just the result. And it'll work even if your client wants to use custom domain, decides to enable Single Sign-On...

Sorry, authentication, authorization are massive topics. But there is a better way so I'd want you to make a conscious decision before you code yourself into a corner... If help materials are too dry / too new & full of keywords then maybe try passing some trailheads:

Your SOAP login looks probably like that:

POST
    https://test.salesforce.com/services/Soap/c/45.0/
HEADERS
    Content-Type: text/xml;charset=UTF-8
    SOAPAction: ""
PAYLOAD
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:enterprise.soap.sforce.com">
       <soapenv:Body>
          <urn:login>
             <urn:username>uptonogood@example.com</urn:username>
             <urn:password>Nice_Try!111 + security token</urn:password>
          </urn:login>
       </soapenv:Body>
    </soapenv:Envelope>

Corresponding OAuth login (forced to return XML although mobile app should "like" JSON better so if you want - ditch the Accept header I've added)

POST
    https://test.salesforce.com/services/oauth2/token
HEADERS
    Content-Type:application/x-www-form-urlencoded
    Accept:application/xml
PAYLOAD
    grant_type=password&
    client_id=3MVG9fTLmJ60pJ5JaGv0NNHD5nh6P...&
    client_secret=3437814...&
    username=uptonogood@example.com&
    password=Nice_Try!111
eyescream
  • 18,088
  • 2
  • 34
  • 46
  • This is very helpful - thank you! I don't want to bypass salesforce security features at all haha - just find that with the mobile SDK, the only way to login is through the built in web based login, which users have complained about. It just seems like there is enough for a native app to be able to handle account creation or authentication securely without the user having to take extra steps to go through Salesforce on the web, and that I'm missing something obvious. But this should help massively, so thank you again. – uptonogood May 08 '19 at 10:49
0

The proper way to do this would be to have your own backend through which you proxy your requests.

e.g.:

Android app -> Your backend -> Salesforce

user5507535
  • 1,580
  • 1
  • 18
  • 39