Shibboleth Developer's Meeting, April 12, 2013
Attendees: Rod, Ian, Tom, Daniel, Brent, Scott, Paul Hethmon, Marvin
Next call is next Friday.
60 to 90 minute call window.
OpenSAML release is done, after closing some final issues out. Built a clean release env to use.
Advisories up next, then will pick back up with V3 work.
Checked in changes for LDAP connector bean parser. All the work is for V2 config support.
Security schema isn't moved over yet, used in the connectors for loading credentials.
Some questions about caching, V2 used EHCache, looked like we were moving to Guava's caching in V3? No information from team on it. Scott wasn't aware we used anything more than a hashmap in V2. Suggest we ping Chad about the choice and might just take the easy path to port over the older code.
- xmlsectool final snapshot / release candidate build and advertised, now testing. Expect to cut release Wednesday 17th.
- blacklist approach?
- MDA bugs: worth a release? Would require V3 parent release, java-support 1.0.1 or 1.1.0.
Hoping to move some UK federation work on to github for wider use by aggregator users without it being project development.
Suggested on list to work on unit tests for actions and contexts as a documentation tool. Scott agrees, suggests we both just iterate a bit on contexts and actions and tests and keep tabs on the overall alignment.
Willing to release V2 database-backed storage plugin to community and is willing to look at proposals for V3 API and perhaps assist.
Some time spent on doing a dry run of the QuickInstaller build. Took the opportunity to update to the latest Tomcat6 distro. I'll be writing up the (astonishingly tedious) process into the wiki asap. I really am looking forward to redoing this work in WiX.
The rest of the week spent doing the AttributeResolverDefinitionBeanDefinitionParser (sic). Some missing implementations and still some impedance mismatch still showing and under discussion with Tom:
- Do we parse (some) child Elements in the parent (as per V2)
- Or do we parse the child Elements as beans but "reach up" in the DOM for attributes in the parent which affect operation?
- Or do we parse the child Elements as beans and patch the behaviours in the doInitiatize() method.
each have their own advantages and disadvantages.
Otherwise it's "just typing", I hope to be done with Attribute definitions this week and then move on to the "easy" Data Connectors (in cooperation with Daniel). Then back to Attribute Filters (which are still only partially implemented)
FInishing up testing on 2.4, need to get security advisories from Brent, and need to write up upgrade material in wiki. Release probably mid-week.
Completed additional refactoring work on web flow, looking into how to reduce the complex boilerplate code in the actions by separating it from the execution logic, but need a place to store the data extracted from the message context. Could do this in two obvious places, the beans themselves (by making them stateful, non-singletons) or by creating one-off temp contexts in the context tree. Some concern about lack of experience with stateful web flow beans, but general sense is that using the context tree for scratch storage isn't a great approach. Scott and Brent both seem to prefer stateful beans at this point, Scott will try this out.
Also looking at dumping the Event annotation type and moving to a javadoc taglet approach, in turn should be able to move many existing actions into OpenSAML.
AI : commit maven-plugin version updates to parent poms after 2.4.0 release. Done.
AI : document naming convention for Spring bean definition parser tests. For example, TestSimpleAttrDefBeanParser.testBadValues() should read testSimpleBadValues.xml.
Recreated nightly jobs so that Jenkins should now be doing the right thing. Added a few more projects from utilities.
Have been thinking about gradle, ant, java, and spring-shell for installation and upgrades.
Some discussion about the installation issues. No strong feelings about the options. Marvin mentioned needing to do a custom installer at VT, may need to get more input from the community about the real needs here.
IdP 2.4.0 Release
Brent working on advisories today for TLS issues, release probably early next week.
AI for Marvin: document Context objects needed for authentication.
AI for Scott : Authentication Actions, Contexts, and flows.
AI for Tom : document current state of Action API, inputs and outputs.
Coding convention : getLdapUrl or getLDAPURL
Tabled for further discussion.