Page Comparison

...

For some helpful reference material on how native Spring syntax works, see:

• http://docs.spring.io/spring/docs/4.13.x/spring-framework-reference/html/beans.html
• http://docs.spring.io/spring/docs/4.13.x/spring-framework-reference/html/xsd-configconfiguration.html

Creating New Files

If you need to create your own Spring bean file to import or load into a service's resource set, the following template should be used. While usable to some degree in XML editors, the use of the "p" and "c" shorthand namespaces is not really schema-compatible and is designed for use inside Spring-aware tools such as the Eclipse STS plugin.

...

While the use of Spring Web Flow (SWF) for user interaction is a major change from V2 to V3, we have tried to minimize the degree to which a typical deployer will need to interact with, let alone customize, flows. But we will eventually provide some notes on how and where this can be done for those with more ambitious needs.One basic comment: if you want to create your own flows, the best way to do that is usually to copy an existing flow from the system configuration files. A key difference between the flows that are built in vs. any that you create are that user flows have to follow a very particular file name and location convention to be found. The way this works is that a flow called foo/bar running at the URL path /idp/foo/bar needs to be in a file located and named idp.home/flows/foo/bar/bar

The mapping of functionality to URL is by and large derived from a set of mappings that define the built-in flows that come with the software and the paths at which they should be installed. Starting with V3.3, this is managed with an extended bean factory that is more flexible than that provided by SWF natively, and it introduces a couple of new capabilities useful for plugins that are implementing custom flows or for advanced deployers:

• Overriding built-in system flows at a given location
• Adding flows automatically using a plugin jar

There are now Spring beans containing the mappings of flow definitions to locations and flow "patterns" to search for. The defaults are contained in a pair of beans, shibboleth.DefaultFlowMap and shibboleth.DefaultFlowPatterns. The latter will load flows from the following two locations automatically:

• idp.home/flows/**/*-flow.xml
• classpath*:/META-INF/net/shibboleth/idp/flows/**/*-flow.xml

The first of these loads flows defined in the user-modifiable configuration, as in previous releases. The second is new, and is provided to allow plugins to supply flow definitions at load time without requiring copying or other tricks.

Note that in both cases, the flow's name/location will be derived from the directory structure found in the wildcarded portion of the path, so a flow in /META-INF/net/shibboleth/idp/flows/authn/custom/custom-flow.xml will be named "authn/custom", just as if it were placed in idp.home/flows/authn/custom/custom-flow.xml.

Many of the flows in the system fall into special groups that have to follow an additional naming convention. For example, a login flow name must start with the prefix "authn/". So a new login flow called "authn/bar" has to be created in idp.home/flows/authn/bar/bar-flow.xml.Typically, the convention is to put the Spring beans that define the flow's objects into the same directory with the flow file and then import it into the flow file, as in the example above.

If you have a need to override or supplement existing flow mappings, you can supply two maps called shibboleth.FlowMap and shibboleth.FlowPatterns to replace, or more likely merge themselves with, the default beans mentioned above. The main use case for this would be to override the flow installed to one of the built-in locations or to register one of the built-in flows at an additional location. The practical reason you would do this would be to add additional endpoints for various services to fit some kind of unusual requirement.

Pre-Supplied Beans and useful classes

A standard IdP configuration provides you with many "named beans" which are there to simplify configuration.  Examples include (but are not limited to) the many ActivationConditions which are available.

The PredefinedBeans topic details them all, as well as providing a list of other "useful class names".