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 3 ? 10

Brent

Daniel

Ian

Rod

Scott

Tom

Other

Tied up on other business but

1. Resources
   1. No Shibboleth Resources used inside MDA or IDP now (just spring)
2. Services
   1. Currently under construction.
   2. SpringReloadableService is fully generic (and could load itself)
   3. Need to add failfast and reloadfrequency to idp.properties for AttributeResolver, AttributeFilter, Logback
   4. Need to move Mapper back into resolver (just as encoding is)
3. Spring integration
   1. Need to review context usage.
4. Also
   1. Generic Types
   2. Other cleanup
   3. Dependencies
   4. 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.