You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[AAP-48066] Allow login from multiple active authenticators (#774)
## Description
This PR is based off of the following
[PoC](#751).
[Jira](https://issues.redhat.com/browse/AAP-48066)
- What is being changed? This PR allows for multiple authenticators to
match to a given AAP user, based on the email as the unifying key. When
attempting to sign in via any authenticator with email -
`[email protected]`, we will sign you into the AAP user associated with
that email, provided only 1 AAP user exists with that email address.
- Why is this change needed? This change is needed to standardize our
users, and provide clear expectations about how users are signed in.
With this change, we will no longer have unique users for each
authenticator, and will instead be able to link multiple authenticators
to a given AAP user.
- How does this change address the issue?
This change addresses the issue by adjusting the logic used to match
users to usernames as described in the
[proposal](https://handbook.eng.ansible.com/proposals/0082-Handling-Sign-In-Via-Multiple-Authenticators).
Note -
This change allows users to log into existing AAP accounts if one
associated with their email exists. However in this flow -
1. Local AAP account created
2. Sign in via LDAP
The user will sign in successfully, but due to how django-auth-ldap
works, it will automatically unset the users local password preventing
them from then signing in via the local password. We may be able to
circumvent this. In my testing so far I have not yet been able too, but
upon thinking about it further, it may be best to avoid circumventing
it, to avoid messing with how django-auth-ldap handles its security.
## Type of Change
<!-- Mandatory: Check one or more boxes that apply -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] Documentation update
- [x] Test update
- [ ] Refactoring (no functional changes)
- [ ] Development environment change
- [ ] Configuration change
## Self-Review Checklist
<!-- These items help ensure quality - they complement our automated CI
checks -->
- [ ] I have performed a self-review of my code
- [ ] I have added relevant comments to complex code sections
- [ ] I have updated documentation where needed
- [ ] I have considered the security impact of these changes
- [ ] I have considered performance implications
- [ ] I have thought about error handling and edge cases
- [ ] I have tested the changes in my local environment
## Testing Instructions
<!-- Optional for test-only changes. Mandatory for all other changes -->
<!-- Must be detailed enough for reviewers to reproduce -->
### Prerequisites
<!-- List any specific setup required -->
### Steps to Test (using aap-dev)
1. `make configure-sources`, use this DAB PR
4. `make aap`
5. Configure multiple authenticators such as LDAP, GitHub, SAML, etc in
your AAP environment
6. (Optional) Create a local user, with same email address another
authenticator users, and sign in as local user. Sign in succeeds
7. Check the /api/gateway/v1/users/<ID> endpoint, we should see
associated_authenticators updated with this authenticator reference
8. Sign in via another authenticator (such as github), you should be
signed into the same AAP Account, and now associated_authenticators
should have multiple entries.
9. (Optional) Keep signing in with other authenticators, you should
continue to sign into the same AAP account as long as the same email
address is provided by authenticator
Next test -
1. Create a new local user, without an email
2. Sign in via local, see the user is created and linked to local
authenticator
3. Sign in via authenticator, a new AAP user should be created (Since no
email was available to match on)
4. Sign in via another authenticator (which provides email). We should
link to the AAP account created by the step 3 authenticator.
### Expected Results
User can sign into AAP using any authenticator, and expect to sign into
their existing AAP account, so long as it is associated with a matching
email.
## Additional Context
<!-- Optional but helpful information -->
### Required Actions
<!-- Check if changes require work in other areas -->
<!-- Remove section if no external actions needed -->
- [ ] Requires documentation updates
<!-- API docs, feature docs, deployment guides -->
- [ ] Requires downstream repository changes
<!-- Specify repos: django-ansible-base, eda-server, etc. -->
- [ ] Requires infrastructure/deployment changes
<!-- CI/CD, installer updates, new services -->
- [ ] Requires coordination with other teams
<!-- UI team, platform services, infrastructure -->
- [ ] Blocked by PR/MR: #XXX
<!-- Reference blocking PRs/MRs with brief context -->
### Screenshots/Logs
<!-- Add if relevant to demonstrate the changes -->
0 commit comments