auth_proxy should have a "bail on fail" option

[Jeff Davis]

When auth_proxy is enabled, EG will try each configured authenticator in turn. If the first one fails, it will try the next, and so on. In a typical setup, this means EG will attempt LDAP auth first, then fall-through to native auth if LDAP fails.

But this fall-through isn't always desirable. Let's say you're in a consortium where only one library is using LDAP, and that library doesn't want to support native login. To make this work currently, your "native" authenticator config in opensrf.xml would need to individually list every library in your consortium *except* for the one that's using LDAP. That's cumbersome and error-prone.

Instead, I propose adding a "bail on fail" setting to authenticator config. When enabled, if auth fails for that authenticator, auth_proxy will bail out instead of falling through to the next authenticator.

[Jeff Davis (jdavis-sitka)]

Working branch user/jeffdavis/lp1815229_auth_proxy_bail_on_fail implements this proposal:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1815229_auth_proxy_bail_on_fail

[Dan Wells (dbw2)]

Hello Jeff,

Thanks for your work on both this bug and bug #1715396. I think both solutions do the intended jobs, but as you mention on the other bug, it is starting to feel a little murky with the various add-ons.

Now, feel free to accuse me of over-engineering, but after puzzling over this a while, I'd like to propose the following. What if, between <authenticators> and <authenticator>, we allowed an optional <group> container. This group could specify *required* login_types and/or org_units, would contain one or more authenticators, and would *not* fall through (that is, you get the first matching group only). Something like:
<group>
  <!-- the following login_types and org_units are required for this group -->
  <login_types>
    <type>opac</type>
  </login_types>
  <org_units>
    <unit>5</unit>
  </org_units>
  <authenticator>
    <name>ldap</name>
    ...
  </authenticator>
  <!-- possibly more authenticators here -->
</group>

This would give the following additional benefits:
 - One mechanism for both fall-through avoidance and failure/credential-sharing protection
 - The possibility to apply these mechanisms to org_unit limits *and* login_type limits
 - The possibility for partial/controlled fall-through (i.e. one org_unit with two or more authenticators together with a second org_unit with two or more different authenticators)

In short, it would give a great deal of flexibility, maybe all we would ever need, and feel somewhat more natural to boot (in my opinion). If you agree it is worth trying, I can get a branch posted for your review very quickly.

Dan

[Terran McCanna (tmccanna)]

Adding needsdiscussion tag as per comment 2