Chapter 3. Configuring authentication in the Ansible Automation Platform
Using the authentication settings in Ansible Automation Platform, you can set up a simplified login through several authentication methods, such as LDAP and SAML. Depending on the authentication method you select, you will be required to enter different information to complete the configuration. Be sure to include all the information required for your configuration needs.
3.1. Prerequisites
- A running installation of Ansible Automation Platform 2.5
- A running instance of your authentication source
- Administrator rights to the Ansible Automation Platform
- Any connection information needed to connect Ansible Automation Platform 2.5 to your source (see individual authentication types for details).
3.2. Pluggable authentication
Authentication is the process of verifying a user’s identity to the Ansible Automation Platform (that is, to establish that a user is who they say they are). This can be done in a number of ways but would traditionally be associated with a username
and password
.
Ansible Automation Platform 2.5 uses a pluggable authentication system with a configuration wizard that provides a common, simplified method of configuring different types of authenticators such as LDAP and SAML. The pluggable system also allows you to configure multiple authenticators of the same type.
In the pluggable system we have a couple of concepts:
- Authenticator Plugin
- A plugin allows Ansible Automation Platform to connect to a source system, such as, LDAP or SAML. Ansible Automation Platform includes a variety of authenticator plugins. Authenticator plugins are similar to Ansible collections, in that all of the required code is in a package and can be versioned independently if needed.
- Authenticator
- An authenticator is an instantiation of an authenticator plugin and allows users from the specified source to log in. For example, the LDAP authenticator plugin defines a required LDAP server setting. When you instantiate an authenticator from the LDAP authentication plugin, you must provide the authenticator the LDAP server URL it needs to connect to.
- Authenticator Map
- Authenticator maps are applied to authenticators and tell Ansible Automation Platform what permissions to give a user logging into the system.
3.3. Creating an authentication method
The Create Authentication wizard guides you through the steps to create a new authentication method for your organization. The wizard is launched during the create authentication process.
Creating an authenticator involves the following procedures:
- Authentication type, where you select the type of authenticator plugin you want to configure.
- Authentication details, where you configure the authentication details for the plugin you selected.
- Mapping, where you define mapping rule types and triggers to control access to the system.
Mapping order, where you can define the mapping precedence.
NoteMapping order is only available if you have defined one or more authenticator maps.
- Review, where you can review and confirm the authentication settings before creating the authentication method.
3.3.1. Selecting an authentication type
On the first screen of the wizard you can select the type of authenticator plugin you want to configure.
Procedure
-
From the navigation panel, select
. Click
.The Create Authentication wizard is displayed, where you can follow the prompts to configure your preferred authentication method.
- Select the authenticator type from the Authentication type list. See Configuring an authentication type for the complete list of authentication plugins available.
- Click Configure authentication details. to
3.3.2. Configuring authentication details
Different authenticator plugins require different types of information. See the respective sections in Configuring an authentication type for the required details.
For all authentication types you can enter a Name, Additional Authenticator Fields and Create Objects.
Procedure
Enter a unique Name for the authenticator. The name is required, must be unique across all authenticators, and must not be longer than 512 characters. This becomes the unique identifier generated for the authenticator.
NoteChanging the name does not update the unique identifier of the authenticator. For example, if you create an authenticator with the name “My Authenticator” and later change it to “My LDAP Authenticator” you will not be able to create another authenticator with the name “My Authenticator” because the unique identifier is still in use.
Use the Additional Authenticator Fields to send arbitrary data back to the libraries behind the authenticators. This is an advanced feature and any values provided in this field are not validated.
NoteValues defined in this field override the dedicated fields provided in the UI. For example, if you enter a URL in a dedicated field on this page and then add a URL entry into the Additional Authentication Fields, the URL defined in Additional Authentication Fields overrides the definition in the dedicated field.
- Enable or disable Enabled to specify if the authenticator should be enabled or disabled. If enabled, users are able to login from the authenticator. If disabled, users will not be allowed to login from the authenticator.
Enable or disable Create Object to specify whether the authenticator should create teams and organizations in the system when a user logs in.
- Enabled
- Teams and organizations defined in the authenticator maps are created and the users added to them.
- Disabled
- Organizations and teams defined in the authenticator maps will not be created automatically in the system. However, if they already exist (i.e. created by a superuser), users who trigger the maps are granted access to them.
Enable or disable Remove Users. If enabled, any access previously granted to a user is removed when they authenticate from this source. If disabled, permissions are only added or removed from the user based on the results of this authenticator’s authenticator mappings.
For example, assume a user has been granted the
is_superuser
permission in the system. And that user will log into an authenticator whose maps will not formulate an opinion as to whether or not the user should be a superuser. If Remove Users is enabled, theis_superuser
permission will be removed from the user, the authenticator maps will not have an opinion as to whether it should be there or not so, after login the user will not have theis_superuser
permission.If Remove Users is disabled, the
is_superuser
permission will not be removed from the user. The authenticator maps will not have an opinion as to whether it should be there or not so after login the user will have theis_superuser
permission.- Click Define authentication mapping rules and triggers. to
3.3.3. Defining authentication mapping rules and triggers
Authentication map types can be used with any type of authenticator. Each map has a trigger that defines when the map should be evaluated as true.
Procedure
Click Authenticator map types for detailed descriptions of the different map types. Choices include:
to see the list of available map types and select the map type you want to create. See- Enter a unique rule Name to identify the rule.
Select a Trigger from the list. See Authenticator map triggers for more details. Choices include:
- Always
- Never
- Group
- Attribute
- Repeat steps 1-3 to add additional triggers to the authenticator.
Click Adjust the Mapping order.
to optionallyNoteThe mapping order setting is only available if there is more than one authenticator map defined.
3.3.4. Adjusting the Mapping order
If you have one or more authenticator maps defined, you can manage the order of the maps. Authenticator maps are run in order when logging in lowest order to highest. If one authenticator map determines a user should be a member of a team but a subsequent map determines the user should not be a member of the same team the ruling form the second map will take precedence over the result of the first map. Authenticator maps with the same order are executed in an undefined order.
For example, if the first authenticator map is of type is_superuser
and the trigger is set to never, any user logging into the system would never be granted the is_superuser
flag.
And, if the second map is of type is_superuser
and the trigger is based on the user having a specific group, any user logging in would initially be denied the is_superuser
permission. However, any user with the specified group would subsequently be granted the is_superuser
permission by the second rule.
Procedure
Adjust the mapping order by dragging and dropping the mappings up or down in the list using the draggable icon.
NoteThe mapping precedence is determined by the order in which the mappings are listed.
- After your authenticator maps are in the correct order, click Review the authentication settings. to
3.3.5. Reviewing the authentication settings
After you have defined the authentication details, configured the authentication maps, and specified the mapping order precedence, you can review and verify, or modify the settings before creating the authenticator.
Procedure
- Review and verify the authentication settings.
Click
to create the authenticator.A notification is displayed if there are any issues with the authenticator or the map. If you encounter issues, click
or select a wizard section from the wizard menu to go back and add missing data or correct inaccurate data.
3.4. Configuring an authentication type
Ansible Automation Platform provides multiple authenticator plugins that you can configure to simplify the login experience for your organization. These are the authenticator plugins that are provided:
3.4.1. Configuring local authentication
As a platform administrator, you can configure local system authentication. With local authentication, users and their passwords are checked against local system accounts.
A local authenticator is automatically created by the Ansible Automation Platform installation process, and is configured with the specified admin credentials in the inventory file before installation. After successful installation, you can log in to the Ansible Automation Platform using those credentials.
Procedure
-
From the navigation panel, select
. - Click .
- Select Local from the Authentication type list and click .
- Enter a Name for this Local configuration. The configuration name is required, must be unique across all authenticators, and must not be longer than 512 characters.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.2. Configuring LDAP authentication
As a platform administrator, you can configure LDAP as the source for account authentication information for Ansible Automation Platform users.
When LDAP is configured, an account is created for any user who logs in with an LDAP username and password and they can be automatically placed into organizations as either regular users or organization administrators.
Users created through an LDAP login should not change their username, first name, last name, or set a local password for themselves. Any changes made to this information is overwritten the next time the user logs in to the platform.
Procedure
-
From the navigation panel, select
. - Click .
- Select LDAP from the Authentication type list and click .
- Enter a Name for this LDAP configuration. The configuration name is required, must be unique across all authenticators, and must not be longer than 512 characters.
- In the LDAP Server URI field, enter or modify the list of LDAP servers to which you want to connect. This field supports multiple addresses.
In the LDAP Bind DN text field, enter the Distinguished Name (DN) to specify the user that the Ansible Automation Platform uses to connect to the LDAP server. For example:
CN=josie,CN=users,DC=website,DC=com
- In the LDAP Bind Password text field, enter the password to use for the binding user.
Select a group type from the LDAP Group Type list.
NoteThe LDAP group types that are supported by the Ansible Automation Platform use the underlying django-auth-ldap library.
- To use LDAP User DN Template as an alternative to user search, enter the name of the template. This approach is more efficient for user lookups than searching if it is usable in your organizational environment. If this setting has a value it will be used instead of the LDAP User Search setting.
- LDAP Start TLS is disabled by default. To enable TLS when the LDAP connection is not using SSL, set the switch to On.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- Enter any LDAP Connection Options to set for the LDAP connection.
In the LDAP Group Type Parameters field, enter the parameters required for the LDAP Group Type you previously selected to identify LDAP groups and the members that belong to those groups.
To determine the parameters that a specific LDAP Group Type requires, refer to the django_auth_ldap documentation on the classes
init
parameters.- In the LDAP Group Search field, specify which groups should be searched and how to search them.
- In the LDAP User Attribute Map field, enter user attributes to map LDAP fields to your Ansible Automation Platform users for example, email or first_name.
- In the LDAP User Search field, enter where to search for users during authentication.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.3. Configuring SAML authentication
SAML allows the exchange of authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). Ansible Automation Platform is a SAML SP that can be configured to talk with one or more SAML IdPs in order to authenticate users. Based on groups and attributes optionally provided by the IdP users can be placed into teams and organizations in Ansible Automation Platform based on authenticator maps tied to this authenticator.
Procedure
-
From the navigation panel, select
. - Click .
- Select SAML from the Authentication type list and click .
- Enter a Name for this SAML configuration.
- Enter the application-defined unique identifier used as the audience of the SAML service provider configuration in the SAML Service Provider Entity ID field. This is usually the URL for the service.
- Include the certificate content in the SAML Service Provider Public Certificate field.
- Include the private key content in the SAML Service Provider Private Key.
- Enter the URL to redirect the user to for login initiation in the IdP Login URL field.
- Enter the public cert used for secrets coming from the IdP in the IdP Public Cert field.
- Enter the entity ID returned in the assertion in the Entity ID. .Enter user details in the Groups, User Email, Username, User Last Name, User First Name and User Permanent ID fields.
- The SAML Assertion Consumer Service (ACS) URL field registers the service as a service provider (SP) with each identity provider (IdP) you have configured.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
In the SAML Service Provider Organization Info field, provide the URL, display name, and the name of your app.
{ "en-US": { "url": "http://www.example.com", "displayname": "Example", "name": "example" } }
In the SAML Service Provider Technical Contact field, provide the name and email address of the technical contact for your service provider.
{ "givenName": "Some User", "emailAddress": "suser@example.com" }
In the SAML Service Provider Support Contact field, provide the name and email address of the support contact for your service provider.
{ "givenName": "Some User", "emailAddress": "suser@example.com" }
-
Optional: Provide extra configuration data in the SAML Service Provider extra configuration data field. This field is the equivalent to the
SOCIAL_AUTH_SAML_SP_EXTRA
in the API. For more information, see OneLogin’s SAML Python Toolkit to learn about the valid service provider extra (SP_EXTRA) parameters. Optional: Provide security settings in the SAML Security Config field. This field is the equivalent to the
SOCIAL_AUTH_SAML_SECURITY_CONFIG
field in the API.// Indicates whether the <samlp:AuthnRequest> messages sent by this SP // will be signed. [Metadata of the SP will offer this info] "authnRequestsSigned": false, // Indicates a requirement for the <samlp:Response>, <samlp:LogoutRequest> // and <samlp:LogoutResponse> elements received by this SP to be signed. "wantMessagesSigned": false, // Indicates a requirement for the <saml:Assertion> elements received by // this SP to be signed. [Metadata of the SP will offer this info] "wantAssertionsSigned": false,
For more information and additional options, see OneLogin’s SAML Python Toolkit.
- Optional: In the SAML IDP to extra_data attribute mapping field, enter values to map IDP attributes to extra_data attributes. For more information, see advanced SAML settings.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.4. Configuring TACACS+ authentication
Terminal Access Controller Access-Control System Plus (TACACS+) is a protocol that handles remote authentication and related services for networked access control through a centralized server. TACACS+ provides authentication, authorization and accounting (AAA) services, in which you can configure Ansible Automation Platform to use as a source for authentication.
This feature is deprecated and will be removed in a future release.
Procedure
-
From the navigation panel, select
. - Click .
- Select TACACS+ from the Authentication type list and click .
- Enter a Name for this TACACS+ configuration.
Enter the following information:
- Hostname of TACACS+ Server: Provide the hostname or IP address of the TACACS+ server with which to authenticate. If you leave this field blank, TACACS+ authentication is disabled.
- TACACS+ Authentication Protocol: The protocol used by the TACACS+ client. The options are ascii or pap.
- Shared secret for authenticating to TACACS+ server: The secret key for TACACS+ authentication server.
- The TACACS+ client address sending enabled is disabled by default. To enable client address sending, select the checkbox.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
Click
.
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.5. Configuring Microsoft Azure active directory authentication
To set up enterprise authentication for Microsoft Azure Active Directory (AD), you need to obtain an OAuth2 key and secret by registering your organization-owned application from Azure using the Quickstart: Register an application with the Microsoft identity platform.
Each key and secret must belong to a unique application and cannot be shared or reused between different authentication backends. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See dDisplaying authenticator details for instructions on accessing this information.
Procedure
-
From the navigation panel, select
. - Click .
- Select Azuread from the Authentication type list and click .
- Enter a Name for this authentication configuration.
Click Application (Client) ID to the OIDC Key field.
, copy and paste Microsoft’sFollowing instructions for registering your application with the Microsoft identity platform, supply the key (shown at one time only) to the client for authentication.
- Copy and paste the secret key created for your Microsoft Azure AD application to the OIDC Secret field.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
Click
.
Verification
To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials.
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
Additional resources
For application registering basics in Microsoft Azure AD, see the What is the Microsoft identity platform? overview.
3.4.6. Configuring Google OAuth2 authentication
To set up social authentication for Google, you must obtain an OAuth2 key and secret for a web application. To do this, you must first create a project and set it up with Google.
For instructions, see Setting up OAuth 2.0 in the Google API Console Help documentation.
If you have already completed the setup process, you can access those credentials by going to the Credentials section of the Google API Manager Console. The OAuth2 key (Client ID) and secret (Client secret) are used to supply the required fields in the UI.
Procedure
-
From the navigation panel, select
. - Click .
- Select Google OAuth from the Authentication type list and click .
- Enter a Name for this authentication setting.
The Google OAuth2 Key and Google OAuth2 Secret fields are pre-populated.
If not, use the credentials Google supplied during the web application setup process. Save these settings for use in the following steps.
- Copy and paste Google’s Client ID into the Google OAuth2 Key field.
- Copy and paste Google’s Client secret into the Google OAuth2 Secret field.
Optional: Enter information for the following fields using the tooltips provided for instructions and required format:
- Access Token URL
- Access Token Method
- Authorization URL
- Revoke Token Method
- Revoke Token URL
- OIDC JWT Algorithm(s)
- OIDC JWT
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
Click
.
Verification
To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials.
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.7. Configuring generic OIDC authentication
OpenID Connect (OIDC) uses the OAuth 2.0 framework. It enables third-party applications to verify the identity and obtain basic end-user information. The main difference between OIDC and SAML is that SAML has a service provider (SP)-to-IdP trust relationship, whereas OIDC establishes the trust with the channel (HTTPS) that is used to obtain the security token. To obtain the credentials needed to set up OIDC with Ansible Automation Platform, see the documentation from the IdP of your choice that has OIDC support.
Procedure
-
From the navigation panel, select
. - Click .
- Select Generic OIDC from the Authentication type list and click .
- Enter a Name for this authentication configuration.
Enter the following information:
- OIDC Provider URL: The URL for your OIDC provider.
- OIDC Key: The client ID from your third-party IdP.
- OIDC Secret: The client secret from your IdP.
- Optional: Select the HTTP method to be used when requesting an access token from the Access Token Method list. The default method is POST.
Optionally enter information for the following fields using the tooltips provided for instructions and required format:
- Access Token Method - The default method is POST.
- Access Token URL
- Access Token Method
- Authorization URL
- ID Key
- ID Token Issuer
- JWKS URI
- OIDC Public Key
- Revoke Token Method - The default method is GET.
- Revoke Token URL
- Response Type
- Token Endpoint Auth Method
- Userinfo URL
- Username Key
- Use the Verify OIDC Provider Certificate to enable or disable the OIDC provider SSL certificate verification.
- Use the Redirect State to enable or disable the state parameter in the redirect URI. It is recommended that this is enabled to prevent Cross Site Request Forgery (CSRF) attacks.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.8. Configuring keycloak authentication
You can configure Ansible Automation Platform to integrate Keycloak to manage user authentication.
Procedure
-
From the navigation panel, select
. - Click .
- Select Keycloak from the Authentication type list and click .
- Enter a Name for this keycloak configuration. The configuration name is required, must be unique across all authenticators, and must not be longer than 512 characters.
- Enter the location where the user’s token can be retrieved in the Keycloak Access Token URL field.
- Optional: Enter the redirect location the user is taken to during the login flow in the Keycloak Provider URL field.
- Enter the Client ID from your Keycloak installation in the Keycloak OIDC Key field.
- Enter the RS256 public key provided by your Keycloak realm in the Keycloak Public Key field.
- Enter the OIDC secret (Client Secret) from your Keycloak installation in the Keycloak OIDC Secret field.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.9. Configuring GitHub authentication
You can connect GitHub identities to Ansible Automation Platform using OAuth. To set up GitHub authentication, you need to obtain an OAuth2 key and secret by registering your organization-owned application from GitHub using the registering the new application with GitHub.
The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information.
Procedure
-
From the navigation panel, select
. - Click .
- Select GitHub from the Authentication type list and click .
- Enter a Name for this authentication configuration.
When the application is registered, GitHub displays the Client ID and Client Secret:
- Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
- Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Verification
To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials.
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.10. Configuring GitHub organization authentication
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 and by a team within an organization. You can also choose to permit all by specifying non-organization or non-team based settings. You can limit users who can log in to the platform by limiting only those in an organization or on a team within an organization.
To set up social authentication for a GitHub organization, you must obtain an OAuth2 key and secret for a web application using the registering the new application with GitHub.
The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information.
Procedure
-
From the navigation panel, select
. - Click .
- Select GitHub organization from the Authentication type list and click .
- Enter a Name for this authentication configuration.
When the application is registered, GitHub displays the Client ID and Client Secret:
- Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
- Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
-
Enter the name of your GitHub organization, as used in your organization’s URL, for example,
https://github.com/<yourorg>/
in the GitHub OAuth Organization Name field. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
-
Enter the authorization scope for users in the GitHub OAuth2 Scope field. The default is
read:org
. - To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Verification
To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials.
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.11. Configuring GitHub team authentication
To set up social authentication for a GitHub team, you must obtain an OAuth2 key and secret for a web application using the instructions provided in registering the new application with GitHub.
The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information.
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) are used to supply the required fields in the UI.
Procedure
-
From the navigation panel, select
. - Click .
- Select GitHub team from the Authentication type list and click .
- Enter a Name for this authentication configuration.
When the application is registered, GitHub displays the Client ID and Client Secret:
- Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
- Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
- Copy and paste GitHub’s team ID in the GitHub OAuth2 Team ID field.
-
Enter the authorization scope for users in the GitHub OAuth2 Scope field. The default is
read:org
. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Verification
To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials.
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.12. Configuring GitHub enterprise authentication
To set up social authentication for a GitHub enterprise, you must obtain a GitHub Enterprise URL, an API URL, OAuth2 key and secret for a web application.
To obtain the URLs, refer to the GitHub Enterprise administration documentation.
The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information.
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) are used to supply the required fields in the UI.
Procedure
-
From the navigation panel, select
. - Click .
- Select GitHub enterprise from the Authentication type list and click .
- Enter a Name for this authentication configuration.
When the application is registered, GitHub displays the Client ID and Client Secret:
- Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
- Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
-
In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example,
https://github.example.com
. -
In the Github OAuth2 Enterprise API URL field, enter the API URL of the GitHub Enterprise instance, for example,
https://github.example.com/api/v3
. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Verification
To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials.
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.13. GitHub Enterprise Organization settings
To set up social authentication for a GitHub Enterprise Organization, you must obtain a GitHub Enterprise Organization URL, an Organization API URL, an Organization OAuth2 key and secret for a web application.
To obtain the URLs, refer to the GitHub Enterprise administration documentation.
The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information.
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) are used to supply the required fields in the UI.
Procedure
-
From the navigation panel, select
. - Click .
- Select GitHub enterprise organization from the Authentication type list and click .
- Enter a Name for this authentication configuration.
When the application is registered, GitHub displays the Client ID and Client Secret:
- Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
- Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
-
In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example,
https://github.example.com
. -
In the Github OAuth2 Enterprise API URL field, enter the API URL of the GitHub Enterprise instance, for example,
https://github.example.com/api/v3
. -
Enter the name of your GitHub Enterprise organization, as used in your organization’s URL, for example,
https://github.com/<yourorg>/
in the GitHub OAuth2 Enterprise Org Name field. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Verification
To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials.
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.14. Configuring GitHub enterprise team authentication
To set up social authentication for a GitHub enterprise team, you must obtain a GitHub Enterprise Organization URL, an Organization API URL, an Organization OAuth2 key and secret for a web application.
To obtain the URLs, refer to the GitHub Enterprise administration documentation.
To obtain the key and secret, you must first register your enterprise organization-owned application at https://github.com/organizations/<yourorg>/settings/applications
.
The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information.
Each key and secret must belong to a unique application and cannot be shared or reused between different authentication backends. The OAuth2key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI.
Procedure
-
From the navigation panel, select
. - Click .
- Select GitHub enterprise team from the Authentication type list and click .
- Enter a Name for this authentication configuration.
When the application is registered, GitHub displays the Client ID and Client Secret:
- Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
- Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
-
In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example,
https://github.orgexample.com
. -
In the Github OAuth2 Enterprise API URL field, enter the API URL of the GitHub Enterprise instance, for example,
https://github.example.com/api/v3
. - Enter the OAuth2 key (Client ID) from your GitHub developer application in the GitHub OAuth2 team ID field.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Verification
To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials.
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.4.15. Configuring RADIUS authentication
You can configure Ansible Automation Platform to centrally use RADIUS as a source for authentication information.
Procedure
-
From the navigation panel, select
. - Click .
- Select Radius from the Authentication type list and click .
- Click .
- Enter the host or IP of the RADIUS server in the RADIUS Server field. If you leave this field blank, RADIUS authentication is disabled.
- Enter the Shared secret for authenticating to RADIUS server.
Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.
NoteValues defined in this field override the dedicated fields provided in the UI.
- To automatically create organizations, users, and teams upon successful login, select Create objects.
- To enable this authentication method upon creation, select Enabled.
- To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
- Click .
Next steps
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping.
3.5. Mapping
To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or what groups they belong to, you can configure authenticator maps.
Authenticator maps allow you to add conditions that must be met before a user is given or denied access to a resource type. Authenticator maps are associated with an authenticator and are given an order. The maps are processed in order when the user logs in. These can be thought of like firewall rules or mail filters.
3.5.1. Authenticator map types
Ansible Automation Platform supports the following rule types:
- Allow
- Determine if the user is allowed to log into the system.
- Organization
- Determine if a user should be put into an organization.
- Team
- Determine if the user should be a member of a team.
- Role
- Determine if the user is a member of a role (for example, System Auditor).
- Is Superuser
- Determine if the user is a superuser in the system.
These authentication map types can be used with any type of authenticator.
3.5.2. Authenticator map triggers
Each map has a trigger that defines when the map should be evaluated as true. Trigger types include the following:
- Always
- The trigger should always be fired.
- Never
- The trigger should never be fired.
- Group
The map is true or false based on a user having, not having or having multiple groups in the source system. When defining a group trigger, the authentication mapping expands to include the following selections:
Operation: This field includes conditional settings that trigger the handling of the rule based on the specified Groups criteria. The choices include and and or. For example, if you select and the user logging in must be a member of all of the groups specified in the Groups field for this trigger to be true. Alternatively, if you select or the user logging in must be a member of any of the specified Groups in order for the trigger to fire.
NoteIf you are only keying off one group it doesn’t matter if you select "and" or "or".
- Groups: This is a list of one or more groups coming from the authentication system that the user must be a member of. See the Operation field to determine the behavior of the trigger if more than one group is specified in the trigger.
- Attribute
The map is true or false based on a users attributes coming from the source system. When defining an attribute trigger, the authentication mapping expands to include the following selections:
Operation: This field includes conditional settings that trigger the handling of the rule based on the specified Attribute criteria. In version 2.5 this field indicates what will happen if the source system returns a list of attributes instead of a single value. For example, if the source system returns multiple emails for a user and Operation was set to and, all of the given emails must match the Comparison for the trigger to be True. If Operation was set to or, any of the returned emails will set the trigger to True if they match the Comparison in the trigger.
NoteIf you would like to experiment with multiple attribute maps you can do that through the API but the UI form will remove multi-attribute maps if the authenticator is saved through the UI. When adding multiple attributes to a map, the Operation will also apply to the attributes.
-
Attribute: The name of the attribute coming from the source system this trigger will be evaluated against. For example, if you wanted the trigger to fire based on the user’s last name and the last name field in the source system was called
users_last_name
you would enter the value ‘users_last_name’ in this field. Comparison: Tells the trigger how to evaluate the value of the users. Attribute in the source system compared to the Value specified on the trigger. Available options are: contains, matches, ends with, in, or equals. Below is a breakdown of each Comparison type:
- contains: The specified character sequence in Value is contained within the attributes value returned from the source. For example, given an attribute value of ‘John’ from the source the contains Comparison would set the trigger to True if the trigger Value was set to ‘Jo’ and False if the trigger Value was ‘Joy’.
- matches: The Value on the trigger is treated as a python regular expression and does an Regular expression match (re.match) (with case ignore on) between the specified Value and the value returned from the source system. For example, if the trigger’s Value was ‘Jo’ the trigger would return True if the value from the source was ‘John‘ or ‘Joanne‘ or any other value which matched the regular expression ‘Jo’. The trigger would return False if the sources value for the attribute was ‘Dan’ because ‘Dan’ does not match the regular expression ‘Jo’.
- ends with: The trigger will see if the value provided by the source ends with the specified Value of the trigger. For example, if the source provided a value of ‘John’ the trigger would be True if its Value was set to ‘n’ or ‘on’. The trigger would be False if its Value was set to ‘z’ because the value ‘John’ coming from the source does not end with the value ’z’ specified by the trigger.
- equal: The trigger will see if the value provided by the source is equal to (in its entirety) the specified Value of the trigger. For example, if the source returned the value ‘John’, the trigger would be True if its Value was set to ‘John’. Any value other than ‘John’ returned from the source would set this trigger to False.
- in: The in condition will see if the value matches one of several values. When in is specified as the Comparison, the Value field can be a comma separated list. For example, if a trigger had a Value of ‘John,Donna’ the trigger would be True if the attribute coming from the source had either the value ‘John’ or ‘Donna’. Otherwise, the trigger would be False.
Value: The value that a users attribute will be matched against based on the Comparison field. See examples in the Comparison definition in this section.
NoteIf the Comparison type is in, this field can be a comma separated list (without spaces).
3.5.3. Authenticator map examples
-
Make this user a superuser if they have an attribute called
aap_superuser
with a value of True. -
Add this user to a team if they have the group
cn=Administrators,ou=AAP,ou=example,o=com
orcn=Operators,ou=AAP,ou=example,o=com
. -
Never allow access to the system if the user has an attribute called
disabled
with a value of True, Yes or Until Further Notice.
Since maps are executed in order, it is possible to create exceptions. Expanding on the previous example for “Never allow access to the system if the user has an attribute called disabled with a value of True, Yes or Until Further Notice.
You can add another rule with a higher order, such as, “Allow access to the system for a disabled
user if they are in the group Emergency Contacts
.”
The first rule prevents the disabled user from accessing the system, but the second rule alters that decision to grant access to the system for the disabled user if they are in the Emergency Contacts
group.
3.5.4. Allow mapping
With allow mapping, you can control which users have access to the system by defining the conditions that must be met.
Procedure
- After configuring the authentication details for your authentication method, select Allow from the Add authentication mapping list.
- Enter a unique rule Name to identify the rule.
- Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
- Select Revoke to deny user access to the system when none of the trigger conditions are matched.
- Click .
Next steps
You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.
NoteThe mapping precedence is determined by the order in which the mappings are listed.
- Click to review and verify the mapping configurations.
- Click .
3.5.5. Organization mapping
You can control which users are placed into which Ansible Automation Platform organizations based on attributes like their username and email address or based on groups provided from an authenticator.
When organization mapping is positively evaluated, a specified organization is created, if it does not exist if the authenticator tied to the map is allowed to create objects.
Procedure
- After configuring the authentication details for your authentication type, select Organization from the Add authentication mapping list.
- Enter a unique rule Name to identify the rule.
- Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
- Select Revoke to deny user access to the system when none of the trigger conditions are matched.
- Select the Organization to which matching users are added or blocked.
- Select a Role to be applied or removed for matching users (for example, Organization Admin or Organization Member).
- Click .
Next steps
You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.
NoteThe mapping precedence is determined by the order in which the mappings are listed.
- Click to review and verify the mapping configurations.
- Click .
3.5.6. Team mapping
Team mapping is the mapping of team members (users) from authenticators.
You can define the options for each team’s membership. For each team, you can specify which users are automatically added as members of the team and also which users can administer the team.
Team mappings can be specified separately for each account authentication.
When Team mapping is positively evaluated, a specified team and its organization are created, if they don’t exist if the related authenticator is allowed to create objects.
Procedure
- After configuring the authentication details for your authentication type, select Team from the Add authentication mapping list.
- Enter a unique rule Name to identify the rule.
- Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
- Select Revoke to deny user access to the system when none of the trigger conditions are matched.
- Select the Team and Organization to which matching users are added or blocked.
- Select a Role to be applied or removed for matching users (for example, Team Admin or Team Member).
- Click .
Next steps
You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.
NoteThe mapping precedence is determined by the order in which the mappings are listed.
- Click to review and verify the mapping configurations.
- Click .
3.5.7. Role mapping
Role mapping is the mapping of a user either to a global role, such as Platform Auditor, or team or organization role.
When a Team and/or Organization is specified together with the appropriate Role, the behavior is identical with Organization mapping or Team mapping.
Role mapping can be specified separately for each account authentication.
Procedure
- After configuring the authentication details for your authentication type, select Team from the Add authentication mapping list.
- Enter a unique rule Name to identify the rule.
- Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
- Select Revoke to remove the role for the user when none of the trigger conditions are matched.
- Select a Role to be applied or removed for matching users.
- Click .
Next steps
You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.
NoteThe mapping precedence is determined by the order in which the mappings are listed.
- Click to review and verify the mapping configurations.
- Click .
3.5.8. Superuser mapping
Role mapping is the mapping of a user either to a global role, such as Platform Auditor, or team or organization role.
When a Team and/or Organization is specified together with the appropriate Role, the behavior is identical with Organization mapping or Team mapping.
Role mapping can be specified separately for each account authentication.
Procedure
- After configuring the authentication details for your authentication type, select Team from the Add authentication mapping list.
- Enter a unique rule Name to identify the rule.
- Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
- Select Revoke to remove the superuser role from the user when none of the trigger conditions are matched.
- Click .
Next steps
You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.
NoteThe mapping precedence is determined by the order in which the mappings are listed.
- Click to review and verify the mapping configurations.
- Click .
3.6. Managing authentication in Ansible Automation Platform
After you have configured your authentication settings, you can view a list of authenticators, search, sort and view the details for each authenticator configured on the system.
3.6.1. Authentication list view
On the Authentication Methods page, you can view and manage the configured authentication methods for your organization.
Procedure
From the navigation panel, select
. The Authentication Methods page is displayed.
- Click Configuring an authentication type. Otherwise, proceed to step 3. and follow the steps for creating an authentication method in
- From the menu bar, you can sort the list of authentication methods by using the arrows in the menu bar for Order, Name and Authentication type.
- Click the toggles to Enable or Disable authenticators.
3.6.2. Searching for an authenticator
You can search for a previously configured authenticator from the Authentication list view.
Procedure
-
From the navigation panel, select
. - In the search bar, enter an appropriate keyword for the authentication method you want to search for and click the arrow icon.
- If you don’t find what you’re looking for, you can narrow your search. From the filter list, select Name or Authentication type depending on the search term you want to use.
- Scroll through the list of search results and select the authenticator you want to review.
3.6.3. Displaying authenticator details
After you locate the authenticator you want to review, you can display the configuration details:
Procedure
-
From the navigation panel, select
. In the list view, select the authenticator name displayed in the Name column.
The authenticator Details page is displayed.
- From the Details page, you can review the configuration settings applied to the authenticator.
3.6.4. Editing an authenticator
You can modify the settings of previously configured authenticators from the Authentication list view.
Procedure
-
From the navigation panel, select
. In the list view, you can either:
- Select the icon next to authenticator you want to modify, or
- Select the authenticator name displayed in the Name column and click from the Details page.
- Modify the authentication details or mapping configurations as required.
- Click .
3.6.5. Deleting an authenticator
You can modify the settings of previously configured authenticators from the Authentication list view.
Procedure
-
From the navigation panel, select
. - In the list view, select the checkbox next to the authenticator you want to delete.
Select Delete authentication from the ⋮ list.
NoteYou can delete multiple authenticators by selecting the checkbox next to each authenticator you want to remove, and clicking Delete selected authentication from the ⋮ list on the menu bar.