Current File(s): conf/admin/
Format: Native Spring, Properties


The IdP supports a small number of "administrative" functions (reloading configurations, the status page, attribute resolver diagnostics) that are exposed as simple web interfaces and as command line scripts.

The IdP includes a framework for defining administrative flows that in addition to supporting basic access control also supports the IdP's authentication and attribute resolution features before invoking administrative flows, and to apply access control policies based on user- or attribute-based rules.

In the majority of cases, there's no need to touch this configuration unless you want to do something unusual or exotic with the current administrative features to change their access control model. But it may be useful in the future as additional features are developed, or if you're developing your own features to extend the IdP.

General Configuration

There are significant differences in the OOB approach to configuration for new installs of V4.1 compared to V4.0 or upgraded systems. The tabs below (and elsewhere in the page) provide the relevant information for each version, and where applicable information on taking advantage of new approaches after upgrading.

Some of the individual administrative flows have been converted into Modules that can be enabled and disabled. This approach is addressed within the pages that document all the flows. Most of the flows are so simple as to require little or no additional configuration, and so are not in modules and are "always" available though subject to access control.

The primary means of configuring most of the simple options is via the file admin/ Most of the settings in this file are commented out and defaulted, so setting the ones you need generally involves uncommenting them.

Every administrative flow known to the system auto-registers itself with defaults that can be overridden by setting corresponding properties, generally with the naming convention "idp.feature.setting".

For reference or for those whose understanding may be aided by seeing the actual wiring, you can see the XML that allows all the properties to slot in here, as well as in the Reference section of each individual flow's documentation page, but it's not essential to using the properties or understanding what they do.


The IdP does not at present rely on an "application session" in its own right; rather, each webflow is treated as a separate function to which a requester may have to authenticate itself in order to satisfy an access control policy. However, the IdP's own SSO functionality can be used to gloss over this behavior; to an end user it will usually appear as though he/she is signing on once and simply navigating to different features. A particular advantage of this approach is that step-up authentication is automatic (if you apply different requirements to different flows), since each administrative flow is free to express its own requirements and the IdP's existing capabilities will simply ensure that the right things happen.

You can mark a flow as requiring authentication with a flow-specific idp.feature.authenticated property in admin/

If you need to control how authentication is done, you can control this with a set of idp.feature.defaultAuthenticationMethods properties that are analagous to the “supportedPrincipals” property syntax used with the various authentication flows in

See the AuthenticationFlowSelection topic; essentially, the process of selecting the flow(s) to try is identical because to the IdP, the administrative flow is like a profile flow it's being asked to satisfy requirements for.

You can also configure post-authentication interceptor flows via idp.feature.postAuthenticationFlows properties.

Browser vs. Non-Browser

By default administrative flows do not support non-browser access during authentication. What that means in practice is nothing, unless you turn authentication on. Then it matters for determining whether to behave in ways that would be expected to break a non-browser client. For example, a simple script should not need to navigate a login form, though it could supply basic-auth credentials. So if you turn authentication for a feature on, but you want to use authentication features that only work with a non-browser client, you would need to set the nonBrowserSupported flow descriptor property to signal this. Or you could even perform user-agent testing on the fly to set this by plugging in a condition script via nonBrowserSupportedPredicate

Developing Administrative Flows

Refer to the developer material under Administration for technical details on developing your own administrative flows.

Supported Flows

As noted at the top, most of the current administrative features are actually more like REST-based WebInterfaces.

The others include:








idp.admin.entityID 5.1


Presently only used to override the entityID used in a discovery service request made during authentication to an admin flow, though it may eventually find other uses

Bean ID



Bean ID





List of flow descriptors enumerating the administrative flows available to the system (supplanted in V4.1 by autowiring of AdministrativeFlowDescriptor beans, but you may need to create this bean if you wish to extend/alter the system-defined beans)



Abstract parent bean for defining administrative flow descriptor beans, generally needed only by extension developers or those wishing to override the system-defined XML



Abstract parent bean for defining new administrative flow descriptor beans for flows intended to execute only once