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.

TODO :

+ Nexus license

ugh

+ Unicon dta-ssl contrib

ping ...

Other