Chapter 3. Configuring authentication in the Ansible Automation Platform

Procedure

1. From the navigation panel, select Access Management Authentication Methods.

2. Click Create authentication.

   The Create Authentication wizard is displayed, where you can follow the prompts to configure your preferred authentication method.

3. Select the authenticator type from the Authentication type list. See Configuring an authentication type for the complete list of authentication plugins available.
4. Click Next to Configure authentication details.

Procedure

1. 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.

   Note

   Changing 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.

2. 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.

   Note

   Values 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.

3. 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.

4. 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.

5. 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, the is_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 the is_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 the is_superuser permission.

6. Click Next to Define authentication mapping rules and triggers.

Procedure

1. Click Add authentication mapping to see the list of available map types and select the map type you want to create. See Authenticator map types for detailed descriptions of the different map types. Choices include:

   • Allow
   • Organization
   • Team
   • Role
   • Is Superuser
2. Enter a unique rule Name to identify the rule.

3. Select a Trigger from the list. See Authenticator map triggers for more details. Choices include:

   • Always
   • Never
   • Group
   • Attribute
4. Repeat steps 1-3 to add additional triggers to the authenticator.

5. Click Next to optionally Adjust the Mapping order.

   Note

   The mapping order setting is only available if there is more than one authenticator map defined.

Procedure

1. Adjust the mapping order by dragging and dropping the mappings up or down in the list using the draggable icon.

   Note

   The mapping precedence is determined by the order in which the mappings are listed.

2. After your authenticator maps are in the correct order, click Next to Review the authentication settings.

Procedure

1. Review and verify the authentication settings.

2. Click Finish to create the authenticator.

   A notification is displayed if there are any issues with the authenticator or the map. If you encounter issues, click Back or select a wizard section from the wizard menu to go back and add missing data or correct inaccurate data.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select Local from the Authentication type list and click Next.
4. 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.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

   Note

   Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

7. To automatically create organizations, users, and teams upon successful login, select Create objects.
8. To enable this authentication method upon creation, select Enabled.
9. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
10. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select LDAP from the Authentication type list and click Next.
4. 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.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.
6. 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.

7. 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 as shown in the following example:

   CN=josie,CN=users,DC=website,DC=com

8. In the LDAP Bind Password text field, enter the password to use for the binding user.

9. Select a group type from the LDAP Group Type list.

   The group type defines the class name of the group, which manages the groups associated with users in your LDAP directory and is returned by the search specified in Step 14 of this procedure. The group type, along with group parameters and the group search, is used to find and assign groups to users during log in, and can also be evaluated during the mapping process. The following table lists the available group types, along with their descriptions and the necessary parameters for each. By default, LDAP groups will be mapped to Django groups by taking the first value of the cn attribute. You can specify a different attribute with name_attr. For example, name_attr='cn'.

   Table 3.1. Available LDAP group types

   LDAP Group Type	Description	Initializer method (init)
   PosixGroupType	Handles the posixGroup object class. This checks for both primary group and group membership.	name_attr='cn'
   MemberDNGroupType	Handles the grouping mechanisms wherein the group object contains a list of its member DNs.	member_attr, name_attr='cn'
   GroupOfNamesType	Handles the groupOfNames object class. Equivalent to MemberDNGroupType('member').	name_attr='cn'
   GroupOfUniqueNamesType	Handles the groupOfUniqueNames object class. Equivalent to MemberDNGroupType('uniqueMember').	name_attr='cn'
   ActiveDirectoryGroupType	Handles the Active Directory groups. Equivalent to MemberDNGroupType('member').	name_attr='cn'
   OrganizationalRoleGroupType	Handles the organizationalRole object class. Equivalent to MemberDNGroupType('roleOccupant').	name_attr='cn'
   NestedGroupOfNamesType	Handles the groupOfNames object class. Equivalent to NestedMemberDNGroupType('member').	member_attr, name_attr='cn'
   NestedGroupOfUniqueNamesType	Handles the groupOfUniqueNames object class. Equivalent to NestedMemberDNGroupType('uniqueMember').	name_attr='cn'
   NestedActiveDirectoryGroupType	Handles the Active Directory groups. Equivalent to NestedMemberDNGroupType('member').	name_attr='cn'
   NestedOrganizationalRoleGroupType	Handles the organizationalRole object class. Equivalent to NestedMemberDNGroupType('roleOccupant').	name_attr='cn'

   Note

   The group types that are supported by Ansible Automation Platform use the underlying django-auth-ldap library. To specify the parameters for the selected group type, see Step 14 of this procedure.

10. You can use LDAP User DN Template as an alternative to user search. This approach is more efficient for user lookups than searching if it is usable in your organizational environment. Enter the name of the template as shown in the following example:

    uid=%(user)s,cn=users,cn=accounts,dc=example,dc=com

    where: uid is the user identifier, cn is the common name and dc is the domain component.

    Note

    If this setting has a value it will be used instead of the LDAP User Search setting.

11. LDAP Start TLS is disabled by default. StartTLS allows your LDAP connection to be upgraded from an unencrypted connection to a secure connection using Transport Layer Security (TLS). To enable StartTLS when the LDAP connection is not using SSL, set the switch to On.

12. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

    Note

    Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

13. Enter any LDAP Connection Options to set for the LDAP connection. LDAP referrals are disabled by default (to prevent certain LDAP queries from hanging with Active Directory). Option names should be strings as shown in the following example:

    OPT_REFERRALS: 0
    OPT_NETWORK_TIMEOUT: 30

    See the python-LDAP Reference for possible options and values that can be set.

14. Depending on the selected LDAP Group Type, different parameters are available in the LDAP Group Type Parameters field to account for this. LDAP_GROUP_TYPE_PARAMS is a dictionary, which is converted to kwargs and passed to the LDAP Group Type class selected. There are two common parameters used by group types: name_attr and member_attr. Where name_attr defaults to cn and member_attr defaults to member:

    {"name_attr": "cn", "member_attr": "member"}

    To determine the parameters that a specific LDAP Group Type requires, refer to the django_auth_ldap documentation on the classes init parameters.

15. In the LDAP Group Search field, specify which groups should be searched and how to search them as shown in the following example:

    [
    "dc=example,dc=com",
    "SCOPE_SUBTREE",
    "(objectClass=group)"
     ]

16. 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 as shown in the following example:

    {
    "first_name": "givenName",
    "last_name": "sn",
    "email": "mail"
    }

17. In the LDAP User Search field, enter where to search for users during authentication as shown in the following example:

    [
    "OU=Users,DC=website,DC=com",
    "SCOPE_SUBTREE",
    "(cn=%(user)s)"
    ]

    If the LDAP User DN Template is not set, the Ansible Automation Platform authenticates to LDAP using the Bind DN Template and LDAP Bind Password. After authentication, an LDAP search is performed to locate the user specified by this field. If the user is found, Ansible Automation Platform validates the provided password against the user found by the LDAP search. Multiple search queries are supported for users with LDAPUnion by entering multiple search terms as shown in the following example:

    [
        [
            "ou=users,dc=example,dc=com",
            "SCOPE_SUBTREE",
            "uid=%(user)s"
        ],
         [
            "ou=employees,dc=subdivision,dc=com",
            "SCOPE_SUBTREE",
            "uid=%(user)s"
         ]
    ]

    If non-unique users are found during multiple searches, those users will not be able to log in to Ansible Automation Platform. Based on the example provided, if a user with uid=jdoe was found in both the ou=users,dc=example,dc=com and ou=employees,dc=subdivision,dc=com, neither jdoe user would be able to log in. All other unique users that are found in either branch would still be able to log in.

    Note

    If the field LDAP User DN Template is populated, it takes precedence over the LDAP User Search field and only the template will be used to authenticate users.

18. To automatically create organizations, users, and teams upon successful login, select Create objects.
19. To enable this authentication method upon creation, select Enabled.
20. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
21. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select SAML from the Authentication type list and click Next.
4. Enter a Name for this SAML configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.
6. 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 base URL of your service provider, but the actual value depends on the Entity ID expected by your IdP.
7. Include the certificate content in the SAML Service Provider Public Certificate field. This information is contained in the cert.pem you created as a prerequisite and must include the —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—–.
8. Include the private key content in the SAML Service Provider Private Key field. This information is contained in the key.pem you created as a prerequisite and must include the —–BEGIN PRIVATE KEY—– and —–END PRIVATE KEY—–.
9. Enter the URL to redirect the user to for login initiation in the IdP Login URL field. This is the login URL from your SAML IdP application.

10. Enter the public cert used for secrets coming from the IdP in the IdP Public Cert field. This is the SAML certificate available for download from IdP.

    Note

    The IdP in the IdP Public Cert field should contain the entire certificate, including the —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—–. You must manually enter the prefix and suffix if the IdP does not include it.

11. Enter the entity ID returned in the assertion in the Entity ID. This is the identifier from your IdP SAML application. You can find this value in the SAML metadata provided by your IdP.
12. Enter user details in the Groups, User Email, Username, User Last Name and User First Name.

13. Enter a permanent ID for the user in the User Permanent ID field. This field is required.

    Note

    Additional attributes might be available through your SAML IdP. Those values must be included in either the Additional Authenticators Fields or the SAML IDP to extra_data attribute mapping field. Refer to those steps for details.

14. The SAML Assertion Consumer Service (ACS) URL field registers the service as a service provider (SP) with each identity provider (IdP) you have configured. Leave this field blank. After you save this authentication method, it is auto generated. This field must match the Reply URL setting in your IdP.

15. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. For example, to ensure all SAML IdP attributes other than Email, Username, Last Name, First Name are included for mapping, enter the following:

    GET_ALL_EXTRA_DATA: true

    Alternatively, you can include a list of SAML IdP attributes in the SAML IDP to extra_data attribute mapping field.

    Note

    Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

16. 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"
      }
    }

17. In the SAML Service Provider Technical Contact field, give the name and email address of the technical contact for your service provider.

    {
    "givenName": "Some User",
    "emailAddress": "suser@example.com"
    }

18. In the SAML Service Provider Support Contact field, give the name and email address of the support contact for your service provider.

    {
    "givenName": "Some User",
    "emailAddress": "suser@example.com"
    }

19. Optional: Provide extra configuration data in the SAML Service Provider extra configuration data field. For example, you can choose to enable signing requests for added security:

    {
    "sign_request": True,
    }

    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.

20. 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,
    
    // Authentication context.
    // Set to false and no AuthContext will be sent in the AuthNRequest,
    // Set true or don't present this parameter and you will get an AuthContext 'exact' 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport'
    // Set an array with the possible auth context values: array ('urn:oasis:names:tc:SAML:2.0:ac:classes:Password', 'urn:oasis:names:tc:SAML:2.0:ac:classes:X509'),
    "requestedAuthnContext": true,

    For more information and additional options, see OneLogin’s SAML Python Toolkit.

21. Optional: In the SAML IDP to extra_data attribute mapping field, enter values to map IDP attributes to extra_data attributes. These values will include additional user information beyond standard attributes like Email or Username to be mapped. For example:

    - Department
    - UserType
    - Organization

    For more information on the values you can include, see advanced SAML settings.

    Important

    Make sure you include all relevant values so that everything gets mapped correctly for your configuration. Alternatively, you can include the GET_ALL_EXTRA_DATA: true in the Additional Authenticator Fields to allow mapping of all available SAML IdP attributes.

22. To automatically create organizations, users, and teams upon successful login, select Create objects.
23. To enable this authentication method upon creation, select Enabled.
24. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
25. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select TACACS+ from the Authentication type list and click Next.
4. Enter a Name for this TACACS+ configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. 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.
7. The TACACS+ client address sending enabled is disabled by default. To enable client address sending, select the checkbox.

8. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

   Note

   Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

9. To automatically create organizations, users, and teams upon successful login, select Create objects.
10. To enable this authentication method upon creation, select Enabled.

11. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.

    Click Next.

1. Configure your Ansible Automation Platform to use Microsoft Entra ID authentication using the steps in this procedure.
2. Register Ansible Automation Platform in Microsoft Entra ID by following the Quickstart: Register an application with the Microsoft identity platform. This process provides you with an Application (client) ID and Application secret.
3. Add the redirect URL in Microsoft Entra ID. After completing the configuration wizard for Microsoft Entra ID authentication in your platform, copy the URL displayed in the Azure AD OAuth2 Callback URL field. Then, go to your registered enterprise application in Azure and add this URL as a Redirect URL (also referred to as a Callback URL in Ansible Automation Platform) as described in How to add a redirect URI to your application. This step is required for the login flow to work correctly.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select Azuread from the Authentication type list and click Next.
4. Enter a Name for this authentication configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.
6. Click Edit, copy and paste Microsoft’s Application (Client) ID to the OIDC Key field.

7. If your Microsoft Entra ID is configured to provide user group information within a groups claim, ensure that the platform is configured with a Groups Claim name that matches your Microsoft Entra ID configuration. This allows the platform to correctly identify and associate groups for users logging in through Microsoft Entra ID.

   Note

   Groups coming from Microsoft Entra ID use unique IDs instead of group names. When creating group maps for a Microsoft Entra ID authenticator you must use the unique IDs.

   By default, Microsoft Entra ID uses groups as the default group claim name. So, be sure to either set the value to the default or to any custom override you have set in your IdP. The current default is set to preserve the existing behavior unless explicitly changed.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select Google OAuth from the Authentication type list and click Next.
4. Enter a Name for this authentication setting.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. 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.

7. Copy and paste Google’s Client ID into the Google OAuth2 Key field.
8. Copy and paste Google’s Client secret into the Google OAuth2 Secret field.

9. 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

10. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

    Note

    Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

11. To automatically create organizations, users, and teams upon successful login, select Create objects.
12. To enable this authentication method upon creation, select Enabled.

13. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.

    Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select Generic OIDC from the Authentication type list and click Next.
4. Enter a Name for this authentication configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. 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.
7. Optional: Select the HTTP method to be used when requesting an access token from the Access Token Method list. The default method is POST.

8. 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
9. Use the Verify OIDC Provider Certificate to enable or disable the OIDC provider SSL certificate verification.
10. 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.

11. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

    Note

    Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

12. To automatically create organizations, users, and teams upon successful login, select Create objects.
13. To enable this authentication method upon creation, select Enabled.
14. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
15. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select Keycloak from the Authentication type list and click Next.
4. 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.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.
6. Enter the location where the user’s token can be retrieved in the Keycloak Access Token URL field.
7. Optional: Enter the redirect location the user is taken to during the login flow in the Keycloak Provider URL field.
8. Enter the Client ID from your Keycloak installation in the Keycloak OIDC Key field.
9. Enter the RS256 public key provided by your Keycloak realm in the Keycloak Public Key field.
10. Enter the OIDC secret (Client Secret) from your Keycloak installation in the Keycloak OIDC Secret field.

11. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

    Note

    Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

12. To automatically create organizations, users, and teams upon successful login, select Create objects.
13. To enable this authentication method upon creation, select Enabled.
14. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
15. Click Next.

1. From the navigation for your Keycloak configuration, select Client scopes YOUR-CLIENT-ID-dedicated Add mapper Audience.
2. Pick a name for the mapper.
3. Select the Client ID corresponding to your client in Included Client Audience.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select GitHub from the Authentication type list and click Next.
4. Enter a Name for this authentication configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. When the application is registered, GitHub displays the Client ID and Client Secret:

   1. Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
   2. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.

7. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

   Note

   Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

8. To automatically create organizations, users, and teams upon successful login, select Create objects.
9. To enable this authentication method upon creation, select Enabled.
10. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
11. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select GitHub organization from the Authentication type list and click Next.
4. Enter a Name for this authentication configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. When the application is registered, GitHub displays the Client ID and Client Secret:

   1. Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
   2. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
7. 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.

8. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

   Note

   Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

9. Enter the authorization scope for users in the GitHub OAuth2 Scope field. The default is read:org.
10. To automatically create organizations, users, and teams upon successful login, select Create objects.
11. To enable this authentication method upon creation, select Enabled.
12. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
13. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select GitHub team from the Authentication type list and click Next.
4. Enter a Name for this authentication configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. When the application is registered, GitHub displays the Client ID and Client Secret:

   1. Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
   2. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
7. Copy and paste GitHub’s team ID in the GitHub OAuth2 Team ID field.
8. Enter the authorization scope for users in the GitHub OAuth2 Scope field. The default is read:org.

9. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

   Note

   Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

10. To automatically create organizations, users, and teams upon successful login, select Create objects.
11. To enable this authentication method upon creation, select Enabled.
12. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
13. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select GitHub enterprise from the Authentication type list and click Next.
4. Enter a Name for this authentication configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. When the application is registered, GitHub displays the Client ID and Client Secret:

   1. Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
   2. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
7. In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example, https://github.example.com.
8. 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.

9. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

   Note

   Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

10. To automatically create organizations, users, and teams upon successful login, select Create objects.
11. To enable this authentication method upon creation, select Enabled.
12. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
13. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select GitHub enterprise organization from the Authentication type list and click Next.
4. Enter a Name for this authentication configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. When the application is registered, GitHub displays the Client ID and Client Secret:

   1. Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
   2. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
7. In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example, https://github.example.com.
8. 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.
9. 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.

10. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

    Note

    Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

11. To automatically create organizations, users, and teams upon successful login, select Create objects.
12. To enable this authentication method upon creation, select Enabled.
13. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
14. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select GitHub enterprise team from the Authentication type list and click Next.
4. Enter a Name for this authentication configuration.
5. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.

6. When the application is registered, GitHub displays the Client ID and Client Secret:

   1. Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field.
   2. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field.
7. In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example, https://github.orgexample.com.
8. 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.
9. Enter the OAuth2 key (Client ID) from your GitHub developer application in the GitHub OAuth2 team ID field.

10. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

    Note

    Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

11. To automatically create organizations, users, and teams upon successful login, select Create objects.
12. To enable this authentication method upon creation, select Enabled.
13. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
14. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. Click Create authentication.
3. Select Radius from the Authentication type list and click Next.
4. Click Create authentication.
5. Enter a Name for this Radius configuration.
6. Select a legacy authenticator method from the Auto migrate users from list. After upgrading from 2.4 to 2.5, this is the legacy authenticator from which to automatically migrate users to this new authentication configuration. Refer to Ansible Automation Platform post-upgrade steps in the RPM upgrade and migration guide for important information about migrating users.
7. Enter the host or IP of the RADIUS server in the RADIUS Server field. If you leave this field blank, RADIUS authentication is disabled.
8. Enter the Shared secret for authenticating to RADIUS server.

9. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator.

   Note

   Values defined in this field override the dedicated fields provided in the UI. Any values not defined here are not provided to the authenticator.

10. To automatically create organizations, users, and teams upon successful login, select Create objects.
11. To enable this authentication method upon creation, select Enabled.
12. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
13. Click Next.

1. Allow rule set to never
2. Allow rule based on group
3. Superuser rule based on user attributes
4. Team admin rule based on user group

1. The Organization title of the page indicates that you are configuring settings permissions on an organization.
2. Network Organization is entered in this field and is the unique, descriptive name for this map configuration.
3. Attributes is selected from the Trigger list to configure authentication based on an attribute from the source system, which in this example is Organization.
4. The operation is defined as or meaning that at least one condition must be true for authentication to succeed.
5. The Attribute coming from the source system is Organization.
6. The Comparison value is set to matches which means that when a user has the attribute Value of Networking, they are added to the Networking organization.
7. The attribute Value coming from the source system is Networking.
8. The name of the Organization to which you are adding members is Networking.
9. Users are added to the Networking organization with the Organization Member role.

Procedure

1. After configuring the authentication details for your authentication method, select Allow from the Add authentication mapping list.
2. Enter a unique rule Name to identify the rule.
3. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
4. Select Revoke to deny user access to the system when the trigger conditions are not matched.
5. Click Next.

Procedure

1. After configuring the authentication details for your authentication type, select Organization from the Add authentication mapping list.
2. Enter a unique rule Name to identify the rule.
3. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
4. Select Revoke to remove the user’s access to the selected organization role when the trigger conditions are not matched.
5. Select the Organization to which matching users are added or blocked.
6. Select a Role to be applied or removed for matching users (for example, Organization Admin or Organization Member).
7. Click Next.

Procedure

1. After configuring the authentication details for your authentication type, select Team from the Add authentication mapping list.
2. Enter a unique rule Name to identify the rule.
3. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
4. Select Revoke to remove the user’s access to the selected organization role and deny user access to the system when the trigger conditions are not matched.
5. Select the Team and Organization to which matching users are added or blocked.
6. Select a Role to be applied or removed for matching users (for example, Team Admin or Team Member).
7. Click Next.

Procedure

1. After configuring the authentication details for your authentication type, select Role from the Add authentication mapping list.
2. Enter a unique rule Name to identify the rule.
3. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
4. Select Revoke to remove the role for the user when none of the trigger conditions are matched.
5. Select a Role to be applied or removed for matching users.
6. Click Next.

Procedure

1. After configuring the authentication details for your authentication type, select Superuser from the Add authentication mapping list.
2. Enter a unique rule Name to identify the rule.
3. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers.
4. Select Revoke to remove the superuser role from the user when none of the trigger conditions are matched.
5. Click Next.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.

   The Authentication Methods page is displayed.

2. Click Create authentication and follow the steps for creating an authentication method in Configuring an authentication type. Otherwise, proceed to step 3.
3. 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.
4. Click the toggles to Enable or Disable authenticators.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. In the search bar, enter an appropriate keyword for the authentication method you want to search for and click the arrow icon.
3. 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.
4. Scroll through the list of search results and select the authenticator you want to review.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.

2. In the list view, select the authenticator name displayed in the Name column.

   The authenticator Details page is displayed.

3. From the Details page, you can review the configuration settings applied to the authenticator.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.

2. In the list view, you can either:

   1. Select the Edit icon next to authenticator you want to modify, or
   2. Select the authenticator name displayed in the Name column and click Edit authenticator from the Details page.
3. Modify the authentication details or mapping configurations as required.
4. Click Save.

Procedure

1. From the navigation panel, select Access Management Authentication Methods.
2. In the list view, select the checkbox next to the authenticator you want to delete.

3. Select Delete authentication from the ⋮ list.

   Note

   You 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.