...
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 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 have modified in Shib 2 are now rewritten in Spring syntax and would have to be manually converted if you made changes to the previous version.
In the Spring framework, application Java classes are used to generate objects called Beans. In any Spring configuration files, each <bean> XML element contains the name of a Java class. Spring creates an instances of the class (an object) and passes values from the <bean> XML object to named properties (or constructor arguments) to initialize the bean with parameters it needs to perform a specific function. New classes can be made available by adding a library to the WEB-INF/lib directory of the Web 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., so we can add third party code or Yale code without changing anything in Shib itself. The parameters provide database URLs, userids, passwords, Active Directory domain names, or any other string or numeric value needed to configure generic code to the specific Yale environment. For example, we add the Unicon library to the Web Application and then configure the Unicon CAS-Shibboleth integration by providing the URL "https://secure.its.yale.edu/cas" of the CAS server at Yale. Information on the Unicon code and configuration, see https://github.com/Unicon/shib-cas-authn3.
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>.
Once Shibboleth defines the Interface or signature of a component, others can provide their own Java code that implements the Interface. So while Shibboleth provides a generic signature for a component that logs users on, Unicon provides a library with a class that implements that interface and logs users on through CAS. We downloaded and installed the Unicon library and added the Unicon configuration files, parameterized with Yale CAS information. For information on the Unicon code and configuration, see https://github.com/Unicon/shib-cas-authn3.
Local Disk File Configuration
...
Local Disk File Configuration
Many applications are configured in a database. Spring has the built in capability to define a file (which it calls a Resource) based on a path to local disk or a URL to a network file. Even before it used Spring, Shibboleth had written its own custom code to read configuration files from disk, from URLs, or even to check a file out from Subversion source control at system startup. Then periodically Shibboleth can "poll" the source to see if a new version of the same file has become available (based on the last changed date or in Subversion the most recent committed version number) and reload it if there was a change.While checking
Using Source Control to manage text configuration files into Source Control seems like is an excellent idea, if the Subversion server is not available when Shibboleth comes up then it takes an unreasonable amount of time for Shibboleth to start. In order to recover from major datacenter failures (as happened when the power was cut to half the servers on campus) Yale stores some of its recovery plans and checklists on cloud services. To login to cloud providers, you need Shibboleth. So Shib is a "Tier 0" application that has to come up before any database, Web, or Source Control servers. That means that everything Shib needs to come up has to be on its "local hard disk" (put in quotes because datacenter disk can be on a SAN). You have a history of changes and an easy way to back out mistakes. When Shibboleth was used to provide casual access to academic resources at other universities, the direct use of Source Control would have been the right thing to do. However, today many of our critical systems are located in the Cloud and they use SAML to login. Since our disaster recovery plans are stored off site, Shibboleth has to be one of the first services restored after a major outage. Subversion comes up hours later. So Shibboleth has to be able to run with only its own local disk. You can of course bring Shibboleth up on the last checked out version of files when Source Control is not available, but we have discovered that Shibboleth takes an unreasonable amount of time trying and failing to connect to the Source Control server when that server is unavailable.
So Yale accomplishes effectively the same thing with a bit more work. All Shibboleth configuration files are checked into Source Control. However, Shibboleth does not know this and does not go to Source Control itself. Shibboleth is configured to use files on disk, and when appropriate to check periodically to see if the file change dates have been modified and reload the changed files. The files are deposited or updated on the Shibboleth local disk by a Jenkins Install job under the control of Operations. So Shibboleth does not see the files change just because a new version of a configuration file has been committed to Subversion. After the commit there has to be an explicit Jenkins run to move the file to the Shibboleth server, and while Jenkins jobs can be configured to run automatically after a commit, this particular job is started by a person when we make a positive decision to change the running Shibboleth.
...
Metadata is a big block of information about an Entity in an XML <EntityDescriptor> defined by SAML.
So a given partner like google.com is sometimes called an SP and sometimes called an RP. It is an Entity and it has Metadata. In different contexts all these terms would be used to describe the same partner.
Metadata and "Providers"
The conf/metadata-providers.xml file (Shib 2 format, not Spring) contains a list of <MetadataProvider) elements. Each Provider defines a local disk file or URL that contains or returns Metadata. This Each file can define a single Entity or it can contain thousands of EntityDescriptors.
...