Shibboleth Developer's Meeting, October 11, 2013

Attendees: Brent, Daniel, Ian, Scott, Tom

Call Administrivia

Dial-in attendee identification.

Next call is next Friday. Any reason not to meet ?

60 to 90 minute call window.

Brent

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

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.

Daniel

Ian

Rod

Apologies.
Working on an mdrpi filter for the UK Federation which we may want to accept into V3.  More next week 

Scott

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?

Tom

Summary of previous discussion :

+ vt-crypt

 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.

+ Infrastructure

Jenkins : Ian, when do you have time again ? Later ?

Yes

Carryover :

+ 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

https://github.com/Unicon/shibboleth-tomcat-dta-ssl

http://marc.info/?l=shibboleth-dev&m=138065948329556&w=2

AI : Tom follow up with message to dev list.

+ Infrastructure

Nexus upgrade - no luck with previous contact.

Remove unsubscribe footer from mail lists ?

Remove /confluence from path ?

New:

+ 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

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.

+ Rod

When you have time, catch you up with where I'm at and help me think about install issues ?

TODO :

Nexus license.

Understand Scott's Session work.

Other