Versions Compared

Old Version 3

changes.mady.by.user Rod Widdowson

Saved on

compared with

New Version 4

changes.mady.by.user Rod Widdowson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Overview

The IdP includes a small (at present) number of internal administrative functions to help manage and monitor the application, and this number is expected to grow in the future. As with the more well-known features, the administrative features are also built using Spring Web Flow.

...

As described in the GeneralArchitecture topic, the root of the context tree for any of the profile flows is the ProfileRequestContext class,and this is also true for administrative flows. Unlike the more traditional profile flows, there is no typical "relying party" to associate with them, and they are not enabled in the same way.

Instead, an administrative flow's profile URI is used as a stand-in for the typical "relying party ID" and a mocked up context tree is created to reflect this. A net.shibboleth.idp.profile.context.RelyingPartyContext child context to the ProfileRequestContext is created to hold the profile URI, and a profile configuration object (this object is in fact the same bean defined in admin.xml for the flow). No RelyingPartyConfiguration is populated.

...

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.

Localtabgroup
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
activetrue
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.

...

The first action defined in the flow should typically be:

Admin Flow Bootstrapping
Code Block
languagexmltitleAdmin Flow Bootstrapping
<action-state id="InitializeProfileRequestContext">
	<evaluate expression="InitializeProfileRequestContext" />
	<evaluate expression="'proceed'" />
        
	<!-- Branch to parent flow. -->
	<transition on="proceed" to="DoAdminPreamble" />
</action-state>

...

In addition, two beans of type Function<ProfileRequestContext,String> may be defined:

  • shibboleth.AdminOperationLookupStrategy

  • shibboleth.AdminResourceLookupStrategy

These functions are called to derive the operation and resource to supply to the access control decision performed by the CheckAccess action.

...