Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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

  • Flattening the IdP attribute resolver namespaces? ... Or redo dependenices? .. Or neither?... or both?

 

Attendees:

 

 

Brent

 

Daniel

I have a conflicting meeting today. Will try to join late.

  • IDP-975 - Getting issue details... STATUS  I've added the ability to reference an external (file or classpath) credential in ldaptive. Still haven't given up on a generalized solution.
  • Preparing cryptacular release to address BC 1.54
  • Fixed a couple LDAP resolver bugs

 

Ian

 

Marvin

 

Rod

 

Scott

 

Tom

  • 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

 

 


  • No labels