I'm pretty sure that we formerly had a part in the documentation that mentioned more about the requirements for connecting SOFO to a onsite environment. But I cannot find it anymore, has that been removed or replaced or am I missing something?
Anyway, there should be a separate sub-item for Onsite-configuration, that clarifies all parts related to such a setup.
I would like more information on an architectural level, to better clarify all communication workflows as well as making it easier for an IT Architect to see potential ways of exposing the SO Onsite API in a more secure way.
So, the parts that I would like to have added are:
A workflow diagram that shows the communication from the "local" SOFO App to the SO Onsite API Endpoint
All potential extra proxy layers in form of MS Enterprise apps should be included in this workflow with their GUID's and names, so the whole workflow is 100% clarified
It should be clarified that the authentication against the onsite api is only made with Basic Auth
It should be clarified that respective users personal credentials are used for the authentication
It should be clarified which API that is used, my understanding is that it is the REST-API and not the SOAP-API, right?
As many onsite customers are using SSO, which means that Win Auth is enabled on the site where the REST-API is hosted, it should be mentioned if the REST-API needs to be exposed using a separate NetServer installation using Anonymous Auth on the site or not, or if there are any other kind of recommended setup
My recommended best practice for onsite installations is always to setup a separate Net Server for integrations using the API, to offer better flexibility and independence of the settings applied to the main SO site
Idea:
Some more security focused customers might be a bit reluctant to expose their onsite API to the internet
An idea I have been lightly investigating is the potential of exposing the API using "Azure Application Proxy"
This might give the possibility to limit the access to the API using criterias such as the GUID of the Enterprise App making the calls to the API, or some specific App Certificate or maybe an ID of an authorized enterprise app in the customers Azure environment
This way the potential of unauthorized API calls might be severly limited
If you can see any potential using this kind of workaround, you are more than welcome to add suggested filtering critieras available, thay might be used, such as my suggestions above
Best Regards
Marcus S, Senior Technical Consultant, SuperOffice Sweden
Document Details
⚠ Do not edit this section. It is required for docs.superOffice.com ➟ Docs Team processing.
I'm pretty sure that we formerly had a part in the documentation that mentioned more about the requirements for connecting SOFO to a onsite environment. But I cannot find it anymore, has that been removed or replaced or am I missing something?
Anyway, there should be a separate sub-item for Onsite-configuration, that clarifies all parts related to such a setup.
I would like more information on an architectural level, to better clarify all communication workflows as well as making it easier for an IT Architect to see potential ways of exposing the SO Onsite API in a more secure way.
So, the parts that I would like to have added are:
Idea:
Best Regards Marcus S, Senior Technical Consultant, SuperOffice Sweden
Document Details
⚠ Do not edit this section. It is required for docs.superOffice.com ➟ Docs Team processing.