Developer Call Notes - February 10, 2011
Attendees: Kristof Bajnok, Scott Cantor, Steven Carmody, Jim Fox, Nate Klingenstein, Chad La Joie, Brent Putman, Rod Widdowson, Ian Young, Tom Zeller
- Still splitting apart existing code in to new maven modules
- xmltooling split is mostly complete
- openws and opensaml libraries still to go but should be more straightforward than xmltooling
- Need to determine how object provider and security configuration as well as bootstrapping will work in new version
- this will be a topic for the face-to-face meeting at the end of February
- OpenSAMLv3 code will be moved to new SVN server on February 11, 2011
- Redirects from the Georgetown to the Shib.net SVN server will be set up
- This will work fine for SVN views
- SVN clients are unlikely to follow redirects properly but that error will at least signal to people that something has changed
- Will svn+ssh be supported? No, the set up and maintenance overhead of this doesn't really buy us anything. Passwords are required to meet some relatively stringent requirements, people are encouraged to change their password routinely, and emails containing information on all commits are sent to everyone. Taken together it's unlikely that an attacker would be able to compromise a committer account and do bad things without people noticing. Committer accounts are independent of any machines accounts.
- Brent will include the PKIX options asked for by SWITCH. If any of them prove to be more than trivial to implement they will be postponed until v3
- Scott will look at the contributed dynamic metadata provider and, if it can be brought up to the level of the SP version in short order this will be added
- After having looked at it for a while, Rod will not be attempting to support a metadata regeneration feature
- Rod has completed a key regeneration command line tool. Scott asked if this could also produce PKCS12 files and Rod will look in to this.
- IdP initiated SSO support has been committed to SVN
- The IdP will contain three types of code modules (there will also be some modules dedicated to things like building the distribution)
- API modules contain the public APIs for the IdP and are the only thing extension writers should depend on
- IMPL modules contain "out of the box" implementations of various API interfaces, developers should never rely on these modules, they are not part of the public API
- SPRING modules contain the Spring-related configuration bits (e.g., namespace handlers, bean definition parsers, bean factories)
- API and IMPL modules should not rely on any Spring code so that people who want to use that code elsewhere don't have to pull in all of Spring
- The current StorageService will be replaced with
java.util.concurrent.ConccurentMap. The default implementation within the IdP will use Infinspan and so will be clusterable.
- SIDP-460 will be addressed in v3, not v2.3. Developers will discuss, at the face-to-face meeting, whether new authentication APIs provide support for this.