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

[nmaludy]

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"}}]

[Kami]

Thanks for proposing this idea.

From a high level perspective, it seems reasonable, but after some more through I'm a bit skeptical about it.

My main concern is security (aka when not implemented and configured correctly, it would decrease the aggregate security).

If you have two backends, where the second fallback one is potentially less secure, a bad actor could, with that knowledge, force authentication against second, less secure backend (e.g. by DDoSing a primary backend or similar).

I know security is all about layers (there should also be rate limiting in place, second fallback should also use secure credentials, etc.), but I'm still worried that this second backend would give users false sense of security and in reality, it would actually decrease the overall security.

You could also argue that this increases surface area (and in general anything which increases surface / attack area is usually not a good thing) and also makes it less secure because operator now needs to keep credentials in two backends up to date, etc.

I would argue that we should only support a single auth backend and it's up to the user to set up HA for that backend.

If we do decide to implement this at some point, we need to keep this in mind and be very explicit about the potential negative security implications in the documentation.

There were many scenarios in the past where bad actors abused a similar architecture where there were a multiple ways to authenticate with a service (TODO: need to dig out some references).

[nmaludy]

@Kami I understand where you're coming from, however i'm thinking through some other systems that we work with. Every one of them (except StackStorm) have "local accounts" that can be used as fallbacks in case LDAP is broken. These include:

• VMware vSphere
• Citrix
• Red Hat Satellite
• Red Hat Identity Manager (IdM / FreeIPA)
• ServiceNow
• Graylog
• SolarWinds
• etc

This "fallback" feature might also allow users to take advantage of multiple centralized auth providers like "LDAP first, Keystone second, etc".