Release plan for 2.0.0

[consideRatio]

This is a dependency of z2jh and tljh that hasn't been updated in a long time. I'd like to get one release out that is known to work with jupyterhub 4 at least.

Action points

• maint: general jupyterhub org repo maintenance updates #221 (actually merged, github just bugged!)
• Add end to end test to ensure compatibility against various jupyterhub versions #222
• Consider helping the following PRs land, open currently, from oldest to newest
  • Added tls certs and keys settings #87
    This is a crucial fix resolving many reported issues, but introducing it isn't breaking, so it doesn't really have to come before 2.0.
  • Add slightly better Active Directory support #94
  • Allow users to configure group search filter and attributes (group_search_filter and group_attributes config) #168
  • Allow multiple LDAP servers #184
  • Allow secondary LDAP servers #190
  • Add admin_groups to grant admin access to users of these groups #198
  • add option to check allowed_groups with the configured ldap search user #207
  • Add manage_groups and group_search_based config #213
  • Add a new option: use_tls #216
  • Add new feature: refresh_user #218
  • Escape user- or ldap-provided strings in ldap search filters #238
• Go through and triage issues

[kimkihoon0515]

great

[consideRatio]

Some issues/prs I'd like to highlight

• Bind operation happens twice which can lead to 2 multi-factor authentication pushes to users.  #126
• Add tls_strategy and deprecate use_ssl #258
• Support allowed_users and admin_users #260
• Allow configuring ldap3's TLSObject/SSLContext #49

[manics]

Which of these do you consider blockers for 2.0.0?

[consideRatio]

I'm not sure, but I'd like to keep going a while and when I run out of steam try to answer that with a better overview.

[consideRatio]

Here are things I'm currently thinking truly must resolved before 2.0 @manics:

• Escape username within DN correctly and remove escape_userdn #267
  Currently blocked by review input.
• Fix broken tests for jupyterhub 5 #246
• Evaluate allowed_users etc function side by side with allowed_groups etc - can they be used together, and if not, is it a breaking change to fix it? If so, we should fix it now.

I think we should resolve the following as well, but they could come in a followup minor release as well.

• Allow configuring ldap3's TLSObject/SSLContext #49
• Bind operation happens twice which can lead to 2 multi-factor authentication pushes to users.  #126
  Simple to fix, I'll get it done. Its not truly a blocker, but its such a clear bug that has a simple fix making me want to get it part of the next release.

[minrk]

Thanks for leading all this! I can have a stab at #246. allow config is very likely the cause.

[manics]

When this is ready do you think we could release a beta first, to give more time for reviewing the authenticator as a whole, especially after the security changes?

[consideRatio]

Let's do a beta release to be part of tljh / z2jh beta releases, where kubespawner probably needs a beta release as well for z2jh

[consideRatio]

2.0.0b1 is released!

[consideRatio]

Having worked in this code base a while and read all issues, I have a few ideas of improvements still:

• (breaking) change default of use_lookup_dn_username to false, it seem to make sense
  Change use_lookup_dn_username default value to False #280
• tests: declare config instead of configuring an initialized authenticator object
  tests: pass config to constructor instead of configuring after #281
• move various validation logic to traitlets from code to fail during authenticator initialization (jupyterhub startup) instead of during runtime
  Change use_lookup_dn_username default value to False #280
• Investigate Password update from LDAP break authentication #217 further

---

• Is group_attributes really required, even if we don't read about them in the response?
• Is there really a use case for lookup_dn and bind_dn_template? If not we should disallow it to reduce complexity for users and maintainers.
• allow search_filter to consider either resolved_username or login_username