...
The Shibboleth UI is specifically written to work with new metadata-driven configuration support that Shibboleth Identity Provider 3.4 has introduced. So the assumption is that you will use the Shibboleth UI in conjunction with IdP 3.4. And that the underlying configuration of your Shibboleth IdP 3.4 instance(s) will have been modified to activate metadata-driven configuration support, include the needed LocalDynamic metadata provider definition and metadata/generated directory (for the individual metadata sources (files) managed through the UI) etc. If you use the TIER-provided Docker Shibboleth Identity Provider 3.4 package, these IdP configuration changes will have already been made.
If you are not going to use the TIER Shibboleth IdP 3.4.x Docker distribution, then you would need to make these IdP 3.4.x configuration changes yourself. The following page discusses the range of changes that are needed to take full advantage of this Shibboleth UI.
Deployment
There is a TIER Docker Shibboleth UI testbed deployment one can use, that provides the full environment one needs to explore and gain experience with the Shibboleth UI. This Dockerized testbed version is available at https://github.internet2.edu/docker/shib-ui . That testbed follows the TIER packaging guidelines. It relies on supervisord, and includes the Shibboleth UI, a Shibboleth IdP (with a shared filesystem between the Shibboleth UI and Shibboleth IdP), an LDAP server as the base credential/attribute store for the IdP, the TIER Maria DB image for the UI's persistent database, and the TIER Beacon configuration.
...