Call back URL for self service

[sumeet]

Hello all,

When setting up the Salesforce connected app, the call backup URL was set to the server DNS. This DNS is internal and not exposed out to public.
The connected app is setup, the backup is running fine.

While trying to provide access for self service restore, we setup an external facing DNS with a specific port that has NAT to the internal server where VBSF is installed.
Customer is able to access the public DNS and gets the login page, when they put in their salesforce credentials, the page returns back to our internal DNS, which ofcourse fails as it is not accessible externally. This will happen only if the callback URL in the connected app is being used.
I checked that the connected app has an option to specify multiple call back URLs but this did not help.

The only other option I can think of is to ask my client to use M365 Auth, instead of salesforce. With M365 auth, since I will have to create a new Azure app and specify the call backup URL, so here I can use the public DNS, which will make them land back to the same URL that our client uses for login (which is different than the actual VBSF server). According to my client, their M365 does not have MFA enabled and so he is not keen to use this, but he is checking with his team about MFA.

Any other option? For service providers like us, it is very common to have a different public accessible URL with a port.

Thanks,
-Sumeet.

[MIvanov]

Hello @sumeet, excellent topic and the question. The only workaround I can think of now is to create your custom login page, where you will provide your callback URL yourself. This is an easy fix, so to say, the URL needs to specify the callback url in the URI string.

So, you can, for example, call the VBSF SSO endpoint, get the URL, replace the callback URL on the fly to whatever you have configured and it should work.

We will consider adding something along these lines in v3 this year.

[sumeet]

Hello MIvanov,

Thanks for your reply.

I got a confirmation from my customer that they have MFA enabled for M365, and they are ok to give this a try. The azure app that we will create will have the publicly accessible URL, which we provide to our customers. Do you see any concerns with this option?

My network/security engineer is on leave, hence I'm unable to get a public URL for my test environment to test this out.

Regarding your suggestion of creating my own custom login page, please provide some reference on how to create this. I have never created a custom login page.

Thanks,
-Sumeet.

[sumeet]

Hi MIvanov,

I just tested the option to use Azure Active directory for SSO and this does not work either. As part of adding the SSO, it fails as the callback URL in Veeam Backup for SF does not match with what was specified in the Azure app.

Please provide more details on the custom login page.

Thanks,
-Sumeet.

[sumeet]

Hi MIvanov,

Continue to finding a way to get this to work, I just realized that while setting up the SSO in Veeam Backup for SF, the call back URL cannot be modified. Why is this behavior to not edit the call back URL.
Because if this was editable, I could have changed the URL to the publicly accessible URL and then when I click on save and be redirected to Microsoft, this would not have failed as the URLs would have matched of what is set in the connected App.

Refer this documentation of VBSF https://helpcenter.veeam.com/docs/backu ... tml?ver=20 the first screenshot for enabling SSO using Azure active directory. As you can see, the Callback URL field cannot be edited. Why is this so?

Thanks,
-Sumeet.

[sumeet]

Hi,

Also the restore portal by default has the default login option (username and password) available along with SSO. When this gets exposed publicly, it is prone to brute force attacks and DoS too.
We make sure our passwords are lengthy and complex, but still.

Please check the web restore portal of M365 (I know VBSF is relatively new), this only has the option to specify email ID (I understand M365 has another UI interface too, which is not available for VBSF). But maybe another web portal for self service restore, that does not expose the default login options.

Thanks,
-Sumeet.

[MIvanov]

@sumeet
I'm sorry for confusing you, I just looked into the API and for Salesforce SSO you only need to construct a valid URL and redirect the user to it

Here is the URL format:

Code: Select all

https://login.salesforce.com/services/oauth2/authorize?client_id=client_id&redirect_uri=redirect_uri&response_type=code"

Where
* client_id is you Connected App client id.
* redirect_uri is you reverse DNS URL that you need. Some "https://your-url-here" that will represent the VBSF installation.

The final url will look like this

Code: Select all

https://login.salesforce.com/services/oauth2/authorize?client_id=3MVG9IHf89I1t8hrvswazsWedXWY0i1qK20PSFaInvUgLFB6vrcb9bbWFTSIHpO8G2jxBLJA6uZGyPFC5Aejq&redirect_uri=https://your-url-here&response_type=code

For example, you can try this link and it will allow you authenticate but will end up with invalid redirect, obviously
https://login.salesforce.com/services/o ... _type=code

[MIvanov]

Are you configuring this in AWS or Azure, or you use a VMware environment?

[MIvanov]

As a temporary solution, you can take this simple login page with hardcoded url, replace your parameters and present it to the customer the way is more convenient - put on VBSF server or have a static website on AWS or Azure.

[sumeet]

Hi MIvanov,

We use VMware environment.

I tried the Salesforce SSO valid url that you suggested above and this fails with -- error=redirect_uri_mismatch&error_description=redirect_uri%20must%20match%20configuration
This works only when the URL matches with the server URL, which will not work as our external URL is different.

I will check about the html file that you have shared and get back.

Thanks,
-Sumeet.

[MIvanov]

@sumeet It will work as long as you provide the correct callback url to the call and the Connected App will have it listed (it takes 10 minutes to apply any changes)

If you want, we can do that over the call

[sumeet]

Hi MIvanov,

Thanks for assisting with this one.
We got this resolved by making our public URL match with what we have internally. Our public DNS has the same FQDN (the IP is different though), as what we used internally.

But will request to please consider some of the above feedback provided above in my comments, listing them again below for quick reference

1. Do not expose the default login (to avoid brute force attacks)
2. Allow to use a different external URL (the Azure configuration has the textbox of callback URL field disable)
3. Have different option in case of salesforce to use as callback URL

Thanks,
-Sumeet.