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.
Prior to Ansible Tower version 3.1, social authentication can only be configured in the /etc/tower/settings.py or the configuration files within /etc/tower/conf.d/. Starting with Ansible Tower version 3.1, instead of flat files, the configuration files are now saved to the Postgres database. Therefore, it is important that social authentication be configured in the Ansible Tower User Interface. For instructions, refer to the Configure Tower in Tower section.
Social authentication in Ansible Tower can be configured to centrally use OAuth2, while enterprise-level authentication can be configured for SAML, RADIUS, or even LDAP as a source for authentication information.
For websites, such as Microsoft Azure, Google or GitHub, that provide account information, account information is often implemented using the OAuth standard. OAuth is a secure authorization protocol which is commonly used in conjunction with authentication to grant 3rd party applications a “session token” allowing them to make API calls to providers on the user’s behalf.
SAML (Security Assertion Markup Language) is an XML-based, open-standard data format for exchanging authentication and authorization data between an identity provider and a service provider.
The RADIUS distributed client/server system allows you to secure networks against unauthorized access and can be implemented in network environments requiring high levels of security while maintaining network access for remote users.
For details on completing the mapping fields, see Organization and Team Mapping.
For application registering basics in Azure AD, refer to: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-scenarios#basics-of-registering-an-application-in-azure-ad
https://tower.example.com/sso/complete/google-oauth2/Refer to the Python Social Auth documentation for advanced settings: https://python-social-auth.readthedocs.org/en/latest/backends/google.html#google-oauth2
For details on completing the mapping fields, see Organization and Team Mapping.
https://tower.example.com/sso/complete/github/For details on completing the mapping fields, see Organization and Team Mapping.
When defining authentication with either an organization or a team within an organization, you should use the specific organization and team settings. Authentication can be limited by an organization as well as by a team within an organization.
You can also choose to allow all by specifying non-organization or non-team based settings (as shown above).
You can limit users who can login to Tower by limiting only those in an organization or on a team within an organization.
To setup authentication for your organization:
https://github.com/organizations/<yourorg>/settings/applications and obtain an OAuth2 key (Client ID) and secret (Client Secret). Each key and secret must belong to a unique application and cannot be shared or reused between different social authentication backends.https://tower.example.com/sso/complete/github-org/For details on completing the mapping fields, see Organization and Team Mapping.
To setup authentication for your team:
https://github.com/organizations/<yourorg>/settings/applications and obtain an OAuth2 key (Client ID) and secret (Client Secret). Each key and secret must belong to a unique application and cannot be shared or reused between different social authentication backends.https://tower.example.com/sso/complete/github-team/Refer to Python Social Auth documentation for advanced settings: https://python-social-auth.readthedocs.org/en/latest/backends/github.html
For details on completing the mapping fields, see Organization and Team Mapping.
Note
SAML authentication is a feature specific to Enterprise-level license holders.
To setup SAML authentication:
As an example for public certs:
SOCIAL_AUTH_SAML_SP_PUBLIC_CERT = '''
-----BEGIN CERTIFICATE——
... cert text ...
-----END CERTIFICATE——
As an example for private keys:
SOCIAL_AUTH_SAML_SP_PRIVATE_KEY = '''
-----BEGIN PRIVATE KEY--
... key text ...
-----END PRIVATE KEY——
'''
Some IdPs may provide user data using attribute names that differ from the default OIDs (https://github.com/omab/python-social-auth/blob/master/social/backends/saml.py). Attribute names may be overridden for each IdP as shown below.
SOCIAL_AUTH_SAML_ENABLED_IDPS = {
'myidp': {
'entity_id': 'https://idp.example.com',
'url': 'https://myidp.example.com/sso',
'x509cert': '',
},
'onelogin': {
'entity_id': 'https://app.onelogin.com/saml/metadata/123456',
'url': 'https://example.onelogin.com/trust/saml2/http-post/sso/123456',
'x509cert': '',
'attr_user_permanent_id': 'name_id',
'attr_first_name': 'User.FirstName',
'attr_last_name': 'User.LastName',
'attr_username': 'User.email',
'attr_email': 'User.email',
},
}
For details on completing the mapping fields, see Organization and Team Mapping.
Note
RADIUS authentication is a feature specific to Enterprise-level license holders.
Ansible Tower can be configured to centrally use RADIUS as a source for authentication information.
Note
LDAP authentication is a feature specific to Enterprise-level license holders.
Administrators use LDAP as a source for authentication information for Tower users. User authentication is provided, but not the synchronization of user permissions and credentials. Organization membership (as well as the organization admin) and team memberships can be synchronized.
When so configured, a user who logs in with an LDAP username and password automatically gets a Tower account created for them and they can be automatically placed into organizations as either regular users or organization administrators.
Users created via an LDAP login cannot change their username, first name, last name, or set a local password for themselves. This is also tunable to restrict editing of other field names.
To configure LDAP integration for Tower:
For details on completing the mapping fields, see Organization and Team Mapping.
To enable logging for LDAP, you must set the level to DEBUG in the LDAP configuration file, /etc/tower/conf/ldap.py:
LOGGING['handlers']['tower_warnings']['level'] = 'DEBUG'
Next, you will need to control which users are placed into which Tower 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 social authentication will automatically be added as admins of the organization.
- If False, no social 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. Compiled regular expressions may also be used instead of string literals.
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.
- When True, a user who does not match is removed from the organization’s administrative list.
remove_users: True/False. Defaults to True.
- When True, a user who does not match is removed from the organization’s administrative list.
SOCIAL_AUTH_ORGANIZATION_MAP = {
Add all users to the default organization.
'Default': {
'users': True,
},
'Test Org': {
'admins': ['[email protected]'],
'users': True,
},
'Test Org 2': {
'admins': ['[email protected]', re.compile(r'^tower-[^@]+*?@.*$],
'users': re.compile(r'^[^@].*?@example\.com$'),
},
}
Organization mappings may be specified separately for each social authentication backend. If defined, these configurations will take precedence over the global configuration above.
SOCIAL_AUTH_GOOGLE_OAUTH2_ORGANIZATION_MAP = {}
SOCIAL_AUTH_GITHUB_ORGANIZATION_MAP = {}
SOCIAL_AUTH_GITHUB_ORG_ORGANIZATION_MAP = {}
SOCIAL_AUTH_GITHUB_TEAM_ORGANIZATION_MAP = {}
SOCIAL_AUTH_SAML_ORGANIZATION_MAP = {}
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. Compiled regular expressions may also be used instead of string literals.
remove: True/False. Defaults to True. When True, a user who does not match the rules above is removed from the team.
SOCIAL_AUTH_TEAM_MAP = {
'My Team': {
'organization': 'Test Org',
'users': ['re.compile(r'^[^@]+?@test\.example\.com$')'],
'remove': True,
},
'Other Team': {
'organization': 'Test Org 2',
'users': re.compile(r'^[^@]+?@test2\.example\.com$'),
'remove': False,
},
}
Team mappings may be specified separately for each social authentication backend, based on which of these you setup. When defined, these configurations take precedence over the the global configuration above.
SOCIAL_AUTH_GOOGLE_OAUTH2_TEAM_MAP = {}
SOCIAL_AUTH_GITHUB_TEAM_MAP = {}
SOCIAL_AUTH_GITHUB_ORG_TEAM_MAP = {}
SOCIAL_AUTH_GITHUB_TEAM_TEAM_MAP = {}
SOCIAL_AUTH_SAML_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 Tower 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 = []