Why am I losing System Administrator or System Auditor rights when logging in with single sign on?

Solution Verified - Updated -

Environment

  • Ansible Automation Platform 2.2
  • Ansible Automation Platform 2.3

Issue

  • After upgrading or installing Ansible Automation Platform 2.2 or 2.3 users with System Administrator or System Auditor rights are having them revoked upon logging in using SSO.

Resolution

There are 2 resolutions, see below.

  1. Negate the new feature and not have flags removed

    • Update the SAML User Flags Attribute Mapping within Automation Controller to {"remove_superusers": "False"}
      (For System Auditors use "remove_system_auditors")
  2. Have the provider transmit a field that identifies System Admin/Auditor

  • Update the SAML User Flags Attribute Mapping within Automation Controller to have one or more of the properties:

    {
    "is_superuser_attr": "blueGroups",
    "is_superuser_role": "is_superuser",
    "is_superuser_value": "cn=My-Sys-Admins,ou=memberlist,ou=mygroups,o=myco.com",
    "is_system_auditor_attr": "blueGroups",
    "is_system_auditor_role": "is_system_auditor",
    "is_system_auditor_value": "cn=My-Auditors,ou=memberlist,ou=mygroups,o=myco.com"
    }
    

    For example, using Okta as a provider:

    1. Update the userType attribute in the user's profile to is_superuser. Note: This can be any attribute field, I just chose usertype.
    2. Update the SAML User Flags Attribute Mapping to {"is_superuser_attr": "userType"}
    3. Upon logging in the user will be granted superuser or System Administrator privileges

Ref: GitHub

Root Cause

  • New feature added in AAP 2.2 that allows users to be given System Administrator or System Auditor rights upon login.

Diagnostic Steps

  1. Enable Debugging within Automation Controller:
    • Settings
    • Logging Settings
    • Logging Aggregator Level Threshold > Debug
  2. Using SSO, login to an account with System Administrator privileges.
  3. Verify results in /var/log/tower/tower.log

    Before

    2022-06-15 23:44:42,538 DEBUG    [84a5c8db2c89440e9d2b66817794c918] awx.sso.pipeline User attributes for john.doe@redhat.com: {'FirstName': ['John'], 'LastName': ['Doe'], 'Email': ['john.doe@redhat.com'], 'UserName': ['john.doe@redhat.com'], 'name_id': 'john.doe@redhat.com'}
    2022-06-15 23:44:42,539 DEBUG    [84a5c8db2c89440e9d2b66817794c918] awx.sso.pipeline Revoking superuser from john.doe@redhat.com
    

    After

    2022-06-16 00:07:42,814 DEBUG    [95f92af2a0ff439796e6ab67db1a3f38] awx.sso.pipeline User attributes for john.doe@redhat.com: {'FirstName': ['John'], 'LastName': ['Doe'], 'Email': ['john.doe@redhat.com'], 'UserName': ['john.doe@redhat.com'], 'userType': ['is_superuser'], 'name_id': 'john.doe@redhat.com'}
    2022-06-16 00:07:42,815 DEBUG    [95f92af2a0ff439796e6ab67db1a3f38] awx.sso.pipeline Giving john.doe@redhat.com superuser from attribute userType
    

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

1 Comments

The example json doesn;t work. Because several fields accept "one or more values" they have to be passed differently. This is what worked for me.

{ "is_superuser_role": ["awx_admins"], "is_superuser_attr": "is_superuser", "is_superuser_value": ["IT-Superadmin"], "is_system_auditor_role": ["awx_auditors"], "is_system_auditor_attr": "is_system_auditor", "is_system_auditor_value": ["Auditor"] }