October Update

Created by Scott Cantor
Last updated: Nov 06, 2017
3 min read

Highlights of the last month of work:

  • the recently-release IdP 3.3.2 IdP patch and security advisory
  • some development on IdP 3.4
  • ongoing cleanup work with the SP code/build and dependencies
  • getting Java 9 support into our Jenkins builds and some reconnaissance on it
  • prepping for managing access to the new support mechanisms

The most recent bout with defaulting the handling of TLS verification in the LDAP code has led us to deprecate that approach once and for all going forward, and we will be requiring explicit trust configuration of LDAP connections in 4.0. We're still going to have to study the impact on metadata configuration, but that's much less sensitive to this issue in current practice. We will have to consider the impact moving forward as federations transition to query-on-demand approaches, and we fully expect some federations will decide that signatures aren't what they want to do, whatever our opinions might be. But as a project, we are committed to the idea that security needs to be explicit and not left to the behavior of code we don't control.

The other major addition to the patch was a feature addition, which is not typical, but I felt was warranted because the timeline for 3.4 is unknown and I wanted to make sure the supported version included the ability to generate computed pairwise IDs that are safe for case-insensitive applications, of which there are many. Obviously this is a lost cause for many deployers today, but if we can make life better for the new ones, that's a good thing.

A new feature for 3.4 that was completed this week is something requested by one of the newer Consortium Members, a way to impersonate users for testing purposes that comes up in a lot of deployments. I knew that it could be done both simply and (I hope) safely in a particular way so I felt that it was worth spending a few hours on an example we can include in future releases. The documentation on that will be forthcoming but it's already engendered more discussion on the development list than I've seen in months. I firmly believe testing and test accounts is something that a production IDM environment should deal with directly and not leave up to applications or the IdP, but I also know from local experience that convincing IDM teams of that is a lost cause for many sites. Hopefully this will help.

Java 9 is out, and is a huge change to the Java platform, probably the biggest ever. We're still getting our minds around it but it will be a while before we consider what we might need to do to take advantage of it. More immediately, Java 8 will also be EOL by next September, as expected.

On the support front, we're on track to start rolling out the new options next month and begin to phase in that model through the end of the year. The management of all this is not perfect or where one would like it, but we're sensitive to the amount of time we can afford to spend on managing the way we do this, and we have a lot of existing system behavior with JIRA that limits how much we want to change things. I can definitely say that if JIRA had a way for us to offload the group management through, say, an entitlement attribute, we would explore that, but right now the Support Desk module does not rely on JIRA's own group mechanism for grouping customer accounts. I hope that changes at some point.