...
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.
| Tip |
|---|
You can safely skip the rest of this section unless/until you have a need to work with custom webflows or are building your own extensions. |
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:
...
The first of these loads flows defined by deployers 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.
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-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.