Certain plugins can be linked together with other plugins. Its a short list of just CrushLDAPGroup and Radius, as well as SAMLSSO and WebApplication.

This allows you to have a SAML authentication process that got through its redirects and comes back to CrushFTP with the username provided by SAML. Instead of CrushFTP suing this to lookup group associations and access via LDAP queries, you can allow the WebApplication plugin to make HTTP calls to land the user.XML, VFS.XML, and VFS properties for the user.

This special linking is done with the plugin's instance name. So the first instance of a plugin has a hard coded name and can't be changed. You disable that instance and make a new instance of the plugin. In its name you set it to the name of the other plugin to call plus a tilde and the instance name. So in this case its "WebApplication~"...or "WebApplication~MyApp" where "MyApp" is an instance name on the WebApplication plugin. The first one was a blank instance name (the first plugin instance) while the second example was a named instance name of it.

The WebApplication plugin remains "disabled" so its not trying to process any requests. Its critical it stays disabled.

When the authentication goes through the SAML plugin, after SAML has confirmed the user, it now checks its plugin name and makes the call to the other plugin to see if it wants to handle the login. The way that works is entire up to the plugin, so refer to its documentation. WebApplicationSource