Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

true
Localtabgroupexpand
Localtab live
titleV4.0

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
Expand
titleV4.1+

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:

Code Block
    <bean parent="shibboleth.AdminFlow"
        c:id="http://example.org/myadminflow"
        p:loggingId="MyAdminFlow"
        p:policyName="AccessByIPAddress"
        p:nonBrowserSupported="false"
        p:authenticated="false"
        p:resolveAttributes="false" />

Make sure to inherit from this parent, and to use the c:id syntax to identify the bean with a profile identifier (necessary for the auto-wiring process to work). The other settings are shown for illustrative purposes but will vary by use case.

...