AdministrativeConfiguration
- Scott Cantor
Current File(s): conf/admin/admin.properties
Format: Native Spring, Properties
Overview
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/admin.properties. 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.
Authentication
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/admin.properties
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 authn.properties.
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:
Reference