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-08-19. Any reason to deviate from this?
60 to 90 minute call window.
This week's call will use the Lync system at OSU. To participate, call:
- +1 (614) 688-1800 (please use if possible)
- +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
Attendees
Scott,Tom, Ian, Rod, Brent, Daniel, Misagh
Brent
Daniel
Nothing to report.
Ian
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-961Getting 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.
- 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?
- 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)
- social / proxy authn and attributes
Sorting out 3.3.0 issues
Containers
- Tomcat SLF4J bridge logging test environment
- Windows and Jetty acces logging
- update the 3.2 branch ?
- Tomcat 8.5
- (Jenkins)
Re-do AQ test and ask Brent about encrypting NameID example
Research
- Git and cherry-picking between branches
- Docker
Other