function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Implementing security from an apex callout

I have an internal web service that I am invoking from an apex callout.
It currently works fine, but before we go into production I want to implement some security.
I am looking for a way to authenticate that the request is actually coming from salesforce and if possible, coming from a user in our org.

Any suggestions on how to do this?



ps: If there are any prior posts or existing documentation, please point me to them.
Pat McQueenPat McQueen
There are a couple of ways to secure callouts:

1) Restrict the IP Addresses that the web service will accept calls from.
2) Use the Client Certificate (or use your own Cert) to do mutual SSL for the Callout.
3) Put a HTTP header into the Callout to use some sort of Basic Auth

(any or all of these can be used)

You can get the client certificate under setup. If your endpoint uses a client certificate, right-click the Download Client Certificate link on the outbound message detail page, and save the certificate to the appropriate location. Then you can import the downloaded certificate into your application server, and configure your application server to request the client certificate

You can send HTTP Headers on a Web Service Callout ... Here is the sample in the documentation:

docSample.DocSamplePort stub = new docSample.DocSamplePort();
stub.inputHttpHeaders_x = new Map();

//Setting a basic authentication header

stub.inputHttpHeaders_x.put('Authorization', 'Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==');

//Setting a cookie header
stub.inputHttpHeaders_x.put('Cookie', 'name=value');

//Setting a custom HTTP header
stub.inputHttpHeaders_x.put('myHeader', 'myValue');

String input = 'This is the input string';
String output = stub.EchoString(input);
Thanks for the help!

Is validating that the sessionId of a user belongs to our org good security or not really?
It is my understanding that the sessionId will only be valid when a user is logged in and will change from login to login.

So if I sent that id and then looked up the orgId of the user associated with that session I could tell where the request was originating from and be reasonably certain that someone didn't get a valid session id and saved it to create requests since they should become invalid after sometime.

If we wanted to restrict the IP, that is something someone in our infrastructure team can take care of right?
Or would that be more of an application level of security ?

when i add this line of code

//Setting a custom HTTP header
stub.inputHttpHeaders_x.put('URL', 'myURL');

is this going to be added in the Header section in order for request to contain something like this below

<env:Envelope xmlns:env="" xmlns:xsd="" xmlns:xsi="">