Quick-and-dirty support for GSSAPI authentication

[syskill]

Tested and confirmed working for me with 389 Directory Server (FreeIPA).

As noted in the comments, integrity and confidentiality protection are not implemented. AFAICT that would entail keeping the GSSAPI::Simple object and using its #wrap_message and #unwrap_message methods on incoming and outgoing traffic, with the encryption flag set as appropriate for the SSF. The output size limit would also have to be respected.

(No unit test added, because that would also add a dependency on the GSSAPI gem.)

[jch]

@syskill thanks for the PR, but I can't merge this if it has an external dependency that isn't added to the gemspec. I'm not familiar with gssapi, so I'm not a good person to review this and determine if it's something we want in the core library.

[syskill]

@jch GSSAPI authentication (which is usually synonymous with Kerberos authentication) is commonly used in FreeIPA and similar identity management systems that combine LDAP and Kerberos. It is less commonly used in academia or other old installations that keep running on the memory of a long-expired Sun support contract.

There is a dependency on the GSSAPI gem only if one uses GSSAPI authentication; otherwise, everything works fine without it. In that respect it's like the existing method for GSS-SPNEGO authentication — although I can understand not wanting to merge a second ugly hack alongside the first.

Still, I think this should be merged for one important reason: based on what I found while researching how to implement this, it seems that a lot of people have tried to do it before, and AFAICT most (maybe all) of them finally gave up in frustration. That one line of code for SSF negotiation took me several days to get right. Having this implementation in the ruby-ldap distribution, even though it may surprise the user with a hidden dependency, even though it could fail on some hardened LDAP servers, will be a great help for other users in Kerberized environments. IMO it is also a good starting point for future hacking.

[jch]

In that respect it's like the existing method for GSS-SPNEGO authentication — although I can understand not wanting to merge a second ugly hack alongside the first.

Thanks for this context. That was before my time as a maintainer.

Looking over the existing implementation for #bind, this would be a good candidate to refactor with the adaptor pattern. Each bind implementation could be it's own adaptor. Are GSS-SPNEGO and GSSAPI extensions to the LDAP spec? I'd like to see more research about what parts are specified by the LDAP spec, and what is specified by other specs.

[syskill]

Are GSS-SPNEGO and GSSAPI extensions to the LDAP spec? I'd like to see more research about what parts are specified by the LDAP spec, and what is specified by other specs.

It's slightly more complicated than that. SASL authentication is part of the LDAP spec. SASL is a generic authentication protocol that allows the use of several different authentication methods, including GSSAPI and GSS-SPNEGO. GSSAPI is a generic authentication API (in the old sense — think C, not HTTP) that could wrap any number of authentication libraries, but in practice is only used with Kerberos. GSS-SPNEGO is only used to authenticate to Active Directory; Microsoft hacked it up in the '90s so that AD would have as little compatibility as possible with anything in the Unix LDAP and Kerberos ecosystems. There is an RFC for it now, at least.

I agree that the adapter pattern should be a good fit here. Let me see what I can work up.

[jch]

@syskill great explanation 👍

[eheydrick]

It would be great to have full GSSAPI support. What would it take to get this merged?

[jch]

@eheydrick a PR refactoring #bind with an adapter pattern, and moving this implementation to a separate gem.