Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Shibboleth Developer's Meeting, 2016-08-05

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.

 

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

  1. Flattening the IdP attribute resolver namespaces? ... Or redo dependenices? .. Or neither?... or both?
  2. TIER packaging direction
  3. Dynamic metadata caching
  4. U2F approach
  5. 3.3 timing/scope
  6. Source/target 1.8? Are any other dependencies at risk of moving there? Spring?
  7. Token binding and SAML – mandatory vs. optional semantics

 

Attendees: Scott, Brent, Tom, Marvin, Rod

 

 

Brent

Still continuing work on artifact resolution, which also includes some metadata resolver and SOAP components.  Somewhat stalled on this for the last couple of weeks.  Also dealing with the usual GU pre-school year crunch work load.

 

Daniel 

I've got a conflict today. I will try to join late.

  • Jira Legacy
    serverShibboleth JIRA
    serverId180d847f-bce4-36b2-9964-771bff586829
    keyIDP-975
    • Added support for external credential (file or classpath) to ldaptive
    • Still have given up on getting JAAS to resolve any property
  • Fixed some LDAP resolver bugs:
    • Jira Legacy
      serverShibboleth JIRA
      serverId180d847f-bce4-36b2-9964-771bff586829
      keyIDP-1010
    • Jira Legacy
      serverShibboleth JIRA
      serverId180d847f-bce4-36b2-9964-771bff586829
      keyIDP-1011
  • Working on cryptacular release with BC 1.54 support

Ian

 

Marvin

  • Reviewed MFA work and am very pleased; both capabilities and docs are very good. Plan to follow up with some comments and suggests on Scott's dev thread from a couple weeks ago.
  • Work on https://issues.shibboleth.net/jira/browse/IDP-996 hopefully next week
  • Put CAS storage refactoring in scope for 3.3?

Rod

...

  • OpenSSL 

...

    • Simplified Windows build
    • Santuario XMLTooling clean compile, Santuario tests pass
    • Looking at Ubuntu compile (not working)
    • Running XMLTooling tests on windows next
    • Curl Build changes

 

Scott

 

...

  • Completed MFA work and documentation, review welcome, suggestions on what to include as a default example
  • Completed Duo work, pending what to do about failure modes
  • Started looking at U2F, added to agenda
    • BouncyCastle mess – uploaded cryptacular 1.1.1-SNAPSHOT
      • should I just check in updated POMs overriding the versions for now?
  • libcurl advisory – conclusion we're not impacted

Tom

  • Pushed most of the attribute query integration tests, need a little help with encrypting.
  • Todo : configure idp-tomcat-base for back-channel and run tests
  • Todo : run back-channel tests on Windows, Tomcat and Jetty
  • Todo : clean up / simplify Jenkins integration test jobs
  • Todo : artifact and SOAP logout
  • For Rod : is it possible to run the Windows installer unattended ? are there docs on unattended Ant (non-Windows) install ?
  • Some notes from the field :
    • Somewhere on the wiki regarding next steps after installation we probably should document configuration of conf/access-control.xml to enable scripts such as bin/reload-service.sh. My guess is that deployers will be adding the IP address that the IdP is listening on. Then they need to wait 5m for the automatic reload before being able to use the scripts. Makes me think that we could add an option to CLI.java to select the source address, for example localhost, since access from localhost is allowed by default.
    • I wonder if it is possible or worthwhile to be able to add a new metadata provider without reloading the existing providers, such as a large federation aggregate, for example. Maybe it could be done by nesting large metadata aggregates in their own Spring ApplicationContext as a child of some common context of the MetadataResolver. Or maybe the minute or two it takes to load large metadata aggregates is a non-issue for folks or merely a local issue.

 

Other