Hi, I'm kind of jumping into this discussion on authentication handlers here, even though it's not (or only halfway) related to the initial question.
I initially contributed the patch to make Authentication handlers pluggable again for one single reason: To use the custom couch_jwt_auth handler (*). While everything works fine and smooth for me now, I'd like to take this a step further and check if there's a possibility to include this auth handler at some point in the official distribution. A couple of things motivate me: - It's useful when authentication is already handled by a dedicated service, which seems to be more and more often the case in modern architectures - There's already been a couple of SO questions asking for this kind of use case - It's security related, so I'd like to see it double and triple checked by other eyes - especially since my Erlang is still pretty fresh - It's security related, so including it in the official distribution raises trust - The version I'm currently maintaining(*) is a fork of an existing implementation. I opened a pull request a while back (**) with no reaction. Well, that's it for the moment :) -Daniel (*): https://github.com/dmunch/couch_jwt_auth/ (**): https://github.com/softapalvelin/couch_jwt_auth/pull/4 On Thu, Nov 17, 2016 at 10:36 PM, Robert Samuel Newson <[email protected]> wrote: > Hi Tim, > > Authentication handlers are pluggable once again, and that feature will > appear in our next release (tentatively designated 2.1.0). > > We'd definitely merge a patch that added an authentication handler where the > DN was used to look up a user in the normal CouchDB _users database. > > when we bring LDAP in, things get trickier. I'm sure we'd take a patch to add > an LDAP authentication handler, but there's no precedent for handlers > co-operating with other handlers (LDAP plus client cert). If you're prepared > to do the work, I'm sure this could be figured out, I'm just saying the > authentication system doesn't already support the notion, and we wouldn't > want to make this part of couchdb much fiddlier. > > B. > >> On 17 Nov 2016, at 14:36, Timothy McKernan <[email protected]> wrote: >> >> Has there been any interest in adding support for two-way SSL >> authentication? More specifically, I'm looking for a way to: >> >> - Verify a client's cert is valid, >> - Check the cert's Certificate Authority(s) against a local store, >> - Query a remote service to verify the cert hasn't been revoked >> (CRL's), >> - Use the client's Distinguished Name to query a remote service (LDAP >> would be fine) to verify the user is authorized to connect, >> - Use the client's Distinguished Name to authenticate the user in >> CouchDb, returning the user ctx. >> >> I've looked at how to add an auth handler in 2.0.0 and read some older >> posts about it. It looks like at least src/chttpd/src/chttpd_auth.erl and >> src/couch/src/couch_httpd_auth.erl need to be edited to use any new >> handlers, is that right? >> >> I think my questions come down to: >> >> - Is there going to be support for two-way SSL auth? >> - If not, is the authentication handler code going to be updated to >> allow new handlers to be plugged in (having the handlers implement a known >> interface) rather than hand-edit the above code? >> - I my requirements also suggest allowing a chain of handlers to be >> called, so that the details of CouchDb auth vs. CRL verification vs. LDAP >> can all be called one after the other, only going to the next handler if >> the previous handler succeeded. >> >> Right now I'm just trying to understand the scope of what's required to add >> this, especially if it seems I'd be the one doing it. >> >> -Tim >
