Shibboleth Developer's Meeting, 2020-06-05

Brent

Daniel

Henri

• Jira Legacy
  server Shibboleth JIRA serverId 180d847f-bce4-36b2-9964-771bff586829 key JOIDC-5

  
  
  • MDDriven profile configurations working as expected
    • Will check with 

      Jira Legacy
      server Shibboleth JIRA serverId 180d847f-bce4-36b2-9964-771bff586829 key IDP-1608

       next week
  • Added ClientSecretReferenceKey -element to the schema
    • Simple resolver interface extending Resolver<String, CriteriaSet>
    • Initial implementation for Properties resource
      • How to make it refreshing whenever metadata provider is refreshed?
    • Other implementations? Perhaps HTTP (using the approach from HTTP data connector)?

Ian

...

• (Maybe an agenda item) Thread safety is hard:
  • Arises through 

    Jira Legacy
    server Shibboleth JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 180d847f-bce4-36b2-9964-771bff586829 key MDA-242

  • Things in both the MDA and our other code claim to be @ThreadSafe when they are, strictly, insufficiently synchronized.
    • There seems to be a widespread pattern where setters are synchronized while getters are not. As this is dominant in older MDA code, I think it may come from Chad originally.
      • From Gaetz's book: It is a common mistake to assume that synchronization needs to be used only when writing to shared variables; this is simply not true.
      • You need to synchronize both setters and getters to get the visibility guarantees I think you want.
      • If you're using something else to get those guarantees, then you are probably @ThreadSafeAfterInit and not @ThreadSafe and you don't need either setters or getters to be synchronized.
      • Simple example would be AbstractInitializableComponent, which just has getters but none are synchronized. (There is synchronization on the effective setters initialize and destroy).
      • Or, MessageLifetimeSecurityHandler where setMessageLifetime is synchronized but getMessageLifetime is not.
    • Sometimes code just refers to the field instead of the getter anyway.
  • We probably get away with this because:
    • roperties aren't set after initialization.
    • Everything is initialized on one thread and then other threads are created to do the work. As long as these are explicitly started later or initiated by classes such as Executor, visibility is guaranteed by the library (not the language).
    • Real processors don't buffer writes forever, anyway.
  • I can't find anywhere we have documented our approach to writing concurrent beans.
  • I think there are two consistent positions:
    • Objects are @ThreadSafe and get there by either:
      • If having constructor arguments, having only final fields.
      • If an InitializableComponent, having every setter and getter synchronized and never referring to fields except through the getter.
      • Some combination of the above and other techniques to make the object fully thread-safe.
    • Objects are @ThreadSafeAfterInit (obviously only applies to InitializableComponent )
      • Setters and getters need not be synchronized. User constraint that creation of the object and all steps up to and including initialize must be performed on the same thread before the object becomes visible to another thread.

Marvin

Rod

• • ; full discussion there.
  • A lot of things we say are @ThreadSafe really aren't, although they are mostly @ThreadSafeAfterInit and other things probably conspire to mean we're probably OK in practice. This makes me uncomfortable.
  • It's not possible even in principle to make most things truly @ThreadSafe because of 

    Jira Legacy
    server Shibboleth JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 180d847f-bce4-36b2-9964-771bff586829 key JSPT-97

    .
  • We could fix that (and I think we should, see this commit) but that wouldn't address all the issues, just make it possible to do so for cases we care most about.
  • Beyond that, I don't think really nailing this down is going to be felt to be worthwhile, but we might want to document some assumptions and change some annotations anyway.
• Building from Docker containers: iay/shibboleth-build-docker seems to work

Marvin

Phil

• IdP release using two docker images worked well. The second image was used for building site under JDK14 to fix the search apidocs bug.
  • Modified Javadoc plugin seemed to do its job - drawing a line under that for now, and I did not need to swear. 
  • It can be a bit slow when generating site (Javadoc), just make sure to build inside the container.
  • Detailed instructions on Ian's Github page for all these things.
• Duo 2FA OIDC plugin
  • I have not provided too much input to Rod's plugin work the past few weeks as just trying to get the flow together.
    • Would hope to reengage later on when I actually need it to work as a plugin.
  • Using a Spring Controller to handle the external call and callback - a bit like the SAML proxy controller. 
    • Was debating whether to actually encode the webflow execution key in the State parameter alongside a CSRF type nonce? 
      • Otherwise stored outside the webflow conversation and inside the HttpSession - assuming the redirect_uri does not become an option i.e. Duo not being strict on dynamic query params.

Rod

• Mdolue instalation stalled for want of hours in a day
• Built VM soley to do windows installer builds
• What to do about Java7/8 on Windows and the multi tests?
• Am about to have to install Visual Studio 2019.  Do we want to think about this for SP 3.2 (given we that it may impact on our dependencies)

Scott

• Documentation
• Minor 4.1 work
• Web site, moving community content into WEB wiki space
• EC2 instance running PrivacyIdea
• Would like to start steering "roadmap" content into Jira

Tom

Other