...
Rather than creating a new configuration system, applications are increasingly using the Spring Framework. CAS started using Spring 10 years ago, and Shibboleth 3 now fully embraces it. Spring provides a common configuration mechanism, so once you know how it works you can use it to configure CAS or Shib or any other system written in Spring. However, it is not appropriate here for me to introduce Spring just to explain how Shibboleth configuration works. You can go to the Spring website for an introduction to its general syntax.
The SAML standard defines a syntax for certain configuration files, notably the Metadata. Shibboleth 1 and 2 had their own XML syntax for certain Shib only files, and in a few cases that syntax is still supported. However, almost all the new or less important or highly technical configuration files have been converted in Shib 3 to Spring syntax.
Shibboleth is a modular system with subcomponents that perform specific functions. One component reads Metadata files that describe communication with various partners (Salesforce, Comcast, Google). Another component authenticates users (at Yale we use CAS). Another component reads data from Yale databases and directories to build Attributes that will be returned to the partners after the user logs in.
In Spring, a component is configured as a Bean. A Bean is an instance of a Java class in one of the libraries provided by the application. The Bean is parameterized with strings, files, numbers, booleans, and references to other Beans. For example, a Bean that uses the CAS client library to log a user on needs to know the URL of CAS at Yale ("https://secure.its.yale.edu/cas"). To do the configuration, Spring doesn't have to understand what a Bean does. It just needs to know the name of the Java class that creates the Bean and the names and values of the parametersIf you want to understand Spring in general, go to the website or read a book on Spring.
Some files cannot be replaced by Spring configuration. The SAML standard provides an XML syntax for Metadata. Shibboleth 2 had its own XML configuration file syntax, and some of those files are supported in Shibboleth 3 to simplify migration. Under the covers each XML element will be converted by Shibboleth to an object, and today some of those objects will also be visible to the Spring framework. However, most of the less important, more technical configuration files that administrators were less likely to provide or modify are now converted from Shib 2 format to standard Spring format.
In Spring, each XML element is converted to a "Bean". A Spring Bean is an instance of the Java class whose name is provided in the XML class= attribute. Spring provides a number of general purpose classes, Shibboleth adds its own application specific classes, and Yale or a vendor could supply additional classes by adding a JAR file to the WEB-INF/lib directory of the application.
Each Bean provides a generic function that is parameterized by properties or constructor arguments. Spring does not require you to write code, because the parameters can be provided in the XML. A generic database access Bean would be parameterized by the JDBC class name, the connection URL, and a userid and password to connect to the database. A generic LDAP bean would be parameterized with similar information to connect to the Yale Active Directory. Unicon provides an integration between CAS and Shibboleth 3 that must be supplied the URL of the CAS server at Yale.
You know you have a Spring configuration file if the first element is <beans>. Then the file contains mostly <bean> elements, although Spring has a few aliases for <bean> when you are dealing with standard classes. If you are creating a Java List, for example, then instead of a <bean> file that references the "java.util.List" class, it can use the defined nickname of <util:list>.
...