Shibboleth Developer's Meeting, November 22, 2013

Attendees: 

Note : Tom is out-of-office, so this call is cancelled, unless folks want to chat anyways.

Next call : Friday Dec 6

Brent

Daniel

Ian

Rod

Scott

Tom

Most of the week of November 11-15 was spent adding the attribute resolver and filter to the testbed.

Testbed resources : I omitted the use of our custom <Service/> schema because we have not ported ResourceFilter from v2, and I am not sure we will in lieu of Spring Resources and property replacement. I added a simple SpringResource class to the testbed to wrap a Spring Resource and present it as a java-support Resource. Rather than instantiate the attribute resolver and filter in services.xml, they are instantiated in system/conf/global-system.xml.

Testbed jetty : I added system/conf/jetty.xml to configure Jetty via Eclipse or via Maven. The HTTP connector probably should be removed later. Initial work. I copied Marvin's creds/localhost.p12.

Testbed idp.home : The system property idp.home is necessary to run Jetty from Maven and Eclipse. I moved configuration resources to the filesystem (src/main/config) rather than classpath (src/main/resources), but maybe should not have. I am pondering whether idp.home might need to be idp.conf for locations of the form "${idp.conf}/conf/idp.properties" instead of "file://{$idp.home}/conf/idp.properties" so that deployers can bundle configuration resources into a war or not. In other words, the idp.conf system property might should specify the "file:" or "classpath:" prefix. For example, to tell Logback to configure itself via src/main/config/conf/logback.xml requires a system property, whereas if we defaulted back to classpath resources that system property would not be needed.

Testbed idp.properties : The contents of idp.properties are added as system properties when running via Eclipse and Maven.

Once Rod and I have gotten farther along with configuration reloading, I expect that the Service interface will change. I have done some looking as to whether Service should be replaced by Spring's Lifecycle interface, with a custom DefaultLifecycleProcessor to handle our fail-safe reloading of an application context. Also, conjoined components like the AttributeResolver and AttributeMapper should probably be in the same application context. Pretty sure Rod is going to move the Spring "nature study" to the testbed.

Marvin : are you handling "Interrupting/branching out of web flows" ? http://shibboleth.net/pipermail/dev/2013-November/002946.html

AI : Testbed property replacement for class attributes ? http://shibboleth.net/pipermail/dev/2013-November/002948.html

AI : Testbed exceptions for "classpath:" schemaLocation ? Just ignore for now, not sure it makes any sense to override the Spring EntityResolver or PluggableSchemaResolver at this time.

AI : Testbed filters in attribute-filter.xml were looking for context data that did not exist, need to send Rod the example attribute-filer.xml files I received and let's make sure they work.

AI : Would be nice to have a unit test for testbed flows.

AI : All sorts of testbed ideas.

AI : JPAR-35 and documentation of release process.

AI : File Spring bug for file:// base paths in flow-location-pattern

AI : Upgrade Jetty dependency to 9.1.0, revisit idp-distribution, for grins.

AI : Run testbed in Tomcat.

Other