Shibboleth Developer's Meeting, October 11, 2013
Attendees: Brent, Daniel, Ian, Scott, Tom
Dial-in attendee identification.
Next call is next Friday. Any reason not to meet ?
60 to 90 minute call window.
Finished out a lot of dynamic metadata abstract base class.
Spent a lot of time this week getting much more up to speed on HttpClient, and specifically v 4.3, which has some differences from 4.2. Took notes/digest from their tutorial: https://firstname.lastname@example.org/HttpClientNotes
Next up: refactoring some existing HttpClient usage based on what I now know about the library, in both existing HTTP metadata resolver and new dynamic resolver. Continue with concrete impl(s) of dynamic resolver and testing.
Working on an mdrpi filter for the UK Federation which we may want to accept into V3. More next week
Working on glue between session manager and the container / cookie mgmt process and drafting the few actions left that deal with sessions before and after authentication subflow. Starting on Spring config for the session manager objects, not sure how best to organize this yet.
If we use imported bean files, can a bean being imported reference a bean in a different import? Can we declare default init and destroy methods even if not all beans actually have those methods?
Using injected HttpServlet* objects in SessionManager, and built a CookieManager class to consolidate managing cookie path/domain/secure etc. Built a filter for preventing cookie duplication in responses, but needs testing and probably changes.
Would like to keep cookies out of StorageService layer, rebranded the client-side store interface as "RequestScoped" to reflect this.
Working out how to handle load/store of request-scoped storage data at beginning and end of servlet processing. Was thinking about using a filter, but would like to avoid if possible because of need to inject StorageService into filter. Now thinking perhaps I could handle the "save" step that creates the value of the eventual cookie by subclassing Cookie and implementing an on-demand getValue() method that would serialize the stored data "just in time" for inclusion in the Set-Cookie header.
Actual serializing of data, not sure yet. Could just serialize Java Map(s), but probably too big. Could use JSON, but lots of embedded JSON and additional characters for "escaping". Could look at Kryo or some other third party option to optimize size. Probably will start with JSON for now and see how it looks.
Believe I'm on target for completion of session layer this month.
Meta-thought: should we be thinking in terms of a properties file or just a separate beans file to define strings representing the settings users would typically want to change, and then set actual bean properties using those strings? Basically externalize the settings likely to change for basic deployers while keeping the bean files themselves untouched for upgrades?
Summary of previous discussion :
Aim release supporting latest BC for 2014Q1.
+ rename java-parent-project-v3 to java-parent-project
Background : need to tag and release upstream dependencies of MDA.
It is unclear what "v3" means across all projects, leave project name as is for now.
We should decide and document a Versions convention for JPAR.
MDA release maybe towards end of month.
+ Attribute -> IdPAttribute
I think Scott wants to rename Attribute while I want to add an IdPAttribute interface, I need to look again.
Although (Tom was) originally opposed, okay to rename Attribute to IdPAttribute based on convention that we align with the SAML spec, where Attribute = SAML Attribute. Work with Rod to determine extent of IdP* prefix.
+ AttributeDefinition, DataConnector, BaseResolverPlugin interfaces
Okay with adding those interfaces, see next note.
+ Abstract* and Base* naming convention
When adding interfaces above, Base* -> Abstract*. I thought Base* -> Default*, my bad.
Jenkins : Ian, when do you have time again ? Later ?
+ Rod : When you have time
IdPv2 issue and porting to v3, tests.
Annotate and clean up idp-attribute-*-spring.
Test contributed v3 attribute-filter.xml files.
+ Tomcat7/8 dta-ssl contribution
AI : Tom follow up with message to dev list.
Nexus upgrade - no luck with previous contact.
Remove unsubscribe footer from mail lists ?
Remove /confluence from wiki.shibboleth.net/confluence ?
+ Third-party naming convention for getHttpClient vs getHTTPClient = match third-party usage (Brent).
+ Helper vs Support = Support (Scott).
+ Serializing XMLObject (Scott).
Punt to dev list.
+ Injecting ServletRequest/Response pattern (Scott).
No objections, move forward.
Jetty 9.1.0 RC default way to upgrade Jetty via jetty.base.
How do we determine the version of Jetty to recommend? Background : SSL session ID cache bug with 9+.
+ idp front end
Where I'm at with why we need to run the IdP on more then one port.
Can metadata be a TrustStore ? (Pretty clueless here, will ask for background)
Basic summary is that folks are too nice to question my sanity on a public list. Running anything as root or running split v2-v3 as an incremental upgrade were concerns. Will park idea. Still think that the Jetty BalancerServlet might be interesting to some deployers.
When you have time, catch you up with where I'm at and help me think about install issues ?
Understand Scott's Session work.