...
Top-level flows exposed to the outside world are divided into profile flows and administrative flows. Administrative flows are essentially any feature that doesn't take advantage of the full relying-party abstraction for their configuration. They're assumed to be on or off generically and behave somewhat uniformly, although in practice any amount of intelligence could be built into the flows themselves if desired.
Localtabgroupexpand | |||
---|---|---|---|
Localtab live |
| ||
As a top-level flow, there is no special naming convention for administrative flows, but they are all defined to the system with a bean of type net.shibboleth.idp.admin.AdministrativeFlowDescriptor in a list in conf/admin.xml. See AdministrativeConfiguration for more information on this "deployer-facing" aspect of the system. Localtab live | | active | true
Expand | ||
---|---|---|
| ||
As a top-level flow, there is no special naming convention for administrative flows, but they are all defined to the system with a bean of type net.shibboleth.idp.admin.AdministrativeFlowDescriptor. Beans of this type are now auto-detected at startup and so do not require any special file or containing list to define them in, something that used to be required (see also the V4.0 tab). Simple defining a bean like so in conf/global.xml should work:
Make sure to inherit from this parent, and to use the |
...