2015-09-18

Shibboleth Developer's Meeting, 2015-09-18

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 2015-10-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 (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

  1. JPA DDL / compatibility
  2. SPNEGO / Kerberos
  3. SLO and SPNEGO timeline / 3.2 impact

Attendees:

 

Brent

Finalizing delegation flow.  Have provisional authN and subject c14n worked out, need to decide on the exact approach we'll use.  Remaining bits are around policy enforcement.  Also need to circle back around and make changes we have discussed around assertion delegation.

 

Daniel

JPA related links:

Ian

 

Marvin

Nothing to report.

Rod

On vacation

Last week spent in various Spring parsing activities as tracked in Jira. 

  • Flatten the afp namespace
  • inject a named bean into the Scripted beans

 

Scott

Metadata reload investigations: still trying to get clarification on what people have been seeing, but logging bug is inambiguously a problem. V2 discussion will wait for Brent to get back.

  • Updated heap guidance to 1G: should we message this more loudly for existing installs? Add a warning at startup or status page?

Working on the bottomless pit of complex authn bugs, fixed a couple, need to start thinking seriously about a new example flow for supplemental factor use, see thread w/ David Walker on dev list

TIER kickoff meeting

Tom

Mostly working on refactoring BaseIntegrationTest to support testing (a) multiple server configurations and (b) multiple browsers in parallel.

  • Each test method receives an object representing the desired/current browser and server configuration, which can be modified before being started
  • After being started, the browser needs to know the server endpoints (maybe random ports, private/public addresses when testing remotely)
  • A particular server configuration should probably only be started once
  • After each test, all servers and browsers are torn down
  • The model for sharing the browser and server configuration is TestNG's DataProvider which returns Object[][] or Iterator<Object[]>. Conceptually Object[][] seems easier to think about, but programmatically the Iterator seems more straightforward, where each thread when running in parallel operates on an Object[] received from the Iterator.
  • Abstract JettyServerProcess -> ServerProcess
  • ServerBuilder copies a source/template idp.home and has static methods to replace properties, regexes in files, uncomment XML, etc.
  • Thinking about exposing some IdP configuration information, e.g. env properties, via a @Controller added to the IdP via web-override.xml like I did for the storage @Controller in the testbed. Otherwise, need to write fields, getters, and setters for "every" configuration toggle in order to expose them to test methods.
  • Point being : it might be "easier" to configure the IdP for testing via the browser in each test method.
  • Can't find the JIRA, but ultimately this feels like "-t".

 

Misagh (Unicon)

Will try to make the call. On the OpenIdConnect front, basic protocol functionality and SSO is functional. Will have a demo for TechEx. Working on server-side storage, client registration and attributes next, which probably won't make it for the demo. 

Daniel Lutz (SWITCH)

Attending to discuss SPNEGO login flow.

Working on SPNEGO login flow.

  • Architecture of the SPNEGO login flow
    • The first release will probably provide a standalone SPNEGO login flow only, no combined view for Password and SPNEGO.
    • Scott will look for a general way to plug-in alternative login methods to the Password login flow. (This use case is not restricted to SPNEGO.)
  • We implemented the external authentication part of the SPNEGO login flow using an MVC controller instead of a servlet.
  • The SPNEGO login flow will support conditional activation, flexibly configurable via JavaScript (e.g. activation based on the client's IP address or some token in the user agent' identifier string).
  • The login flow will be called "SPNEGO" instead of "SPNEGOKerberos", but will be restricted to support Kerberos only.