Search

Chapter 3. Configuring authentication in the Ansible Automation Platform

download PDF

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:

  1. Authentication type, where you select the type of authenticator plugin you want to configure.
  2. Authentication details, where you configure the authentication details for the plugin you selected.
  3. Mapping, where you define mapping rule types and triggers to control access to the system.
  4. Mapping order, where you can define the mapping precedence.

    Note

    Mapping order is only available if you have defined one or more authenticator maps.

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

  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.

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

  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.

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

  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:

  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.

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

  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.

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

  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.

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.

Note

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

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

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

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

  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. 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.
  6. 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
  7. In the LDAP Bind Password text field, enter the password to use for the binding user.
  8. Select a group type from the LDAP Group Type list.

    Note

    The LDAP group types that are supported by the Ansible Automation Platform use the underlying django-auth-ldap library.

  9. 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.
  10. LDAP Start TLS is disabled by default. To enable TLS when the LDAP connection is not using SSL, set the switch to On.
  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.

  12. Enter any LDAP Connection Options to set for the LDAP connection.
  13. 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.

  14. In the LDAP Group Search field, specify which groups should be searched and how to search them.
  15. 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.
  16. In the LDAP User Search field, enter where to search for users during authentication.
  17. To automatically create organizations, users, and teams upon successful login, select Create objects.
  18. To enable this authentication method upon creation, select Enabled.
  19. To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users.
  20. Click Next.

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

  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. 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.
  6. Include the certificate content in the SAML Service Provider Public Certificate field.
  7. Include the private key content in the SAML Service Provider Private Key.
  8. Enter the URL to redirect the user to for login initiation in the IdP Login URL field.
  9. Enter the public cert used for secrets coming from the IdP in the IdP Public Cert field.
  10. 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.
  11. The SAML Assertion Consumer Service (ACS) URL field registers the service as a service provider (SP) with each identity provider (IdP) you have configured.
  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.

  13. 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"
      }
    }
  14. 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"
    }
  15. 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"
    }
  16. 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.
  17. 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.

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

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.

Note

This feature is deprecated and will be removed in a future release.

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

  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.

    Click Next.

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

  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. Click Edit, copy and paste Microsoft’s Application (Client) ID to the OIDC Key field.

    Following instructions for registering your application with the Microsoft identity platform, supply the key (shown at one time only) to the client for authentication.

  6. Copy and paste the secret key created for your Microsoft Azure AD application to the OIDC 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.

  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.

    Click Next.

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

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

  6. Copy and paste Google’s Client ID into the Google OAuth2 Key field.
  7. Copy and paste Google’s Client secret into the Google OAuth2 Secret field.
  8. 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
  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.

  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.

    Click Next.

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

  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. 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.
  6. Optional: Select the HTTP method to be used when requesting an access token from the Access Token Method list. The default method is POST.
  7. 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
  8. Use the Verify OIDC Provider Certificate to enable or disable the OIDC provider SSL certificate verification.
  9. 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.
  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.

  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.

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

  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. Enter the location where the user’s token can be retrieved in the Keycloak Access Token URL field.
  6. Optional: Enter the redirect location the user is taken to during the login flow in the Keycloak Provider URL field.
  7. Enter the Client ID from your Keycloak installation in the Keycloak OIDC Key field.
  8. Enter the RS256 public key provided by your Keycloak realm in the Keycloak Public Key field.
  9. Enter the OIDC secret (Client Secret) from your Keycloak installation in the Keycloak OIDC Secret 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.

  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.

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

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

  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.

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

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

  8. Enter the authorization scope for users in the GitHub OAuth2 Scope field. The default is read:org.
  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.
  12. Click Next.

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

  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. 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.
  6. Copy and paste GitHub’s team ID in the GitHub OAuth2 Team ID field.
  7. Enter the authorization scope for users in the GitHub OAuth2 Scope field. The default is read:org.
  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.

  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.
  12. Click Next.

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

  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. 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.
  6. In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example, https://github.example.com.
  7. 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.
  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.

  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.
  12. Click Next.

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

  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. 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.
  6. In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example, https://github.example.com.
  7. 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.
  8. 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.
  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.

  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.

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

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

  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.

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

  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 the host or IP of the RADIUS server in the RADIUS Server field. If you leave this field blank, RADIUS authentication is disabled.
  6. Enter the Shared secret for authenticating to RADIUS server.
  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.

  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.

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.

    Note

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

    Note

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

      Note

      If 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 or cn=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

  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 none of the trigger conditions are matched.
  5. Click Next.

Next steps

  1. You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.

    Note

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

  2. Click Next to review and verify the mapping configurations.
  3. Click Finish.

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

  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 deny user access to the system when none of the trigger conditions are 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.

Next steps

  1. You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.

    Note

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

  2. Click Next to review and verify the mapping configurations.
  3. Click Finish.

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

  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 deny user access to the system when none of the trigger conditions are 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.

Next steps

  1. You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.

    Note

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

  2. Click Next to review and verify the mapping configurations.
  3. Click Finish.

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

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

Next steps

  1. You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.

    Note

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

  2. Click Next to review and verify the mapping configurations.
  3. Click Finish.

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

  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 superuser role from the user when none of the trigger conditions are matched.
  5. Click Next.

Next steps

  1. You can manage the authentication mappings order by dragging and dropping the mapping up or down in the list.

    Note

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

  2. Click Next to review and verify the mapping configurations.
  3. Click Finish.

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

  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.

3.6.2. Searching for an authenticator

You can search for a previously configured authenticator from the Authentication list view.

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.

3.6.3. Displaying authenticator details

After you locate the authenticator you want to review, you can display the configuration details:

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.

3.6.4. Editing an authenticator

You can modify the settings of previously configured authenticators from the Authentication list view.

Procedure

  1. From the navigation panel, select Access Management Authentication Methods.
  2. In the list view, you can either:

    1. Select the Edit 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.

3.6.5. Deleting an authenticator

You can modify the settings of previously configured authenticators from the Authentication list view.

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.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.