Metadata and Attributes
...
are Documented in another Page
From week to week we add new Metadata files and configure the release of attributes to new applications. Occasionally we defined new Attributes or get the same Attribute from a new database. That is the routine maintenance and it is documented in a different page. It is probably a good idea to read the Shibboleth Configuration page first before reading this page because it is more important, and because I assume you understand a little about Spring Bean configuration already.
...
In Shibboleth 2 a Datasource (a database connection pool configuration specifying the database url, jdbc class name, userid, and password) could be configured in a DataConnector element of the attribute-resolver.xml or it could be supplied by the container (the Web Server which is to say Tomcat or JBoss). There was, however, a scary comment in the Wiki that if you use Oracle as your database (which we did) then the Shibboleth provided DataConnector implementation did not work well and they recommended using a container datasource. So that is what we did.
When we migrated to Shibboleth 3 we have initially maintained this convention. Therefore, datasources are configured in the context.xml file that is copied (with variable substitution) to the /apps/tomcat/current/conf/catalina/localhost/idp.xml file by the Install Project.
However, because Shibboleth 3 is not fully a Spring Framework project, there is an alternative. The datasource can be configured as a Spring Bean. Spring has serious industrial strength support for DataSources that is as good or better than JBoss or Tomcat. Moving the datasources to a Spring Bean configuration is planned for a future (but relatively soon) releasewe used all ContainerManaged datasources.
A Datasource maintains a pool of connections. Sometimes they get old and are closed at the database end. Sometimes the database goes down and breaks the connection. Before passing a connection to Shib, the Datasource is supposed to check to make sure it is usable. This is not a trivial job, and Apache, JBoss, Spring, and other environments have code (sometimes vendor specific code) to get it right. Shib is not in the generic JDBC business, so you will generally get more reliable behavior if you use code from someone who put a lot of effort into getting it exactly right.
For the first cut, Shibboleth 3 continues to use ContainerManaged datasources. However, we now run under Tomcat instead of JBoss, and Tomcat uses Apache datasource management which is OK but not really as good as JBoss. The solution will be to move from ContainerManaged datasources to a new option that was added by Shib 3 where the Datasources can be managed by Spring.
Tomcat managed datasources are configured in the context.xml file that is copied (with variable substitution) to the /apps/tomcat/current/conf/catalina/localhost/idp.xml file by the Install Project.
Spring managed datasources will be defined as Beans in one of the Bean XML files.
Logging
Logging in Shibboleth 3 is controlled by the conf/logback.xml file. Initially it is treated as a normal configuration file. However, we may want to create a special Jenkins Install runtype to change the logging levels to get more information from a running server, provided that the logging levels can change dynamically.
...