18. Setting up Social Authentication¶

18.3.1. Github Org Settings¶

When defining account authentication with either an organization or a team within an organization, you should use the specific organization and team settings. Account 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 set up social authentication for a GitHub Organization, you will need to obtain an OAuth2 key and secret for a web application. To do this, you must first register your organization-owned application at https://github.com/organizations/<yourorg>/settings/applications. In order to register the application, you must supply it with your Authorization callback URL, which is the Callback URL shown in the Configure Tower user interface. Each key and secret must belong to a unique application and cannot be shared or reused between different authentication backends. The OAuth2 key (Client ID) and secret (Client Secret) will be used to supply the required fields in the Ansible Tower User Interface.

1. In the Ansible Tower User Interface, click Authentication from the Settings () Menu screen.

The Azure AD tab displays initially by default.

2. Select the GitHub tab and select GutHub Org from the GitHub Category drop-down menu list.

3. The GitHub Organization OAuth2 Callback URL field is already pre-populated and non-editable.

Once the application is registered, GitHub displays the Client ID and Client Secret.

4. Copy and paste GitHub’s Client ID into the GitHub Organization OAuth2 Key field.

5. Copy and paste GitHub’s Client Secret into the GitHub Organization OAuth2 Secret field.

6. For details on completing the mapping fields, see Organization and Team Mapping.

7. Click Save when done.

8. To verify that the authentication was configured correctly, logout of Ansible Tower and the login screen will now display the GitHub Organization logo to allow logging in with those credentials.

18.3.2. Github Team Settings¶

To set up social authentication for a GitHub Team, you will need to obtain an OAuth2 key and secret for a web application. To do this, you must first register your team-owned application at https://github.com/organizations/<yourorg>/settings/applications. In order to register the application, you must supply it with your Authorization callback URL, which is the Callback URL shown in the Configure Tower user interface. Each key and secret must belong to a unique application and cannot be shared or reused between different authentication backends. The OAuth2 key (Client ID) and secret (Client Secret) will be used to supply the required fields in the Ansible Tower User Interface.

1. Find the numeric team ID using the Github API: http://fabian-kostadinov.github.io/2015/01/16/how-to-find-a-github-team-id/. The Team ID will be used to supply a required field in the Ansible Tower User Interface.

2. In the Ansible Tower User Interface, click Authentication from the Settings () Menu screen.

The Azure AD tab displays initially by default.

3. Select the GitHub tab and select GutHub Team from the GitHub Category drop-down menu list.

4. The GitHub Team OAuth2 Callback URL field is already pre-populated and non-editable.

Once the application is registered, GitHub displays the Client ID and Client Secret.

5. Copy and paste GitHub’s Client ID into the GitHub Team OAuth2 Key field.

6. Copy and paste GitHub’s Client Secret into the GitHub Team OAuth2 Secret field.

7. For details on completing the mapping fields, see Organization and Team Mapping.

8. Click Save when done.

9. To verify that the authentication was configured correctly, logout of Ansible Tower and the login screen will now display the GitHub Team logo to allow logging in with those credentials.

18.4.1. Organization mapping¶

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 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": ["[email protected]"],
        "users": true
    },
    "Test Org 2": {
        "admins": ["[email protected]", "/^tower-[^@]+?@.*$/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.

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 = {}

18.4.2. 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 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 = []