mirror of
https://github.com/ansible/awx.git
synced 2026-02-16 18:50:04 -03:30
3rd party auth removal cleanup
- Sequentiallize auth config removal migrations - Remove references to third party auth - update license files - lint fix - Remove unneeded docs - Remove unreferenced file - Remove social auth references from docs - Remove rest of sso dir - Remove references to third part auth in docs - Removed screenshots of UI listing removed settings - Remove AuthView references - Remove unused imports ... Co-Authored-By: jessicamack <21223244+jessicamack@users.noreply.github.com>
This commit is contained in:
Hao Liu
jessicamack
@@ -146,7 +146,7 @@ Use this command to clear tokens which have already been revoked. Refer to `Djan
|
||||
``expire_sessions``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Use this command to terminate all sessions or all sessions for a specific user. Consider using this command when a user changes role in an organization, is removed from assorted groups in LDAP/AD, or the administrator wants to ensure the user can no longer execute jobs due to membership in these groups.
|
||||
Use this command to terminate all sessions or all sessions for a specific user. Consider using this command when a user changes role in an organization, is removed from assorted groups in AD, or the administrator wants to ensure the user can no longer execute jobs due to membership in these groups.
|
||||
|
||||
::
|
||||
|
||||
|
||||
@@ -10,24 +10,10 @@ AWX Configuration
|
||||
|
||||
You can configure various AWX settings within the Settings screen in the following tabs:
|
||||
|
||||
.. image:: ../common/images/ug-settings-menu-screen.png
|
||||
:alt: Screenshot of the AWX settings menu screen.
|
||||
|
||||
Each tab contains fields with a **Reset** button, allowing you to revert any value entered back to the default value. **Reset All** allows you to revert all the values to their factory default values.
|
||||
|
||||
**Save** applies changes you make, but it does not exit the edit dialog. To return to the Settings screen, click **Settings** from the left navigation bar or use the breadcrumbs at the top of the current view.
|
||||
|
||||
|
||||
Authentication
|
||||
=================
|
||||
.. index::
|
||||
single: social authentication
|
||||
single: authentication
|
||||
pair: configuration; authentication
|
||||
|
||||
.. include:: ./configure_awx_authentication.rst
|
||||
|
||||
|
||||
.. _configure_awx_jobs:
|
||||
|
||||
Jobs
|
||||
@@ -66,7 +52,7 @@ The System tab allows you to define the base URL for the AWX host, configure ale
|
||||
2. The right side of the Settings window is a set of configurable System settings. Select from the following options:
|
||||
|
||||
- **Miscellaneous System settings**: enable activity streams, specify the default execution environment, define the base URL for the AWX host, enable AWX administration alerts, set user visibility, define analytics, specify usernames and passwords, and configure proxies.
|
||||
- **Miscellaneous Authentication settings**: configure options associated with authentication methods (built-in or SSO), sessions (timeout, number of sessions logged in, tokens), and social authentication mapping.
|
||||
- **Miscellaneous Authentication settings**: configure options associated with authentication methods and sessions (timeout, number of sessions logged in, tokens).
|
||||
- **Logging settings**: configure logging options based on the type you choose:
|
||||
|
||||
.. image:: ../common/images/configure-awx-system-logging-types.png
|
||||
|
||||
@@ -1,7 +0,0 @@
|
||||
1. From the left navigation bar, click **Settings**.
|
||||
|
||||
2. The left side of the Settings window is a set of configurable Authentication settings. Select from the following options:
|
||||
|
||||
Different authentication types require you to enter different information. Be sure to include all the information as required.
|
||||
|
||||
3. Click **Save** to apply the settings or **Cancel** to abandon the changes.
|
||||
@@ -1,19 +0,0 @@
|
||||
.. _ag_ent_auth:
|
||||
|
||||
Setting up Enterprise Authentication
|
||||
==================================================
|
||||
|
||||
|
||||
.. index::
|
||||
single: enterprise authentication
|
||||
single: authentication
|
||||
|
||||
This section describes setting up authentication for the following enterprise systems:
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
- Enterprise users can only be created via the first successful login attempt from remote authentication backend.
|
||||
- Enterprise users cannot be created/authenticated if non-enterprise users with the same name has already been created in AWX.
|
||||
- AWX passwords of enterprise users should always be empty and cannot be set by any user if there are enterprise backend-enabled.
|
||||
- If enterprise backends are disabled, an enterprise user can be converted to a normal AWX user by setting the password field. However, this operation is irreversible, as the converted AWX user can no longer be treated as enterprise user.
|
||||
@@ -39,10 +39,7 @@ Need help or want to discuss AWX including the documentation? See the :ref:`Comm
|
||||
configure_awx
|
||||
isolation_variables
|
||||
oauth2_token_auth
|
||||
social_auth
|
||||
ent_auth
|
||||
authentication_timeout
|
||||
kerberos_auth
|
||||
session_limits
|
||||
custom_rebranding
|
||||
troubleshooting
|
||||
|
||||
@@ -1,117 +0,0 @@
|
||||
User Authentication with Kerberos
|
||||
==================================
|
||||
|
||||
.. index::
|
||||
pair: user authentication; Kerberos
|
||||
pair: Kerberos; Active Directory (AD)
|
||||
|
||||
User authentication via Active Directory (AD), also referred to as authentication through Kerberos, is supported through AWX.
|
||||
|
||||
To get started, first set up the Kerberos packages in AWX so that you can successfully generate a Kerberos ticket. To install the packages, use the following steps:
|
||||
|
||||
::
|
||||
|
||||
yum install krb5-workstation
|
||||
yum install krb5-devel
|
||||
yum install krb5-libs
|
||||
|
||||
Once installed, edit the ``/etc/krb5.conf`` file, as follows, to provide the address of the AD, the domain, etc.:
|
||||
|
||||
::
|
||||
|
||||
[logging]
|
||||
default = FILE:/var/log/krb5libs.log
|
||||
kdc = FILE:/var/log/krb5kdc.log
|
||||
admin_server = FILE:/var/log/kadmind.log
|
||||
|
||||
[libdefaults]
|
||||
default_realm = WEBSITE.COM
|
||||
dns_lookup_realm = false
|
||||
dns_lookup_kdc = false
|
||||
ticket_lifetime = 24h
|
||||
renew_lifetime = 7d
|
||||
forwardable = true
|
||||
|
||||
[realms]
|
||||
WEBSITE.COM = {
|
||||
kdc = WIN-SA2TXZOTVMV.website.com
|
||||
admin_server = WIN-SA2TXZOTVMV.website.com
|
||||
}
|
||||
|
||||
[domain_realm]
|
||||
.website.com = WEBSITE.COM
|
||||
website.com = WEBSITE.COM
|
||||
|
||||
After the configuration file has been updated, you should be able to successfully authenticate and get a valid token.
|
||||
The following steps show how to authenticate and get a token:
|
||||
|
||||
::
|
||||
|
||||
[root@ip-172-31-26-180 ~]# kinit username
|
||||
Password for username@WEBSITE.COM:
|
||||
[root@ip-172-31-26-180 ~]#
|
||||
|
||||
Check if we got a valid ticket.
|
||||
|
||||
[root@ip-172-31-26-180 ~]# klist
|
||||
Ticket cache: FILE:/tmp/krb5cc_0
|
||||
Default principal: username@WEBSITE.COM
|
||||
|
||||
Valid starting Expires Service principal
|
||||
01/25/16 11:42:56 01/25/16 21:42:53 krbtgt/WEBSITE.COM@WEBSITE.COM
|
||||
renew until 02/01/16 11:42:56
|
||||
[root@ip-172-31-26-180 ~]#
|
||||
|
||||
Once you have a valid ticket, you can check to ensure that everything is working as expected from command line. To test this, make sure that your inventory looks like the following:
|
||||
|
||||
::
|
||||
|
||||
[windows]
|
||||
win01.WEBSITE.COM
|
||||
|
||||
[windows:vars]
|
||||
ansible_user = username@WEBSITE.COM
|
||||
ansible_connection = winrm
|
||||
ansible_port = 5986
|
||||
|
||||
You should also:
|
||||
|
||||
- Ensure that the hostname is the proper client hostname matching the entry in AD and is not the IP address.
|
||||
|
||||
- In the username declaration, ensure that the domain name (the text after ``@``) is properly entered with regard to upper- and lower-case letters, as Kerberos is case sensitive. For AWX, you should also ensure that the inventory looks the same.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
If you encounter a ``Server not found in Kerberos database`` error message, and your inventory is configured using FQDNs (**not IP addresses**), ensure that the service principal name is not missing or mis-configured.
|
||||
|
||||
|
||||
Now, running a playbook should run as expected. You can test this by running the playbook as the ``awx`` user.
|
||||
|
||||
Once you have verified that playbooks work properly, integration with AWX is easy. Generate the Kerberos ticket as the ``awx`` user and AWX should automatically pick up the generated ticket for authentication.
|
||||
|
||||
.. note::
|
||||
|
||||
The python ``kerberos`` package must be installed. Ansible is designed to check if ``kerberos`` package is installed and, if so, it uses kerberos authentication.
|
||||
|
||||
|
||||
AD and Kerberos Credentials
|
||||
------------------------------
|
||||
|
||||
Active Directory only:
|
||||
|
||||
- If you are only planning to run playbooks against Windows machines with AD usernames and passwords as machine credentials, you can use "user@<domain>" format for the username and an associated password.
|
||||
|
||||
With Kerberos:
|
||||
|
||||
- If Kerberos is installed, you can create a machine credential with the username and password, using the "user@<domain>" format for the username.
|
||||
|
||||
|
||||
Working with Kerberos Tickets
|
||||
-------------------------------
|
||||
|
||||
Ansible defaults to automatically managing Kerberos tickets when both the username and password are specified in the machine credential for a host that is configured for kerberos. A new ticket is created in a temporary credential cache for each host, before each task executes (to minimize the chance of ticket expiration). The temporary credential caches are deleted after each task, and will not interfere with the default credential cache.
|
||||
|
||||
To disable automatic ticket management (e.g., to use an existing SSO ticket or call ``kinit`` manually to populate the default credential cache), set ``ansible_winrm_kinit_mode=manual`` via the inventory.
|
||||
|
||||
Automatic ticket management requires a standard kinit binary on the control host system path. To specify a different location or binary name, set the ``ansible_winrm_kinit_cmd`` inventory variable to the fully-qualified path to an MIT krbv5 kinit-compatible binary.
|
||||
@@ -449,11 +449,6 @@ Revoking an access token by this method is the same as deleting the token resour
|
||||
The special OAuth 2 endpoints only support using the ``x-www-form-urlencoded`` **Content-type**, so as a result, none of the ``api/o/*`` endpoints accept ``application/json``.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
The **Allow External Users to Create Oauth2 Tokens** (``ALLOW_OAUTH2_FOR_EXTERNAL_USERS`` in the API) setting is disabled by default. External users refer to users authenticated externally with services like SSO services. This setting ensures external users cannot *create* their own tokens. If you enable then disable it, any tokens created by external users in the meantime will still exist, and are not automatically revoked.
|
||||
|
||||
|
||||
Alternatively, you can use the ``manage`` utility, :ref:`ag_manage_utility_revoke_tokens`, to revoke tokens as described in the :ref:`ag_token_utility` section.
|
||||
|
||||
|
||||
|
||||
@@ -79,12 +79,6 @@ Existing security functionality
|
||||
Do not disable SELinux, and do not disable AWX’s existing multi-tenant containment. Use AWX’s role-based access control (RBAC) to delegate the minimum level of privileges required to run automation. Use Teams in AWX to assign permissions to groups of users rather than to users individually. See :ref:`rbac-ug` in the |atu|.
|
||||
|
||||
|
||||
External account stores
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Maintaining a full set of users just in AWX can be a time-consuming task in a large organization, prone to error. AWX supports connecting to external account sources via certain :ref:`OAuth providers <ag_social_auth>`. Using this eliminates a source of error when working with permissions.
|
||||
|
||||
|
||||
.. _ag_security_django_password:
|
||||
|
||||
Django password policies
|
||||
|
||||
@@ -1,118 +0,0 @@
|
||||
.. _ag_social_auth:
|
||||
|
||||
Setting up Social Authentication
|
||||
==================================
|
||||
|
||||
.. index::
|
||||
single: social authentication
|
||||
single: authentication
|
||||
|
||||
Authentication methods help simplify logins for end users--offering single sign-ons using existing login information to sign into a third party website rather than creating a new login account specifically for that website.
|
||||
|
||||
Account authentication can be configured in the AWX User Interface and saved to the PostgreSQL database. For instructions, refer to the :ref:`ag_configure_awx` section.
|
||||
|
||||
.. _ag_org_team_maps:
|
||||
|
||||
Organization and Team Mapping
|
||||
---------------------------------
|
||||
|
||||
.. index::
|
||||
single: organization mapping
|
||||
pair: authentication; organization mapping
|
||||
pair: authentication; team mapping
|
||||
single: team mapping
|
||||
|
||||
Organization mapping
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You will need to control which users are placed into which organizations based on their username and email address (mapping out your organization admins/users from social or enterprise-level authentication accounts).
|
||||
|
||||
Dictionary keys are organization names. Organizations will be created, if not already present and if the license allows for multiple organizations. Otherwise, the single default organization is used regardless of the key.
|
||||
|
||||
Values are dictionaries defining the options for each organization's membership. For each organization, it is possible to specify which users are automatically users of the organization and also which users can administer the organization.
|
||||
|
||||
**admins**: None, True/False, string or list/tuple of strings.
|
||||
|
||||
- If **None**, organization admins will not be updated.
|
||||
- If **True**, all users using account authentication will automatically be added as admins of the organization.
|
||||
- If **False**, no account authentication users will be automatically added as admins of the organization.
|
||||
- If a string or list of strings, specifies the usernames and emails for users who will be added to the organization. Strings beginning and ending with ``/`` will be compiled into regular expressions; modifiers ``i`` (case-insensitive) and ``m`` (multi-line) may be specified after the ending ``/``.
|
||||
|
||||
**remove_admins**: True/False. Defaults to **True**.
|
||||
|
||||
- When **True**, a user who does not match is removed from the organization's administrative list.
|
||||
|
||||
**users**: None, True/False, string or list/tuple of strings. Same rules apply as for **admins**.
|
||||
|
||||
**remove_users**: True/False. Defaults to **True**. Same rules apply as for **remove_admins**.
|
||||
|
||||
|
||||
::
|
||||
|
||||
{
|
||||
"Default": {
|
||||
"users": true
|
||||
},
|
||||
"Test Org": {
|
||||
"admins": ["admin@example.com"],
|
||||
"users": true
|
||||
},
|
||||
"Test Org 2": {
|
||||
"admins": ["admin@example.com", "/^awx-[^@]+?@.*$/i"],
|
||||
"users": "/^[^@].*?@example\\.com$/"
|
||||
}
|
||||
}
|
||||
|
||||
Organization mappings may be specified separately for each account authentication backend. If defined, these configurations will take precedence over the global configuration above.
|
||||
|
||||
::
|
||||
|
||||
Team mapping
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Team mapping is the mapping of team members (users) from social auth accounts. Keys are team names (will be created if not present). Values are dictionaries of options for each team's membership, where each can contain the following parameters:
|
||||
|
||||
**organization**: string. The name of the organization to which the team
|
||||
belongs. The team will be created if the combination of organization and
|
||||
team name does not exist. The organization will first be created if it
|
||||
does not exist. If the license does not allow for multiple organizations,
|
||||
the team will always be assigned to the single default organization.
|
||||
|
||||
**users**: None, True/False, string or list/tuple of strings.
|
||||
|
||||
- If **None**, team members will not be updated.
|
||||
- If **True**/**False**, all social auth users will be added/removed as team members.
|
||||
- If a string or list of strings, specifies expressions used to match users. User will be added as a team member if the username or email matches. Strings beginning and ending with ``/`` will be compiled into regular expressions; modifiers ``i`` (case-insensitive) and ``m`` (multi-line) may be specified after the ending ``/``.
|
||||
|
||||
**remove**: True/False. Defaults to **True**. When **True**, a user who does not match the rules above is removed from the team.
|
||||
|
||||
::
|
||||
|
||||
{
|
||||
"My Team": {
|
||||
"organization": "Test Org",
|
||||
"users": ["/^[^@]+?@test\\.example\\.com$/"],
|
||||
"remove": true
|
||||
},
|
||||
"Other Team": {
|
||||
"organization": "Test Org 2",
|
||||
"users": ["/^[^@]+?@test\\.example\\.com$/"],
|
||||
"remove": false
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Team mappings may be specified separately for each account authentication backend, based on which of these you setup. When defined, these configurations take precedence over the global configuration above.
|
||||
|
||||
::
|
||||
|
||||
SOCIAL_AUTH_GITHUB_TEAM_MAP = {}
|
||||
SOCIAL_AUTH_GITHUB_ORG_TEAM_MAP = {}
|
||||
SOCIAL_AUTH_GITHUB_TEAM_TEAM_MAP = {}
|
||||
|
||||
Uncomment the line below (i.e. set ``SOCIAL_AUTH_USER_FIELDS`` to an empty list) to prevent new user accounts from being created. Only users who have previously logged in to AWX using social or enterprise-level authentication or have a user account with a matching email address will be able to login.
|
||||
|
||||
::
|
||||
|
||||
SOCIAL_AUTH_USER_FIELDS = []
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 93 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB |
@@ -5,9 +5,6 @@
|
||||
pair: settings menu; configure the controller
|
||||
|
||||
|
||||
To enter the Settings window for AWX, click **Settings** from the left navigation bar. This page allows you to modify your AWX configuration, such as settings associated with authentication, jobs, system, and user interface.
|
||||
|
||||
.. image:: ../common/images/ug-settings-menu-screen.png
|
||||
:alt: The main settings window for AWX.
|
||||
To enter the Settings window for AWX, click **Settings** from the left navigation bar. This page allows you to modify your AWX configuration, such as settings associated with jobs, system, and user interface.
|
||||
|
||||
For more information on configuring these settings, refer to :ref:`ag_configure_awx` section of the |ata|.
|
||||
@@ -42,9 +42,6 @@ The very last item in the navigation bar is **Settings**, which provides access
|
||||
|
||||
The Settings page allows administrators to configure authentication, jobs, system-level attributes, and customize the user interface. Refer to :ref:`ag_configure_awx` section for more detail.
|
||||
|
||||
.. image:: ../common/images/ug-settings-menu-screen.png
|
||||
|
||||
|
||||
Regardless of the window or action you're performing, the very top of each page next to the your user icon is the About (|about|) icon, which provides you the versions of AWX and Ansible you are currently running.
|
||||
|
||||
.. |about| image:: ../common/images/help-about-icon.png
|
||||
|
||||
@@ -27,8 +27,6 @@ Known Issues
|
||||
pair: known issues; Ansible Azure dependencies
|
||||
pair: known issues; authentication (reactive user)
|
||||
pair: known issues; user cannot log in using authentication
|
||||
pair: known issues; login problems with social authentication
|
||||
pair: known issues; OAuth account recreation
|
||||
pair: known issues; login via http
|
||||
pair: known issues; web sockets in safari
|
||||
pair: known issues; browser auto-complete
|
||||
@@ -173,12 +171,6 @@ Database server installed on nodes
|
||||
All nodes in the cluster get a database server even if the nodes do not have a database. This is unexpected and may take up space.
|
||||
|
||||
|
||||
Reactivating OAuth authentication accounts which have been deleted
|
||||
===================================================================
|
||||
|
||||
Once a user who logs in using social authentication has been deleted, the user will not be able to login again or be recreated until the system administrator runs a ``cleanup_deleted`` action with ``days=0`` to allow users to login again. Once ``cleanup_deleted`` has been run, AWX must be restarted. Accounts which have been deleted prior to having the ``cleanup_deleted`` action run will receive a "Your account is inactive" message upon trying to login.
|
||||
|
||||
|
||||
Using vaulted variables in inventory sourced from a project
|
||||
===========================================================
|
||||
|
||||
|
||||
@@ -61,7 +61,7 @@ Glossary
|
||||
A collection of hosts against which Jobs may be launched.
|
||||
|
||||
Inventory Script
|
||||
A very simple program (or a complicated one) that looks up hosts, group membership for hosts, and variable information from an external resource--whether that be a SQL database, a CMDB solution, or something like LDAP. This concept was adapted from Puppet (where it is called an “External Nodes Classifier”) and works more or less exactly the same way.
|
||||
A very simple program (or a complicated one) that looks up hosts, group membership for hosts, and variable information from an external resource--whether that be a SQL database or a CMDB solution. This concept was adapted from Puppet (where it is called an “External Nodes Classifier”) and works more or less exactly the same way.
|
||||
|
||||
Inventory Source
|
||||
Information about a cloud or other script that should be merged into the current inventory group, resulting in the automatic population of Groups, Hosts, and variables about those groups and hosts.
|
||||
|
||||
@@ -473,7 +473,7 @@ Before AWX can use |ah| as the default source for collections content, you need
|
||||
|
||||
- **Galaxy Server URL** = ``https://cloud.redhat.com/api/automation-hub/``
|
||||
|
||||
- **AUTH SEVER URL** = ``https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token``
|
||||
- **AUTH SERVER URL** = ``https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token``
|
||||
|
||||
4. To use a private |ah|, create an |ah| credential using a token retrieved from the Repo Management dashboard of your local |ah| and pointing to the published repo URL as shown:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user