Chapter 3. Configuring authentication in the Ansible Automation Platform
Chapter 3. Configuring authentication in the Ansible Automation Platform Using the authentication settings in Ansible Automation Platform, you can set up a simplified login through several authentication methods, such as LDAP and SAML. Depending on the authentication method you select, you will be required to enter different information to complete the configuration. Be sure to include all the information required for your configuration needs. 3.1. Prerequisites A running installation of Ansible Automation Platform 2.5 A running instance of your authentication source Administrator rights to the Ansible Automation Platform Any connection information needed to connect Ansible Automation Platform 2.5 to your source (see individual authentication types for details). 3.2. Pluggable authentication Authentication is the process of verifying a user's identity to the Ansible Automation Platform (that is, to establish that a user is who they say they are). This can be done in a number of ways but would traditionally be associated with a username and password . Ansible Automation Platform 2.5 uses a pluggable authentication system with a configuration wizard that provides a common, simplified method of configuring different types of authenticators such as LDAP and SAML. The pluggable system also allows you to configure multiple authenticators of the same type. In the pluggable system we have a couple of concepts: Authenticator Plugin A plugin allows Ansible Automation Platform to connect to a source system, such as, LDAP or SAML. Ansible Automation Platform includes a variety of authenticator plugins. Authenticator plugins are similar to Ansible collections, in that all of the required code is in a package and can be versioned independently if needed. Authenticator An authenticator is an instantiation of an authenticator plugin and allows users from the specified source to log in. For example, the LDAP authenticator plugin defines a required LDAP server setting. When you instantiate an authenticator from the LDAP authentication plugin, you must provide the authenticator the LDAP server URL it needs to connect to. Authenticator Map Authenticator maps are applied to authenticators and tell Ansible Automation Platform what permissions to give a user logging into the system. 3.3. Creating an authentication method The Create Authentication wizard guides you through the steps to create a new authentication method for your organization. The wizard is launched during the create authentication process. Creating an authenticator involves the following procedures: Authentication type , where you select the type of authenticator plugin you want to configure. Authentication details , where you configure the authentication details for the plugin you selected. Mapping , where you define mapping rule types and triggers to control access to the system. Mapping order , where you can define the mapping precedence. Note Mapping order is only available if you have defined one or more authenticator maps. Review , where you can review and confirm the authentication settings before creating the authentication method. 3.3.1. Selecting an authentication type On the first screen of the wizard you can select the type of authenticator plugin you want to configure. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . The Create Authentication wizard is displayed, where you can follow the prompts to configure your preferred authentication method. Select the authenticator type from the Authentication type list. See Configuring an authentication type for the complete list of authentication plugins available. Click 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 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. 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. Enable or disable Enabled to specify if the authenticator should be enabled or disabled. If enabled, users are able to login from the authenticator. If disabled, users will not be allowed to login from the authenticator. Enable or disable Create Object to specify whether the authenticator should create teams and organizations in the system when a user logs in. Enabled Teams and organizations defined in the authenticator maps are created and the users added to them. Disabled Organizations and teams defined in the authenticator maps will not be created automatically in the system. However, if they already exist (i.e. created by a superuser), users who trigger the maps are granted access to them. Enable or disable Remove Users . If enabled, any access previously granted to a user is removed when they authenticate from this source. If disabled, permissions are only added or removed from the user based on the results of this authenticator's authenticator mappings. For example, assume a user has been granted the is_superuser permission in the system. And that user will log into an authenticator whose maps will not formulate an opinion as to whether or not the user should be a superuser. If Remove Users is enabled, 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. Click 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 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 Enter a unique rule Name to identify the rule. Select a Trigger from the list. See Authenticator map triggers for more details. Choices include: Always Never Group Attribute Repeat steps 1-3 to add additional triggers to the authenticator. Click 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 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. After your authenticator maps are in the correct order, click 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 Review and verify the authentication settings. 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: Local LDAP SAML TACACS+ Radius Azure Google OAuth Generic OIDC Keycloak GitHub GitHub organization GitHub team GitHub enterprise GitHub enterprise organization GitHub enterprise team 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 From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select Local from the Authentication type list and click . Enter a Name for this Local configuration. The configuration name is required, must be unique across all authenticators, and must not be longer than 512 characters. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . 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. Note If the LDAP server you want to connect to has a certificate that is self-signed or signed by a corporate internal certificate authority (CA), the CA certificate must be added to the system's trusted CAs. Otherwise, connection to the LDAP server will result in an error that the certificate issuer is not recognized. 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 time the user logs in to the platform. Important Migration of LDAP authentication settings are not supported for 2.4 to 2.5 in the platform UI. If you are upgrading from Ansible Automation Platform 2.4 to 2.5, be sure to save your authentication provider data before upgrading. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select LDAP from the Authentication type list and click . Enter a Name for this LDAP configuration. The configuration name is required, must be unique across all authenticators, and must not be longer than 512 characters. In the LDAP Server URI field, enter or modify the list of LDAP servers to which you want to connect. This field supports multiple addresses. In the LDAP Bind DN text field, enter the Distinguished Name (DN) to specify the user that the Ansible Automation Platform uses to connect to the LDAP server. For example: CN=josie,CN=users,DC=website,DC=com In the LDAP Bind Password text field, enter the password to use for the binding user. Select a group type from the LDAP Group Type list. The LDAP Group Type list includes the following groups: PosixGroupType GroupOfNamesType GroupOfUniqueNamesType ActiveDirectoryGroupType OrganizationalRoleGroupType MemberDNGroupType NISGroupType NestedGroupOfNamesType NestedGroupOfUniqueNamesType NestedActiveDirectoryGroupType NestedOrganizationalRoleGroupType NestedMemberDNGroupType PosixUIDGroupType 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 13 of this procedure. To use LDAP User DN Template as an alternative to user search, enter the name of the template. This approach is more efficient for user lookups than searching if it is usable in your organizational environment. If this setting has a value it will be used instead of the LDAP User Search setting. LDAP Start TLS is disabled by default. To enable TLS when the LDAP connection is not using SSL, set the switch to On . Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. Enter any LDAP Connection Options to set for the LDAP connection. 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. In the LDAP Group Search field, specify which groups should be searched and how to search them. In the LDAP User Attribute Map field, enter user attributes to map LDAP fields to your Ansible Automation Platform users, for example, email or first_name . In the LDAP User Search field, enter where to search for users during authentication. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . 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 you can configure to talk with one or more SAML IdPs to authenticate users. Based on groups and attributes optionally provided by the SAML IdP, users can be placed into teams and organizations in Ansible Automation Platform based on the authenticator maps tied to this authenticator. This mapping ensures that when a user logs in through SAML, Ansible Automation Platform can correctly identify the user and assign the proper attributes like first name, last name, email, and group membership. Prerequisites Before you configure SAML authentication in Ansible Automation Platform, be sure you do the following: Configure a SAML Identity Provider (IdP). Pre-configure the SAML IdP with the settings required for integration with Ansible Automation Platform. For example, in Microsoft Entra ID you can configure the following: Identifier (Entity ID): This can be any value that you want, but it needs to match the one configured in your Ansible Automation Platform. Reply URL (Assertion Consumer Service (ACS) URL): This URL is auto generated when the SAML method is configured in Ansible Automation Platform. That value must be copied from Ansible Automation Platform and pasted in your IdP settings. Gather the user attributes for your SAML IdP application. Different IdPs might use different attribute names and formats. Refer to documentation for your specific IdP for the exact attribute names and the expected values. Generate a private key and public certificate using the following command: USD openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select SAML from the Authentication type list and click . Enter a Name for this SAML configuration. Enter the application-defined unique identifier used as the audience of the SAML service provider configuration in the SAML Service Provider Entity ID field. This is usually the base URL of your service provider, but the actual value depends on the Entity ID expected by your IdP. 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-- . 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-- . 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. 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. 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. Enter user details in the Groups , User Email , Username , User Last Name and User First Name . 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. 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. 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. In the SAML Service Provider Organization Info field, provide the URL, display name, and the name of your app. { "en-US": { "url": "http://www.example.com", "displayname": "Example", "name": "example" } } In the SAML Service Provider Technical Contact field, give the name and email address of the technical contact for your service provider. { "givenName": "Some User", "emailAddress": "suser@example.com" } In the SAML Service Provider Support Contact field, give the name and email address of the support contact for your service provider. { "givenName": "Some User", "emailAddress": "suser@example.com" } Optional: Provide extra configuration data in the SAML Service Provider extra configuration data field. 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. 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 . 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. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . Important You can configure an HTTPS redirect for SAML in operator-based deployments to simplify login for your users. For the steps to configure this setting, see Enabling single sign-on (SSO) for platform gateway on OpenShift Container Platform . 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.1. Configuring transparent SAML logins For transparent logins to work, you must first get IdP-initiated logins to work. Procedure Set the RelayState on the IdP to "IdP". 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 From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select TACACS+ from the Authentication type list and click . Enter a Name for this TACACS+ configuration. Enter the following information: Hostname of TACACS+ Server: Provide the hostname or IP address of the TACACS+ server with which to authenticate. If you leave this field blank, TACACS+ authentication is disabled. TACACS+ Authentication Protocol: The protocol used by the TACACS+ client. The options are ascii or pap. Shared secret for authenticating to TACACS+ server: The secret key for TACACS+ authentication server. The TACACS+ client address sending enabled is disabled by default. To enable client address sending, select the checkbox. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . 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 Entra ID authentication To set up enterprise authentication for Microsoft Entra ID, formerly known as 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 Displaying authenticator details for instructions on accessing this information. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select Azuread from the Authentication type list and click . Enter a Name for this authentication configuration. 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. Copy and paste the secret key created for your Microsoft Entra ID/Microsoft Azure AD application to the OIDC Secret field. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . Verification To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials. 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 Entra ID/Microsoft Azure AD, see the What is the Microsoft identity platform? overview. 3.4.6. Configuring Google OAuth2 authentication To set up social authentication for Google, you must obtain an OAuth2 key and secret for a web application. To do this, you must first create a project and set it up with Google. For instructions, see Setting up OAuth 2.0 in the Google API Console Help documentation. If you have already completed the setup process, you can access those credentials by going to the Credentials section of the Google API Manager Console . The OAuth2 key (Client ID) and secret (Client secret) are used to supply the required fields in the UI. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select Google OAuth from the Authentication type list and click . Enter a Name for this authentication setting. The Google OAuth2 Key and Google OAuth2 Secret fields are pre-populated. If not, use the credentials Google supplied during the web application setup process. Save these settings for use in the following steps. Copy and paste Google's Client ID into the Google OAuth2 Key field. Copy and paste Google's Client secret into the Google OAuth2 Secret field. Optional: Enter information for the following fields using the tooltips provided for instructions and required format: Access Token URL Access Token Method Authorization URL Revoke Token Method Revoke Token URL OIDC JWT Algorithm(s) OIDC JWT Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . Verification To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials. steps To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping . 3.4.7. Configuring generic OIDC authentication OpenID Connect (OIDC) uses the OAuth 2.0 framework. It enables third-party applications to verify the identity and obtain basic end-user information. The main difference between OIDC and SAML is that SAML has a service provider (SP)-to-IdP trust relationship, whereas OIDC establishes the trust with the channel (HTTPS) that is used to obtain the security token. To obtain the credentials needed to set up OIDC with Ansible Automation Platform, see the documentation from the IdP of your choice that has OIDC support. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select Generic OIDC from the Authentication type list and click . Enter a Name for this authentication configuration. Enter the following information: OIDC Provider URL : The URL for your OIDC provider. OIDC Key : The client ID from your third-party IdP. OIDC Secret : The client secret from your IdP. Optional: Select the HTTP method to be used when requesting an access token from the Access Token Method list. The default method is POST . Optionally enter information for the following fields using the tooltips provided for instructions and required format: Access Token Method - The default method is POST . Access Token URL Access Token Method Authorization URL ID Key ID Token Issuer JWKS URI OIDC Public Key Revoke Token Method - The default method is GET . Revoke Token URL Response Type Token Endpoint Auth Method Userinfo URL Username Key Use the Verify OIDC Provider Certificate to enable or disable the OIDC provider SSL certificate verification. Use the Redirect State to enable or disable the state parameter in the redirect URI. It is recommended that this is enabled to prevent Cross Site Request Forgery (CSRF) attacks. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . 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. Note When using this authenticator some specific setup in your Keycloak instance is required. Refer to the Python Keycloak reference for more details. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select Keycloak from the Authentication type list and click . Enter a Name for this keycloak configuration. The configuration name is required, must be unique across all authenticators, and must not be longer than 512 characters. Enter the location where the user's token can be retrieved in the Keycloak Access Token URL field. Optional: Enter the redirect location the user is taken to during the login flow in the Keycloak Provider URL field. Enter the Client ID from your Keycloak installation in the Keycloak OIDC Key field. Enter the RS256 public key provided by your Keycloak realm in the Keycloak Public Key field. Enter the OIDC secret (Client Secret) from your Keycloak installation in the Keycloak OIDC Secret field. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . 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 . Troubleshooting If you receive an jwt.exceptions.InvalidAudienceError: Audience doesn't match error, you must re-enable the audience by doing the following: From the navigation for your Keycloak configuration, select Client scopes YOUR-CLIENT-ID-dedicated Add mapper Audience . Pick a name for the mapper. Select the Client ID corresponding to your client in Included Client Audience . 3.4.9. Configuring GitHub authentication You can connect GitHub identities to Ansible Automation Platform using OAuth. To set up GitHub authentication, you need to obtain an OAuth2 key and secret by registering your organization-owned application from GitHub using the registering the new application with GitHub . The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select GitHub from the Authentication type list and click . Enter a Name for this authentication configuration. When the application is registered, GitHub displays the Client ID and Client Secret : Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . Verification To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials. steps To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping . 3.4.10. Configuring GitHub organization authentication When defining account authentication with either an organization or a team within an organization, you should use the specific organization and team settings. Account authentication can be limited by an organization and by a team within an organization. You can also choose to permit all by specifying non-organization or non-team based settings. You can limit users who can log in to the platform by limiting only those in an organization or on a team within an organization. To set up social authentication for a GitHub organization, you must obtain an OAuth2 key and secret for a web application using the registering the new application with GitHub . The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select GitHub organization from the Authentication type list and click . Enter a Name for this authentication configuration. When the application is registered, GitHub displays the Client ID and Client Secret : Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field. Enter the name of your GitHub organization, as used in your organization's URL, for example, https://github.com/<yourorg>/ in the GitHub OAuth Organization Name field. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. Enter the authorization scope for users in the GitHub OAuth2 Scope field. The default is read:org . To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . Verification To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials. steps To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping . 3.4.11. Configuring GitHub team authentication To set up social authentication for a GitHub team, you must obtain an OAuth2 key and secret for a web application using the instructions provided in registering the new application with GitHub . The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information. Each key and secret must belong to a unique application and cannot be shared or reused between different authentication backends. The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select GitHub team from the Authentication type list and click . Enter a Name for this authentication configuration. When the application is registered, GitHub displays the Client ID and Client Secret : Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field. Copy and paste GitHub's team ID in the GitHub OAuth2 Team ID field. Enter the authorization scope for users in the GitHub OAuth2 Scope field. The default is read:org . Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . Verification To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials. steps To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping . 3.4.12. Configuring GitHub enterprise authentication To set up social authentication for a GitHub enterprise, you must obtain a GitHub Enterprise URL, an API URL, OAuth2 key and secret for a web application. To obtain the URLs, refer to the GitHub Enterprise administration documentation . The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information. Each key and secret must belong to a unique application and cannot be shared or reused between different authentication backends. The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select GitHub enterprise from the Authentication type list and click . Enter a Name for this authentication configuration. When the application is registered, GitHub displays the Client ID and Client Secret : Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field. In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example, https://github.example.com . In the Github OAuth2 Enterprise API URL field, enter the API URL of the GitHub Enterprise instance, for example, https://github.example.com/api/v3 . Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . Verification To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials. steps To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping . 3.4.13. GitHub Enterprise Organization settings To set up social authentication for a GitHub Enterprise Organization, you must obtain a GitHub Enterprise Organization URL, an Organization API URL, an Organization OAuth2 key and secret for a web application. To obtain the URLs, refer to the GitHub Enterprise administration documentation . The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information. Each key and secret must belong to a unique application and cannot be shared or reused between different authentication backends. The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select GitHub enterprise organization from the Authentication type list and click . Enter a Name for this authentication configuration. When the application is registered, GitHub displays the Client ID and Client Secret : Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field. In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example, https://github.example.com . In the Github OAuth2 Enterprise API URL field, enter the API URL of the GitHub Enterprise instance, for example, https://github.example.com/api/v3 . Enter the name of your GitHub Enterprise organization, as used in your organization's URL, for example, https://github.com/<yourorg>/ in the GitHub OAuth2 Enterprise Org Name field. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . Verification To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials. steps To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping . 3.4.14. Configuring GitHub enterprise team authentication To set up social authentication for a GitHub enterprise team, you must obtain a GitHub Enterprise Organization URL, an Organization API URL, an Organization OAuth2 key and secret for a web application. To obtain the URLs, refer to the GitHub Enterprise administration documentation . To obtain the key and secret, you must first register your enterprise organization-owned application at https://github.com/organizations/<yourorg>/settings/applications . The OAuth2 key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. To register the application, you must supply it with your webpage URL, which is the Callback URL shown in the Authenticator details for your authenticator configuration. See Displaying authenticator details for instructions on accessing this information. Each key and secret must belong to a unique application and cannot be shared or reused between different authentication backends. The OAuth2key (Client ID) and secret (Client Secret) are used to supply the required fields in the UI. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select GitHub enterprise team from the Authentication type list and click . Enter a Name for this authentication configuration. When the application is registered, GitHub displays the Client ID and Client Secret : Copy and paste the GitHub Client ID into the GitHub OAuth2 Key field. Copy and paste the GitHub Client Secret into the GitHub OAuth2 Secret field. In the Base URL field, enter the hostname of the GitHub Enterprise instance, for example, https://github.orgexample.com . In the Github OAuth2 Enterprise API URL field, enter the API URL of the GitHub Enterprise instance, for example, https://github.example.com/api/v3 . Enter the OAuth2 key (Client ID) from your GitHub developer application in the GitHub OAuth2 team ID field. Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . Verification To verify that the authentication is configured correctly, log out of Ansible Automation Platform and check that the login screen displays the logo of your authentication chosen method to enable logging in with those credentials. steps To control which users are allowed into the Ansible Automation Platform server, and placed into Ansible Automation Platform organizations or teams based on their attributes (like username and email address) or to what groups they belong, continue to Mapping . 3.4.15. Configuring RADIUS authentication You can configure Ansible Automation Platform to centrally use RADIUS as a source for authentication information. Procedure From the navigation panel, select Access Management Authentication Methods . Click Create authentication . Select Radius from the Authentication type list and click . Click Create authentication . Enter the host or IP of the RADIUS server in the RADIUS Server field. If you leave this field blank, RADIUS authentication is disabled. Enter the Shared secret for authenticating to RADIUS server . Optional: Enter any Additional Authenticator Fields that this authenticator can take. These fields are not validated and are passed directly back to the authenticator. Note Values defined in this field override the dedicated fields provided in the UI. To automatically create organizations, users, and teams upon successful login, select Create objects . To enable this authentication method upon creation, select Enabled . To remove a user for any groups they were previously added to when they authenticate from this source, select Remove users . Click . 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. Note Group identifiers are case-sensitive and must match the authenticator backend. For example, cn=johnsmith,dc=example,dc=com instead of CN=johnsmith,DC=example,DC=com . 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 example for "Never allow access to the system if the user has an attribute called disabled with a value of True , Yes or Until Further Notice . You can add another rule with a higher order, such as, "Allow access to the system for a disabled user if they are in the group Emergency Contacts ." The first rule prevents the disabled user from accessing the system, but the second rule alters that decision to grant access to the system for the disabled user if they are in the Emergency Contacts group. 3.5.4. Allow mapping With allow mapping, you can control which users have access to the system by defining the conditions that must be met. Procedure After configuring the authentication details for your authentication method, select Allow from the Add authentication mapping list. Enter a unique rule Name to identify the rule. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers. Select Revoke to deny user access to the system when none of the trigger conditions are matched. Click . steps 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. Click to review and verify the mapping configurations. 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 After configuring the authentication details for your authentication type, select Organization from the Add authentication mapping list. Enter a unique rule Name to identify the rule. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers. Select Revoke to deny user access to the system when none of the trigger conditions are matched. Select the Organization to which matching users are added or blocked. Select a Role to be applied or removed for matching users (for example, Organization Admin or Organization Member ). Click . steps 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. Click to review and verify the mapping configurations. 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 After configuring the authentication details for your authentication type, select Team from the Add authentication mapping list. Enter a unique rule Name to identify the rule. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers. Select Revoke to deny user access to the system when none of the trigger conditions are matched. Select the Team and Organization to which matching users are added or blocked. Select a Role to be applied or removed for matching users (for example, Team Admin or Team Member ). Click . steps 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. Click to review and verify the mapping configurations. 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 After configuring the authentication details for your authentication type, select Role from the Add authentication mapping list. Enter a unique rule Name to identify the rule. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers. Select Revoke to remove the role for the user when none of the trigger conditions are matched. Select a Role to be applied or removed for matching users. Click . steps 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. Click to review and verify the mapping configurations. Click Finish . 3.5.8. Superuser mapping Superuser mapping is the mapping of a user to the superuser role, such as System Administrator. Procedure After configuring the authentication details for your authentication type, select Superuser from the Add authentication mapping list. Enter a unique rule Name to identify the rule. Select a Trigger from the list. See Authenticator map triggers for more information about map triggers. Select Revoke to remove the superuser role from the user when none of the trigger conditions are matched. Click . steps 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. Click to review and verify the mapping configurations. 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 From the navigation panel, select Access Management Authentication Methods . The Authentication Methods page is displayed. Click Create authentication and follow the steps for creating an authentication method in Configuring an authentication type . Otherwise, proceed to step 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 . Click the toggles to Enable or Disable authenticators. 3.6.2. Searching for an authenticator You can search for a previously configured authenticator from the Authentication list view. Procedure From the navigation panel, select Access Management Authentication Methods . In the search bar, enter an appropriate keyword for the authentication method you want to search for and click the arrow icon. If you don't find what you're looking for, you can narrow your search. From the filter list, select Name or Authentication type depending on the search term you want to use. Scroll through the list of search results and select the authenticator you want to review. 3.6.3. Displaying authenticator details After you locate the authenticator you want to review, you can display the configuration details: Procedure From the navigation panel, select Access Management Authentication Methods . In the list view, select the authenticator name displayed in the Name column. The authenticator Details page is displayed. From the Details page, you can review the configuration settings applied to the authenticator. 3.6.4. Editing an authenticator You can modify the settings of previously configured authenticators from the Authentication list view. Procedure From the navigation panel, select Access Management Authentication Methods . In the list view, you can either: Select the Edit icon to authenticator you want to modify, or Select the authenticator name displayed in the Name column and click Edit authenticator from the Details page. Modify the authentication details or mapping configurations as required. Click Save . 3.6.5. Deleting an authenticator You can modify the settings of previously configured authenticators from the Authentication list view. Procedure From the navigation panel, select Access Management Authentication Methods . In the list view, select the checkbox to the authenticator you want to delete. Select Delete authentication from the ... list. Note You can delete multiple authenticators by selecting the checkbox to each authenticator you want to remove, and clicking Delete selected authentication from the ... list on the menu bar.
CN=josie,CN=users,DC=website,DC=com {"name_attr": "cn", "member_attr": "member"} openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes GET_ALL_EXTRA_DATA: true { "en-US": { "url": "http://www.example.com", "displayname": "Example", "name": "example" } } { "givenName": "Some User", "emailAddress": "suser@example.com" } { "givenName": "Some User", "emailAddress": "suser@example.com" } { "sign_request": True, } // 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, - Department - UserType - Organization