Proposed IdP category starting with LDAP module - MVP for discussion #9225
Conversation
Minimal viable product - can successfully connect to LDAP server as both anonymous user and authenticated admin user. This also includes java classes corresponding to several standard LDAP schemas. These classes do not contain the Active Directory or Kerberos schemas.
|
Hi @beargiles, thanks for the PR.
For discussion we have GitHub Discussions. Ideal workflow is to submit a discussion, triage it and then submit a PR. It is not necessary to raise an issue and then a PR right away. We value the time you spend on working on this, so, next time consider discussing it before to start working on it.
Regarding to spring security, I know there was Apache Directory in the past and nowadays it supports UnboundID. I even contributed to some on those features but there is no usage of testcontainers on it. Just FYI, there is a minimal implementation of OpenLdapContainer in spring boot in order to add The PR would bring another responsibility to Testcontainers. Testcontainers responsibility is about container initialization. There should be other libraries for LDAP clients such as spring ldap or spring security with ldap support. |
There was a problem hiding this comment.
A KDC module can be used to test code that requires Kerberos authentication. This is heavily used in the Hadoop ecosystem.
- Although distributions like Ubuntu encourage the use of Kerberos KDC as a system dependency ( https://ubuntu.com/server/docs/how-to-install-a-kerberos-server ), in practice in the Java community, most people start a Kerberos KDC through https://directory.apache.org/kerby/. Projects that use Apache Kerby to start a Kerberos KDC include but are not limited to Hadoop, HBase, Hive, and Spring Security.
- This brings up another question: should we first let the apache kerby community provide a Dockerfile to start Kerberos KDC, or let the apache kerby community distribute a Docker Image through downstream channels such as Docker Hub? Due to the LICENSE issues involved in Docker Image, Docker Image will not be distributed through the official channels of ASF.
|
I don't think you can make that assumption at all. The Cloudera installer, at least before they somehow put everything behind a paywall, allowed you to specify Active Directory (iirc), MIT KDC, and IPA/FreeIPA. The last one wasn't supported until relatively late. I don't think the installer ever listed Kerby as a standalone alone service, much less as the system's KDC. But that's been several years, and of course now they've been cloud-only for several years. That's a very different environment from the on-prem we focused on. I have no doubt that all of the systems provide a vanilla KDC. I remember a lot of the issues we had were around user impersonation and that might have just been due to some ambiguous documentation and error messages. However I know that the KDC has been extended - with PKINIT and I thought there was also some type of tokens as well (but not keytabs). (What bit me was that I was retrofitting code and accidentally added user impersonation twice - and it took me far too long to realize that I should write a low-level dump of what I was passing to the cluster. I would not be surprised to learn that some libraries only look one level deep while other libraries follow user authentication recursively until they find an actual user.) |
THIS IS ONLY FOR DISCUSSION
(although it is a minimal viable product that you can run yourself. But see below...)
I see a significant gap in the available modules - there is little to no support for IdP servers. Many of these services, or at least their components, are available as docker images.
Having IdP modules would serve two purposes:
To me the natural place to start is Active Directory - or the Linux alternative of FreeIPA. I know there were limitations on running the FreeIPA in a docker container in the past but they may have been solved by now, or at least they may not prevent its use in a future TestContainer.
In the meanwhile we can start with the components:
I've started with LDAP since I know it can be directly used by Spring Security : LDAP. The documentation refers to embedded LDAP servers but there are benefits to using TestContainers, to say nothing of the fact that many applications do not use Spring Security.
(As an aside - I think a lot of problems would go away if sites moved their username/password authentication into LDAP for the simple reason that composing the database will not compromise the passwords. Double the benefits if you use the standard 'inetOrgPerson' fields to store the PII outside of the standard database. In a system with proper encapsulation this could be a transparent change... and why I'm planning on writing some articles on how to do it!)
A DNS module can be used to test code that performs service discovery via DNS SRV records. Microsoft Active Directory relies on it, and it's a very powerful tool in environments that run their own DNS servers... or are willing to make this information available on the publicly visible DNS servers.
A KDC module can be used to test code that requires Kerberos authentication. This is heavily used in the Hadoop ecosystem.
Finally the CA/PKI mdule can be used to test code that requires encryption keys and digital certificates. In fact it might be the most heavily used module among all of these since it could be used to create a set of related keys required by many other modules.
Once these are in place it would be easy to add support for OAuth and JWT. They're a bit trickie since the standard isn't locked down so there would need to be different implementations to mimic the major providers. However, again, this would be a way to support testing authentication code that doesn't seem to be available now.
A small nit
I needed to make a small change for the code to build. I might be able to revert it now, or help finding the cause of the problems.
gradle/spotless.gradle: I had to comment outremoveUnusedImports()in classes using lombok.Data