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
Spent a lot of time getting up to speed on the changes in HttpClient 4.2 to 4.3, and looking at how to reconcile java-support's usage of these classes.
Cleaned up remaining HttpClient-related TODO's in HTTPMetadataResolver.
Some further work on abstract dynamic MetadataResolver.
Daniel
Ian
Rod
Scott
Reworked config in testbed to move as much out of classpath as possible.
Experimented with different property-based approaches, mostly parked IDP_HOME issue for now.
Worked on rationalizing user-end config of login/session/flows, and did some debugging/improving of login code.
SSO now working as intended with session layer.
TBD: probably extend AuthenticationContext/AuthenticationResult with a custom Principal member signifying "the custom Principal to be included in a profile response that satisfies the SP's request criteria". In SAML, this determines what ends up in AuthnContext.
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