2013-12-06
Shibboleth Developer's Meeting, December 06, 2013
Attendees: Tom, Rod, Scott, Brent, Ian, Daniel
Call Administrivia
Dial-in attendee identification.
60 to 90 minute call window.
Next calls :
 December 13
 December 20
 January 10
Brent
Â
Daniel
Â
Ian
Â
Rod
Tied up on other business but
- Resources
- No Shibboleth Resources used inside MDA or IDP now (just spring)
- Services
- Currently under construction.
- SpringReloadableService is fully generic (and could load itself)
- Need to add failfast and reloadfrequency to idp.properties for AttributeResolver, AttributeFilter, Logback
- Need to move Mapper back into resolver (just as encoding is)
- Spring integration
- Need to review context usage.
- Also
- Generic Types
- Other cleanup
- Dependencies
- SPR-1112
Scott
Uber-import into Nexus: think we should probably move the central-disabling stuff into the release profile
Should create some scripts to download artifacts from Central and then upload to Nexus. Maybe next round.
SP 2.5.3 release/advisory done. Some concerns about RHEL 6.5 with OpenSSL bump, but I probably overreacted and doubt this will be a problem.
This week:
- started reviewing RelyingParty skeleton code, interfaces back to OpenSAML for security config
- de-Springifying some foundational profile actions and moving a couple into OpenSAML
- some cleanup (renaming) on the AttributeEncoder layer
- looking at existing SAML profile code so we can start planning out that work
Would like to have a document akin to what I did for Authentication that lays out the messaging- and profile-related contexts (need help from Brent probably)
Do we have docs on Attribute-related contexts?
A question from Christoph: would getting some time from Halm help with consent layer?
Tom
Weeks in review :
- Branching from active flows http://shibboleth.net/pipermail/dev/2013-November/002946.html
- SP release
- ParserPool changes ?
- Dummy keys
- AttributeResolver being a Resolver
- Spring 4.0RC1
- Maven central
- Checkstyle plugin update
- Remove super() ?
- https://issues.shibboleth.net/jira/browse/IDP-331
- Services
- Resources
- ACAMP v3 notes https://spaces.internet2.edu/display/ACAMPScribe2013/Tues+2pm+SalonsA-D
- Conditional subflows
- Maven plugin versions updated
- Maven dependency version updates (Spring, BC ?)
- AttributeResolver Predicate (was Criteria)
- Spring 3.2.5 bug https://jira.springsource.org/browse/SPR-11112
- Fail-fast
- ProfileConfiguration, SecurityConfiguration, RelyingPartyConfiguration
- Move non-IdP-dependent profile actions from IdP to OpenSAML
- https://issues.shibboleth.net/jira/browse/JOST-220Â IdP stopping metadata retrieval
AI : JPAR-35 : mostly done
AI : Pinged Unicon regarding dta-ssl plugin https://issues.shibboleth.net/jira/browse/JSPT-34
AI : File Spring bug for file:// base paths in flow-location-pattern
AI : Research testbed property replacement for class attributes ? http://shibboleth.net/pipermail/dev/2013-November/002948.html
AI : Ping Brent regarding question to dev list : OpenSAML and Jboss 7.1 classloading / endorsing http://shibboleth.net/pipermail/dev/2013-November/002969.html
...
AI : Add text to IDP-304 regarding HTTPResource : we will need to roll our own and possibly port to Spring. done
AI : Update Resolver javadoc.
AI : "mvn -C"
AI : Update appropriate wiki page for POM dependency|plugin artifact upload policy (see below).
AI : Disable Maven Central in release profile. JPAR-40
AI : JIRA issue for web flow ext authn, hope to engage Marvin, add DF as watcher, get text right via Scott.
AI : Maybe tag testbed and add as project to JIRA. IDP-343
AI : Help with wiki page documenting attribute contexts.
Â
Wrap-up
When adding or updating dependencies or plugins to a POM, upload all artifacts to Nexus via GUI or CLI.
Maven Central should be disabled in the release profile.
The Resolver interface represents a "searcher".
SchemaBuilder needs to be a proper builder and enriched with additional control over resource resolvers, including a no-source resolver, as primary concern is schema location.
Java-support exists to centralize common code, we should determine whether concerns represented there are truly centralized and move or remove as appropriate.
Okay with engaging with Halm regarding consent somehow.
Current ProfileConfiguration API may be too inflexible, perhaps we should set and get Properties rather than named fields.
Need to document attribute related contexts similar to authentication.
Â