Shibboleth Developer's Meeting, October 18, 2013
Attendees:
Call Administrivia
Dial-in attendee identification.
Next call is next Friday. Any reason not to meet ?
60 to 90 minute call window.
Brent
Daniel
Ian
Rod
Scott
Tom
Quick week in review :
+ Injected ServletRequest/Response
Confirming agreement.
+ Scott's testbed work
Great.
+ MD key discussion
Huh ?
+ Identity Switch
(Scott)
+ Resources
Maybe a new Resource class and schema type which wraps our ClasspathResource and FilesystemResource as well as a Spring Resource. The location attribute should accept "classpath:<path>" and "file:<path>" and maybe "spring:<bean definition id>" for http[s], etc. OpenSAML would remain Spring independent, depending on the Resource implementations we ship in java-support.
The default for the resource location should be a property, defined in idp.properties.
Some discussion items :
+ SWITCH AMAAIS
+ Configuration
I am thinking we should try a property+override paradigm for configuration. The comment on jetty-users seems quite relevant to us, basically it is difficult to version XML configuration files, especially when deployers are required to modify them. So, like Jetty 9.1, provide a "site" directory whose configuration files are loaded last via Spring so that they override bean definitions with the same id. Maybe that is bad because it abuses that Spring "feature", possibly. However, we should prefer property based configuration to overriding bean definitions.
Comment from Greg Wilkins (Jetty)
So, deployers would be encouraged to make configuration changes to, umm, idp-conf-site which survives upgrades of the IdP.
If we try the Spring bean definition override idea, I guess we would need to declare bean definition ids as part of our API, we can add but not change or remove within a major version. That might provide an avenue for versioning flow definitions.
I am hoping to avoid rewriting an ${IDP_HOME} macro, either via Maven or an installation script.
TODO :
+ Nexus license
ugh
+ Unicon dta-ssl contrib
ping ...
Other