...
Typically the core configuration (shibboleth2.xml) is an exception to this, in that it defaults to a local file that is monitored for reloadability in a standard fashion. Since it's the "root" of the system, there typically is no XML configuration that itself describes where it lives and how to treat it, but technically it is possible to control the handling of that resource using more advanced settings.
Some component configurations are commonly defined "inline" within the shibboleth2.xml file itself, notably the RequestMapper, and this is usually possible any time a component supports this reloadability feature (e.g., you can define metadata inline if you really want to, or even rules for attribute mapping). In most cases, using a separate file is just simpler.
| Anchor | ||||
|---|---|---|---|---|
|
...