admin user being associated/updated with OAUTH social auth providers (Azure AD, Github)

[lucas-benedito]

ISSUE TYPE

• Bug Report

SUMMARY

Bug found where if you connect with admin user in rest api and then proceed with Azure AD login in Ansible Tower the admin user in Ansible Tower is updated with Azure AD data after login and the admin user has the tag Social
The user in question would be a non administrative user from Azure AD that after login became the admin user and had full access to tower. This only happened when using Azure AD method but not with SAML method for the same Azure AD.

ENVIRONMENT

• Tested in AWX version: > 3.6.5

STEPS TO REPRODUCE

Fresh install of Ansible Tower 3.6.5 or above.
Configure Azure AD with Azure AD OAUTH2 KEY and Azure AD OAUTH2 SECRET
Login with admin user in Rest API in one tab
Login with the Azure AD in another tab
Check the logged user and user details in Users tab

EXPECTED RESULTS

New user created in tower matching Azure AD settings

ACTUAL RESULTS

Admin user updated with Azure AD user data and login performed as the admin user

ADDITIONAL INFORMATION

Tests performed in different OS versions and Ansible Tower versions 3.6.5 and 3.7.2, both had the same issue.

[ghjm]

I cannot reproduce this. If I log in to the API in one tab, a new tag gives me a dashboard view with the logged in API user. If I then navigate to the login page and perform an Azure AD login, it proceeds normally (whether creating a new Tower social account or reusing an existing one). If I then go back to the API page and click refresh, it shows the newly-logged-in AD user. I was not able to produce the behavior described.

@lucas-benedito can you give more details on how to reproduce this, like down to exact "click on this" steps?

[lucas-benedito]

@ghjm sure, I've tested with Ansible Tower 3.6.5 and 3.7.2

• fresh Ansible Tower Installation
• configure Azure AD with Azure AD OAUTH2 KEY and Azure AD OAUTH2 SECRET ( Azure AD authentication tab ) without any other configuration
• Logout from Ansible Tower
• Open two login tabs being one from https://YOUR-TOWER-ADDRESS/api/login and https://YOUR-TOWER-ADDRESS
• Login with the user admin on https://YOUR-TOWER-ADDRESS/api/login
• swith tabs
• Login with Azure AD on https://YOUR-TOWER-ADDRESS
• Check admin user details

No other steps were required during my tests.

[ghjm]

Ok, I can reproduce this now. The trick is to have both browser tabs open before logging into either one of them.

[jakemcdermott]

Hi. I've opened a PR to fix this issue: #8299

I've confirmed that this bug isn't specific to Azure AD. It's likely reproducible for any oauth provider.

For those testing and verifying this issue, I recommend creating a github application to parametrize your social auth settings. It's simpler than azure so it's a great way to make sure you have the bug reproduction steps exactly right before trying any of the other providers:

• In github, go to settings ->developer settings ->oauth apps

Be aware that once you've changed a local user to a social one via this bug, you shouldn't use it for a subsequent test. Delete all of the user(s) and make new ones.

[unlikelyzero]

@kdelee , let's 👁️ this next week when doing the social auth automation

[unlikelyzero]

@kdelee and @tiagodread are going to take this finish verifying this as a part of the Automation Social Auth work

[kdelee]

1. Have two not logged in browser tabs, one open to api, other open to login page
2. Log in as admin in api
3. Log in as social auth user in UI

In the past:

• social user logs in, sees that they are admin
• admin now labeled as "social" user

Now:

• social user logs in, sees they are themselves
• they are labeled social
• tab that was logged in admin, now when navigate to new page is now the social user
• admin is not marked as social (good)
• log out of API, logs me out of UI too

Note:

• seems like you become the user you last logged in as in all currently open tabs, whereas in the past you were the user your FIRST logged in as in all open tabs

[unlikelyzero]

We will not be adding automated coverage for this if you'd like to close this out @kdelee

[tiagodread]

After a retest like @kdelee post above this bug doesn’t happen anymore, closing this.