Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

The IdP software makes extensive use of native Spring XML configuration for newer and advanced features.

Table of Contents


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

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.


Skeletal Spring File
titleSkeletal Spring Filecollapse
Code Block
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""


Spring Expressions

A key technology that can greatly simplify some Spring syntax is the Spring Expression Language:

Spring expressions in XML configuration are typically bracketed like so: #{ expression }


You can generally nest properties inside of Spring expressions (or use them to actually carry expressions) in a natural fashion:

Code Block
    #{ %{} }

The use of lists deserves some special consideration. Ordinarily, as described above, lists have to contain quoted values. If a property contains a list of values that are explicitly quoted, you can do something simple to substitute the property into a list:

Code Block
    #{ { %{} } }

Alternatively, you might want to make the property simpler and more robust, avoiding quotes and automatically trimming any trailing spaces you accidentally add in an editor. You can generate a list to populate into a property with a bean like so:


The mapping of URLs to specific functionality 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. This is managed with an extended mechanism that is more flexible than that provided by SWF natively, and it introduces a couple of advanced 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 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.webflows}/**/*-flow.xml

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

The first of these loads flows defined in the user-modifiable configuration, because the "idp.webflows" property defaults to "%{idp.home}/flows". The second is provided to allow plugins to supply flow definitions at load time without requiring copying or other tricks.