2016-08-19

Owned by Scott Cantor
Last updated: Aug 31, 2016 by Tom ZellerVersion comment
2 min read

Shibboleth Developer's Meeting, 2016-08-19

Call Administrivia

10:00 Central US / 11:00 Eastern US / 16:00 UK

Calls are normally the 1st and 3rd Fridays of each month. Next call would be Friday 2016-09-02. Any reason to deviate from this?

60 to 90 minute call window.

 

Call Details

This week's call will use the Lync system at OSU. To participate, call:

  1. +1 (614) 688-1800 (please use if possible)
  2. +1 (800) 678-6114 (use only if you're charged for the 614 number)

The Conference ID is: 738127#

International participants should be able to access the 800 number without charge through Skype.

AGENDA

  • XMLSecTool functionality question I think the consensus here is to generalize the metadata aggregator

 

Attendees

Scott,Tom, Ian, Rod, Brent, Daniel, Misagh

 

Brent

 

Daniel

Nothing to report.

Ian

Life keeps slapping me in the face. Nothing to report.

Marvin

Nothing to report.

Rod

Mostly OpenSSL1.1

  • XMLSec compiles and tests OK
  • Adding test to XMLTooling to check against typos (was that r->g or r->q?)

With a side swipe across the Curl Build

  • We need to revisit how the dependencies are rebuilt.  Sometime

Moving back to attribute namespace squashing

Scott

Some work on documentation, created IntegrationGuides template for people to use for documenting services. As expected, there's virtually nothing to do with Shibboleth at all outside of a few settings and NameID work.

Spring – noted their plan is for Java 7 (really 6) support through 2019, so we should be off it by...2018 at the latest?

IDP-961 - Getting issue details... STATUS

  • Work is moving along, think I have a workable design, just down to implementing and wiring now.
    • Each admin flow will be able to individually enable the login flows to allow (if any) so it won't have to overlap with user authentication except as desired, and they'll be able to have configurable authentication requirements.
  • Something I wish we'd done: separate the XMLObject interface from the actual interfaces exposed by the XMLObjects. That is, Assertion in one interface, XMLObject in another, and have implementations implement both. Maybe impractical in Java, but would be really nice to expose a data interface matching something in SAML without needing to include the XML machinery.
    • Alternatively, is it possible to build a generic factory bean capable of building an arbitrary XMLObject?

Tom

Related work :

  • ask Scott about tieing browser activity to the session the user experiences (again) start dev thread
  • social / proxy authn and attributes

Sorting out 3.3.0 issues

Containers

  • Tomcat SLF4J bridge logging test environment nope, no one has one
  • Windows and Jetty acces logging
    • update the 3.2 branch ? no
  • Tomcat 8.5
  • (Jenkins)

Re-do AQ test and ask Brent about encrypting NameID example do a dev thread

Research

  • Git and cherry-picking between branches yes, cherry-pick is appropriate to make the same change to multiple branches
  • Docker

Other