SAML cannot adjust SP entity ID / ACS URL

[tm67]

Hi
Case # 08183204
I tried to enable SAML authentication and had some issues.
My VeeamOne runs on port 443.
When adding an identity provider, the "SP entity ID URL" and "Assertion consumer URL" is like this:
https://my-veeamone-fqdn:/api/Saml2/MyClientID
(there is a ":" after the fqdn which I cannot remove during the setup of the IDP inside VeeamOne)
I tested it with EntraID and when importing the xml, I cannot save the config since it does not allow a ":" in the Identifier.
And if I remove the ":" of the identifier in the EntraID, the login does not work since the identifier does not match with VeeamOne.
Is it possible to adjust those URLs while setting up the IDP?
The VONE web client seems to generate those two URLs based on how I access the WebUI, if I access VONE locally on the VONE server with https://localhost, then the URL is https://localhost:/api/Saml2/MyClientID and if I access it with the FQDN, it generates the URL based on the FQDN. Maybe it should be possible to set a fixed FQDN (with port?) and then the URL gets generated based on this value?
Thanks for having a look at it.
Timo

[RomanK]

Hello Timo,

Thank you for the case #.

As far as I know the problem is specifically the port segment. The Veeam ONE web UI runs on 443, which is the standard HTTPS port. When the port is the default for HTTPS, the web client resolves it to an empty value, but it still inserts the : separator. The workaround should be using any other free port or default.

The support engineer should check everything else, so please continue troubleshooting within the support case.
Thanks

[tm67]

Hi Roman
Support confirmed that those URLs are read-only and cannot be adjusted manually.
Also with port 443, this looks like a bug that will be corrected in a patch.

I think there should be an option to specify a URL manually for use cases where VeeamOne is behind some reverse proxy.
Timo

[RomanK]

Hello Timo,

As far as I remember, the idea was that the link should be used for copy-paste rather than creating your own. It should work the same way in other products. But I also agree that the reverse proxy should be supported.

Do I understand correctly that this is a production environment? In theory we could inject the link through the private API, though we haven't tested such a workaround. I see the support case has already been closed. I suppose we could try it under the supervision of support and QA, but a new case will be needed.

Thanks

[tm67]

Thanks Roman, it was just a test environment. As soon as we plan to integrate this in production I will come back with a new case.
I think that we will use port 443 and if this specific issue is fixed in a future patch, we won't have to manually change the URLs.