I skipped an update in July due to the workload of getting the SP finished, which has been dominating the work for least a couple of us most of the last few months, and I'm happy to note we finally shipped 3.0 (and 3.0.1 and 3.0.2). Given the magnitude of the internal changes, I'm reasonably happy with the results so far as the bugs have been easy to fix, and the release process is now more streamlined than before due to huge improvements in the Windows build process and the elimination of Solaris as a supported platform. That means patches come more quickly. Most people I think will find the upgrade to be painless, which is good since we very quickly hit a security issue that impacts all the older versions.
The documentation is about 50% reviewed and cleaned up at this point, better than I hoped but not as good as I would like. It's at least better organized and out from under the old IdP material.
In between patches work has picked back up on the backlog of IdP issues and features. I finished up and started documenting a new feature for limiting access to keys by requiring attended startup of the service, which is a weird concept but is about the only way I can see to protect private keys in a cost effective way. That was done on OSU time donated to the project so we can make use of the feature.
I'm starting work on extending the Duo login flow to include support for non-browser clients using work donated by UMBC and it should hopefully require minimal effort by existing Duo deployers to enable.
The IdP is now leapfrogged again by the SP in terms of some of the dynamic metadata features, so we're circling back to add some of those features into the IdP now that some more deployment experience is available.
We're also finishing up work on a stable configuration set for Jetty 9.4 and are discussing how to make that available to deployers. The embedded version for Windows will be updated to that version and we would like to make deployment on other platforms easier by delivering a customizable starting point that will mostly work out of the box and then be simple to extend. Hopefully we can help people stay current by shipping base configuration sets that can be used to jump start upgrades of local container installs without actually taking on responsibility for the installs ourselves.
The Java platform situation remains very fluid but we now know from Oracle's public statements that their JDK is about to become a for-fee product with Java 11 and that free use will require use of OpenJDK. It is unknown whether there will be free options for OpenJDK support that last longer than the 6 months Oracle will be patching each version of OpenJDK, so there may not be anything like a "long term" Java version that we can rely on for future products. At minimum, this means we have to revisit our recommendations for JDK usage, and at worst it may mean adapting to a much more rapid development cycle to keep up and maintain compatibility. That in turn means more time and money devoted to testing and maintenance.