Shibboleth Developer's Meeting, March 22, 2013

Attendees: Tom, Scott, Rod, Ian, Brent

Call Administrivia

Approve minutes from last week.

Next call is next Friday.

Agenda bash.

Brent

Working on V2 bugs. Mainly the HTTP client overriding of TLS socket factory issue. No success in doing that with the V3 client. Suggest we punt, and document that all disregardSSLCertificate options should be the same across providers.

Scott: is it a predictable order now?

Brent: probably document order, first in wins. But now we always override the socket factory, so it's a bigger deal now.

Scott: do we verify hostname if the flag is set?

Brent: no, all or nothing

Scott: that's ok, we can revisit more extensively later

Brent: A number of issues were found on the metadata code's fail fast behavior, and handling different edge cases, some fixed, a few more to work on, plus better unit tests. A couple of additional bugs.

Brent: want to look at the release process

Tom: we should all go through that piece, esp. the scripts, maybe schedule some time for that?

Scott: suggest within couple of weeks. Probably looking at early April release

Daniel

Work : Attribute Resolver LDAP and RDMBS connectors.

Next : Spring wiring ?

Next : LDAP integration tests ?

(Daniel missed call due to conflict.)

Ian

Work: Pending XmlSecTool 1.2.0 release.

Ian: Lot of interest in the release, several people have tested snapshots. Goal is to get something out so we can avoid revisiting this year, likely to revist it when V3 is stable. Primarily support for varying algorithms, some EC support, blacklisting algorithms for verification, and some issues around PKCS11.

Want to transition from jargs to jcommander at some point. jargs is not Apache licensed. Wait until next major release.

Release likely late April.

No unit tests at the moment, might need to be made more modular for that.

Rod

Work : Attribute Filtering

Rod: code is in there, metadata filters not done, some context filters not done, at least one bug known. Tom at least had some concerns about the code complexity, we need to dig into that soon because it may be a question of changing requirements.

Scott: worth trying to create some base class code to easily mock up attribute data for unit tests?

Rod: I can move a class for testing the resolver that generates data into test class for producing test data.

Rod : V2 scripting environment: want to document the V2 environment made available to current resolver/filter plugins. Then look at how much work it will be to support V2 scripts in V3. Goal is to avoid changing configs, but this is a tricky area to stay compatible.

Rod: Can we use the Spring wiring work to facilitate unit tests of this code?

Tom/Scott: Yes, think that's possible, should be better than mocking things up.

Scott

AI : Review DataConnector Validator interface for fail-fast override capability ?

Didn't discuss on call, but Scott reviewed this a bit. Definitely seems like more of a convenience/code separation issue, because you really need access to the connector implementation to build one of these. Will suggest to Daniel that we include fail-fast validators in the code along with the regular ones. Reason being, they can still try to get connections but can log the failure and then swallow the error. Also probably want to have a validationQuery capable validator for JDBC.

AI : Further thoughts on setting up an Active Directory VM for integration/unit tests ?

Work : Pending IdP 2.4.0 release.

Scott: Not much done apart from updating dependencies.

Tom: Can we provide that list to users with the release?

Scott: Yes, I think we should do pages on new features and important changes in the wiki, similar to existing SP pages.

Scott: Need to test the updated logging code. Also looks like we had already moved off of Java 5, so we should be able to remove scripting jars. Final question was around svnkit. Should be move to 1.7? Looks like that makes working copies invalid, so this would be a hassle since there's no svn update command to run.

Brent: Maybe just move to 1.6 for now?

Work : AACLI

Scott: Some preliminary examination of code and looking into how a webflow might work without a web server. Seems like the Mock objects for unit tests may be the only obvious way to run a flow that way. There's a blog post about doing a Console webflow app, but the example code is long gone.

Scott: Had suggested to Tom offlist that maybe we can separate the webflow aspects from the Actions entirely and build a single adaptor class to translate inputs and outputs. Advantage would be to support moving action code down into opensaml.

Tom

Tom: ok with Scott investigating ways to split up the WebFlow/Action code. Want my role to be providing the framework for SAML expertise, CAS expertise, etc. to do their action breakdowns.

Finishing up some transitioning of I2 work, still taking up some time.

Want to do some more cleanup of the early Spring wiring code.

AI : Email list regarding Active Directory test instance ? Prefer our own.

AI : Set up weekly calls with active IdPv3 developers. Done.

AI : Figure out establishing a handful of alpha testers ?

Note : Need to deal with references to edu.internet2 in configuration files.

Work : Attribute Filter porting design with Rod.

Work : Profile Action interface design with Scott as well as Marvin.

Work : Experimenting with git with Rod and Marvin regarding design work.

TODO : Review commits.

TODO : Clean up Spring wiring pattern in idp-attribute-resolver-spring and idp-core.

FYI : Call with David Langenberg assigning my open I2 JIRA issues to him.

Decisions

Coding convention : getLdapUrl or getLDAPURL ?

Not much consensus other than to make sure we're consistent. Brent favored camel case in the specific examples of having two acronyms back to back. Scott favors predictability, so would favor just using camel case for everything if we did it in some cases. Some discussion about earlier idea to find volunteers for some of the code refactoring if we have to change a lot.