[MXS-1605] PamAuth - Option to Failback to Default Authentication Created: 2018-01-12 Updated: 2022-06-05 Resolved: 2019-12-10 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Authenticator |
| Affects Version/s: | None |
| Fix Version/s: | Icebox |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Matt Mencel | Assignee: | Esa Korhonen |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Epic Link: | Security Improvements | ||||||||
| Sprint: | MXS-SPRINT-94, MXS-SPRINT-95, MXS-SPRINT-96 | ||||||||
| Description |
|
When using PamAuth with MaxScale, it would be nice to have the option to failback to try default authentication if no PAM user is found. A MariaDB system may have a mix of pam authenticated and DB authenticated accounts. My current workaround is to setup a second Listener on another port with a duplicated list of backends that don't use PamAuth. |
| Comments |
| Comment by Esa Korhonen [ 2019-11-12 ] |
|
What does failback mean here exactly? If the client "bob@host1" connects and a matching entry (e.g. "bob@host%") is selected but the associated plugin is not loaded, should the server really start attempting other plugins? According to https://mariadb.com/kb/en/library/create-user/ the server selects the most matching entry and that's it. As for a listener/service supporting multiple authentication plugins, that is under development. |
| Comment by Esa Korhonen [ 2019-12-10 ] |
|
Closing for now. May reopen if issue clarified. |