...
| Expand | ||
|---|---|---|
| ||
V4.1 introduces Modules, and 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".
Upgrading from V4.0 and EarlierThe information above focuses on the "as-delivered" V4.1 defaults, which are considerably changed from earlier versions, and apply out of the box only to new installs. Upgraded systems, while they may contain combinations of old and new files, by design function the same as they used to for compatibility, and the new bits are generally ignored/overridden by the older settings. With V4.1, the use of XML to configure many basic features has been minimized and replaced by simpler properties, with a new file (admin/admin.properties) added. Most of the properties in this file are commented out and largely ignored because they are superseded by the beans in the original admin/general-admin.xml file, which has been removed from new installations (but is still processed when present). With this release, all beans of type AdministrativeFlowDescriptor are automatically recognized, obviating the need to define them by hand, which was the main purpose of the XML file. Instead, all of the built-in administrative flows are wired up internally with properties used to control settings rather than XML. For compatibility and for those who favor XML, any flow descriptor bean inside a list named shibboleth.AvailableAdminFlows with a particular For those wishing to migrate from the older approach to the newer approach (this is not required), removing admin/general-admin.xml, setting idp.searchForProperties to "true" in idp.properties, and setting any properties corresponding to non-default settings applied in the XML will provide equivalent behavior (and hopefully be easier to understand). |
...
| Expand | ||
|---|---|---|
| ||
You can mark a flow as requiring authentication with the You can use the |
| Expand | ||
|---|---|---|
| ||
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, this requires reverting to XML by overriding the built-in bean defining the flow with your own copy nested inside a shibboleth.AvailableAdminFlows list bean. You can define these beans in global.xml and you can easily copy the bean that defines a specific flow by referencing the system's copy of the bean (see here). Then you would create a |
| Expand | ||
|---|---|---|
| ||
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. With this release, you can also configure post-authentication interceptor flows via idp.feature.postAuthenticationFlows properties. The ability to run these flows was missing prior to this release. |
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.
...