Feature Proposal - New Auth Backend - st2-auth-backend-fallback

SUMMARY

I'm proposing implementing a new auth backend called st2-auth-backend-fallback that will allow users to configure fallback auth mechanisms in case primary authentication fails. This capability allows users to still authenticate with StackStorm in case of an outage of the primary authentication mechanism (think LDAP or Keystone).

ISSUE TYPE

• Feature Idea

USECASE

The primary use case i'm trying to solve for is when StackStorm is utilizing a centralized authentication backend such as LDAP or Keystone and that primary service is down you're no longer able to authenticate with StackStorm. In this case, it would be nice to be able to "fall back" to using another auth backend such as flatfile with a local htpasswd file. This way we can still auth with something like st2admin and continue our work, potentially remediating the LDAP server outage.

IMPLEMENTATION THOUGHTS

The st2-auth-backend-fallback would take advantage and utilize existing auth-backends in its implementation. Existing auth-backends would be installed. The "fallback" auth-backend would be configured to create instances of these backends and then invoke them in a defined order. If auth succeeds in one of the backends, then overall auth succeeds. If auth fails on all backends, then overall auth fails.

auth-bakackend KWargs as YAML (set in the config below, but this allows you to see the structure):

backend_kwargs:
  - backend: st2-auth-backend-flat-file
    kwargs:
      file_path: "/path/to/.htpasswd"
  - backend: st2-auth-backend-ldap
    kwargs:
      bind_dn: cn=user,dc=example,dc=com
      bind_pw: bind_password
      group:
        base_dn: ou=groups,dc=example,dc=com
        scope: subtree
        search_filter: (&(cn=st2access)(memberUid={username}))
      ldap_uri: ldap://ldap.example.com
      use_tls: true
      user:
        base_dn: ou=users,dc=example,dc=com
        scope: onelevel
        search_filter: (uid={username})

[auth]
mode = standalone
backend = fallback
backend_kwargs = [{"backend": "st2-auth-backend-flat-file", "kwargs": {"file_path": "/path/to/.htpasswd"}}, {"backend": "st2-auth-backend-ldap", "kwargs": {"use_tls": true, "group": {"scope": "subtree", "search_filter": "(&(cn=st2access)(memberUid={username}))", "base_dn": "ou=groups,dc=example,dc=com"}, "user": {"scope": "onelevel", "search_filter": "(uid={username})", "base_dn": "ou=users,dc=example,dc=com"}, "bind_pw": "bind_password", "ldap_uri": "ldap://ldap.example.com", "bind_dn": "cn=user,dc=example,dc=com"}}]

Start by locating the existing auth-backends and the configuration handling they use. Compare their interfaces with the proposed backend_kwargs YAML and INI examples, then define how ordered authentication should behave. Done means the fallback backend can try configured backends in order, succeeding when any succeeds and failing when all fail.