Work over the past month has included:
- Research into some complex bugs and behavior that were in the backlog.
- Progress on some of the more complex work scheduled for V4.1
- Work to cleanup and stablize the MDA API for the eventual 1.0 release of that software.
The recent Comodo CA expiration resulted in the observation that the IdP's behavior in the case of LDAP and HTTPS certificate evaluation was different (an expired trust root worked for LDAP, but failed for HTTPS). This took a significant amount of investigation to understand, but we discovered that Java actually has two different PKIX certificate validation libraries built in, and both are being used. One accepts expired roots and the other doesn't. This isn't ideal, but messing around in those layers is even less ideal so it's likely to continue behaving this way.
On the 4.1 front, work on the new plugin architecture continues and we're building several test cases for it around new features that we would like to keep out of the core. The intent is really to try and start delivering more features outside the core release process so they can be maintained with more agility, and in the process probably move to a more regular cadence for the actual software itself, to focus it more on bug fixes and library maintenance. Success will ultimately be measured by the ability to make the deployment process seamless in the sense that it shouldn't matter a great deal whether a feature is part of the core or in a plugin.
Initial plugin work includes:
- Scripting alternatives to accomodate the removal of Nashorn from Java 15+
- Implementation for the next-generation Duo WebSDK
- A TOTP login flow based on a Java port of Google's OATH library
Work on all of them is in various stages of advancement.
One thing that probably distinguishes plugins from core work is the impact on schemas. When it comes to new functionality added to the metadata resolver, attribute resolver, or filter services, which are essentially the remaining components that rely on "custom" configuration schemas, it will be much simpler to continue to include those components in the core software in order to prevent further pollution of the configuration by other XML namespaces to prevent conflicts. An example of this is a new feature to support decrypting data in the attribute resolver. The TOTP feature requires the ability to potentially decrypt token seeds, so rather than build that into the feature directly, a more generic capability was added to the core, and the plugin can leverage that feature for its specific needs.