Multi-auth. provider / using separate DBs for usernames and passwords. about maddy HOT 4 CLOSED

Another thing is that users may want to have different storage associated with accounts coming from different auth. backends. Currently, authentication is fully separate from storage and we have the concept of "auth account" and "storage account". This makes it difficult to build some sort of association.

We can allow authentication modules to return some kind of "association tag", which could then be consumed by storage backend.
There are multiple ways to implement such association tags. Depending on the level of abstraction you want them to be on.

SMTP, Pipeline: Allow branching directives to inspect association tag created by authentication provider (using syntax described in #32):

if $authsource = pam {
}

Approach A: Extend authentication provider interface:

type AuthProvider interface {
  CheckPlain(username, password) (associationTag string, err error)
}

Extend storage IMAP interface in similar way:

type StorageBackend interface {
  GetUser(assocationTag, username, password string) (backend.User, error)
}

Then implement multi storage backend and authentication provider capable of making use of these association tags for purposes of dispatching.

from maddy.

Approach B: Move dispatching logic to the upper level.

Do all dispatching at the endpoint (or pipeline) module level, using auth. provider instance names as "association tags".

imap ... {
  auth multi local_users {
      user pam
      pass virtual { file /var/lib/maddy/local-passwd }
  }
  auth multi virtual_users {
      user virtual { file /var/lib/maddy/virtual-users }
      pass virtual { file /var/lib/maddy/virtual-passwd }
  }

  storage {
    auth local_users maildir { root /var/spool/ }
    auth virtual_users sql
  }
}

submission ... {
  auth multi local_users {
      user pam
      pass virtual { file /var/lib/maddy/local-passwd }
  }
  auth multi virtual_users {
      user virtual { file /var/lib/maddy/virtual-users }
      pass virtual { file /var/lib/maddy/virtual-passwd }
  }

  if $auth = virtual_users {
    ...
  } 
}

Side-note: Common auth expressions can be factored out into a snippet:

(auth) {
  auth multi local_users {
      user pam
      pass virtual { file /var/lib/maddy/local-passwd }
  }
  auth multi virtual_users {
      user virtual { file /var/lib/maddy/virtual-users }
      pass virtual { file /var/lib/maddy/virtual-passwd }
  }
}

Or we might want to allow specificing auth directive at top level.

Okay, I think Approach B is more clear and Approach A basically ruins all existing abstractions, while B builds on them.

from maddy.

multi instance_name {
 user pam
 user virtual { file /etc/maddy/userlist }
 pass virtual { file /etc/maddy/passwd }
}

Side note: Not all PAM modules differentiate between "user doesn't exist" and "invalid password" so this setup may be problematic in reality.

from maddy.

  auth multi local_users {
      user pam
      pass virtual { file /var/lib/maddy/local-passwd }
  }
  auth multi virtual_users {
      user virtual { file /var/lib/maddy/virtual-users }
      pass virtual { file /var/lib/maddy/virtual-passwd }
  }

Also this needs extension of config.Map to allow multiple values for directives.

from maddy.