3.5. 認証タイプの設定

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. このローカル設定の Name を入力します。設定名は必須で、すべてのオーセンティケーター間で一意である必要があり、512 文字を超えることはできません。
4. Authentication type リストから Local を選択します。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

   注記

   このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

7. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
8. 作成時にこの認証方法を有効にするには、Enabled を選択します。
9. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
10. Next をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. 認証タイプ リストから LDAP を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。
6. LDAP Server URI フィールドで、接続する LDAP サーバーのリストを入力または変更します。このフィールドは複数のアドレスをサポートします。

7. 次の例に示すように、LDAP Bind DN text フィールドに識別名 (DN) を入力して、Ansible Automation Platform が LDAP サーバーに接続するために使用するユーザーを指定します。

   Copy to Clipboard Toggle word wrap

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

8. バインディングユーザーに使用するパスワードを LDAP Bind Password テキストフィールドに入力します。

9. LDAP Group Type リストからグループタイプを選択します。

   グループタイプは、LDAP ディレクトリー内のユーザーに関連付けられたグループを管理するグループのクラス名を定義し、この手順のステップ 14 で指定された検索で返されます。グループタイプは、グループパラメーターおよびグループ検索と共に、ログイン時にグループを検索してユーザーに割り当てるために使用されます。また、マッピングプロセス中に評価することもできます。次の表には、使用可能なグループタイプと、それぞれの説明および必要なパラメーターがリストされています。デフォルトでは、LDAP グループは cn 属性の最初の値を使用して Django グループにマッピングされます。name_attr で別の属性を指定できます。たとえば、name_attr='cn' です。

   表3.1 利用可能な LDAP グループタイプ

   LDAP グループタイプ	説明	初期化メソッド (init)
   PosixGroupType	posixGroup オブジェクトクラスを処理します。これにより、プライマリーグループとグループメンバーシップの両方がチェックされます。	name_attr='cn'
   MemberDNGroupType	グループオブジェクトにメンバー DN のリストが含まれるグループ化メカニズムを処理します。	member_attr, name_attr='cn'
   GroupOfNamesType	groupOfNames オブジェクトクラスを処理します。MemberDNGroupType('member') と同等です。	name_attr='cn'
   GroupOfUniqueNamesType	groupOfUniqueNames オブジェクトクラスを処理します。MemberDNGroupType('uniqueMember') と同等です。	name_attr='cn'
   ActiveDirectoryGroupType	Active Directory グループを処理します。MemberDNGroupType('member') と同等です。	name_attr='cn'
   OrganizationalRoleGroupType	organizationalRole オブジェクトクラスを処理します。MemberDNGroupType('roleOccupant') と同等です。	name_attr='cn'
   NestedGroupOfNamesType	groupOfNames オブジェクトクラスを処理します。NestedMemberDNGroupType('member') と同等です。	member_attr, name_attr='cn'
   NestedGroupOfUniqueNamesType	groupOfUniqueNames オブジェクトクラスを処理します。NestedMemberDNGroupType('uniqueMember') と同等です。	name_attr='cn'
   NestedActiveDirectoryGroupType	Active Directory グループを処理します。NestedMemberDNGroupType('member') と同等です。	name_attr='cn'
   NestedOrganizationalRoleGroupType	organizationalRole オブジェクトクラスを処理します。NestedMemberDNGroupType('roleOccupant') と同等です。	name_attr='cn'

   注記

   Ansible Automation Platform でサポートされているグループタイプは、基盤となる django-auth-ldap ライブラリー を使用します。選択したグループタイプのパラメーターを指定するには、この手順のステップ 14 を参照してください。

10. ユーザー検索の代わりに、LDAP ユーザー DN テンプレート を使用できます。このアプローチを組織の環境で使用できる場合は、検索よりもユーザー検索の場合により効率的です。次の例に示すように、テンプレートの名前を入力します。

    Copy to Clipboard Toggle word wrap

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

    この場合の uid はユーザー識別子、cn はコモンネーム、dc はドメインコンポーネントです。

    注記

    この設定に値がある場合は、LDAP User Search 設定の代わりに使用されます。

11. LDAP Start TLS は、デフォルトで無効になっています。StartTLS を使用すると、LDAP 接続を、暗号化されていない接続から Transport Layer Security (TLS) を使用した安全な接続にアップグレードできます。LDAP 接続が SSL を使用していない場合に StartTLS を有効にするには、スイッチを On に設定します。

12. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

    注記

    このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

13. LDAP 接続に設定する LDAP Connection Options を入力します。LDAP 参照は (特定の LDAP クエリーが Active Directory でハングすることを防ぐために) デフォルトで無効になっています。次の例に示すように、オプション名は文字列である必要があります。

    Copy to Clipboard Toggle word wrap

    OPT_REFERRALS: 0
    OPT_NETWORK_TIMEOUT: 30

    設定できるオプションと値については、python-LDAP Reference を参照してください。

14. 選択した LDAP Group Type に応じて、異なるパラメーターが LDAP Group Type Parameters フィールドで使用できます。LDAP_GROUP_TYPE_PARAMS はディクショナリーです。これは、kwargs に変換され、選択した LDAP Group Type クラスに渡されます。グループタイプで使用される共通パラメーターが 2 つあります。name_attr と member_attr です。name_attr のデフォルトは cn、member_attr のデフォルトは member です。

    Copy to Clipboard Toggle word wrap

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

    特定の LDAP グループタイプ に必要なパラメーターを判断するには、django_auth_ldap ドキュメント のクラス init パラメーターに関する箇所を参照してください。

15. 次の例に示すように、LDAP Group Search フィールドで検索するグループと検索方法を指定します。

    Copy to Clipboard Toggle word wrap

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

16. 次の例に示すように、LDAP フィールドを Ansible Automation Platform ユーザーにマップするためのユーザー属性 (例: email、first_name) を LDAP User Attribute Map フィールドに入力します。

    Copy to Clipboard Toggle word wrap

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

17. 次の例に示すように、認証中にユーザーを検索する場所を LDAP User Search フィールドに入力します。

    Copy to Clipboard Toggle word wrap

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

    LDAP User DN Template が設定されていない場合、Ansible Automation Platform は、Bind DN Template と LDAP Bind Password を使用して LDAP に対して認証を行います。認証後、このフィールドで指定されたユーザーを検索する LDAP 検索が実行されます。ユーザーが見つかった場合、Ansible Automation Platform は、指定されたパスワードを LDAP 検索で見つかったユーザーと照合して検証します。LDAPUnion を使用したユーザー検索の場合、次の例に示すように、複数の検索語を入力することで複数の検索クエリーを実行できます。

    Copy to Clipboard Toggle word wrap

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

    複数の検索の実行中に一意でないユーザーが複数見つかった場合、それらのユーザーは Ansible Automation Platform にログインできません。上記の例に基づくと、ou=users,dc=example,dc=com と ou=employees,dc=subdivision,dc=com の両方で uid=jdoe を持つユーザーが見つかった場合、どちらの jdoe ユーザーもログインできません。どちらかのブランチで見つかった一意の他のユーザーは、すべて引き続きログインできます。

    注記

    LDAP User DN Template フィールドに値が入力されている場合は、LDAP User Search フィールドよりも優先され、ユーザーの認証にテンプレートのみが使用されます。

18. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
19. 作成時にこの認証方法を有効にするには、Enabled を選択します。
20. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
21. 認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この SAML 設定の Name を入力します。
4. Authentication type リストから SAML を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。
6. SAML Service Provider Entity ID フィールドに、SAML サービスプロバイダー設定の対象ユーザーとして使用されるアプリケーション定義の一意の識別子を入力します。これは通常、サービスプロバイダーのベース URL ですが、実際の値は IdP が想定する Entity ID によって異なります。
7. SAML Service Provider Public Certificate フィールドに証明書の内容を含めます。この情報は、前提条件で作成した cert.pem に含まれています。—-BEGIN CERTIFICATE—- と —-END CERTIFICATE—- を含める必要があります。
8. SAML Service Provider Private Key フィールドに秘密鍵の内容を含めます。この情報は、前提条件で作成した key.pem に含まれています。—–BEGIN PRIVATE KEY—– と —–END PRIVATE KEY—– を含める必要があります。
9. IdP Login URL フィールドに、ログイン開始用にユーザーをリダイレクトする URL を入力します。これは、SAML IdP アプリケーションのログイン URL です。

10. IdP in the IdP Public Cert フィールドからのシークレットに使用する公開証明書を入力します。これは、IdP からダウンロードできる SAML 証明書です。

    注記

    IdP in the IdP Public Cert フィールドには、—–BEGIN CERTIFICATE—– と —–END CERTIFICATE—– を含む証明書全体を含める必要があります。IdP に接頭辞と接尾辞が含まれていない場合は、手動で入力する必要があります。

11. Entity ID にアサーションで返されたエンティティー ID を入力します。これは、IdP SAML アプリケーションの識別子です。この値は、IdP によって提供される SAML メタデータで確認できます。
12. Groups、User Email、Username、User Last Name、および User First Name にユーザーの詳細を入力します。

13. User Permanent ID フィールドにユーザーの永続的な ID を入力します。このフィールドは必須です。

    注記

    SAML IdP を通じて追加の属性を利用できる場合があります。この値は、Additional Authenticators Fields または SAML IDP to extra_data attribute mapping フィールドのいずれかに含める必要があります。詳細は、該当する手順を参照してください。

14. SAML Assertion Consumer Service (ACS) URL フィールドで、設定済みの各アイデンティティープロバイダー (IdP) にサービスをサービスプロバイダー (SP) として登録します。このフィールドは空白のままにしてください。この認証方法を保存すると、URL が自動的に生成されます。このフィールドは、IdP の Reply URL 設定と一致する必要があります。

15. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。たとえば、メールアドレス、ユーザー名、姓、名以外のすべての SAML IdP 属性をマッピングの対象にするには、次のように入力します。

    Copy to Clipboard Toggle word wrap

    GET_ALL_EXTRA_DATA: true

    または、SAML IDP to extra_data attribute mapping フィールドに SAML IdP 属性のリストを含めることもできます。

    注記

    このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

16. SAML Service Provider Organization Info フィールドに、URL、表示名、アプリケーションの名前を入力します。

    Copy to Clipboard Toggle word wrap

    {
      "en-US": {
        "url": "http://www.example.com",
        "displayname": "Example",
        "name": "example"
      }
    }

17. SAML Service Provider Technical Contact フィールドに、サービスプロバイダーの技術担当者の名前とメールアドレスを入力します。

    Copy to Clipboard Toggle word wrap

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

18. SAML Service Provider Support Contact フィールドに、サービスプロバイダーのサポート担当者の名前とメールアドレスを入力します。

    Copy to Clipboard Toggle word wrap

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

19. オプション: SAML Service Provider extra configuration data フィールドに追加の設定データを入力します。たとえば、セキュリティーを強化するために署名リクエストを有効にすることを選択できます。

    Copy to Clipboard Toggle word wrap

    {
    "sign_request": True,
    }

    このフィールドは、API の SOCIAL_AUTH_SAML_SP_EXTRA と同等です。有効なサービスプロバイダーの追加のパラメーター (SP_EXTRA) の詳細は、OneLogin の SAML Python Toolkit を参照してください。

20. オプション: SAML Security Config フィールドに、セキュリティー設定を入力します。このフィールドは、API の SOCIAL_AUTH_SAML_SECURITY_CONFIG フィールドに相当します。

    Copy to Clipboard Toggle word wrap

    // 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,

    詳細情報と追加オプションは、OneLogin の SAML Python Toolkit を参照してください。

21. オプション: SAML IDP to extra_data attribute mapping フィールドに、IDP 属性を extra_data 属性にマッピングする値を入力します。この値には、メールアドレスやユーザー名など、マッピングする標準属性以外の追加のユーザー情報が含まれます。以下に例を示します。

    Copy to Clipboard Toggle word wrap

    - Department
    - UserType
    - Organization

    入力できる値の詳細は、詳細な SAML 設定 を参照してください。

    重要

    設定に応じてすべてが正しくマッピングされるように、関連する値をすべて含めてください。または、Additional Authenticator Fields に GET_ALL_EXTRA_DATA: true を含めて、利用可能なすべての SAML IdP 属性のマッピングを許可することもできます。

22. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
23. 作成時にこの認証方法を有効にするには、Enabled を選択します。
24. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
25. 認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから TACACS+ を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. 以下の情報を入力します。

   • TACACS+ サーバーのホスト名: 認証に使用する TACACS+ サーバーのホスト名または IP アドレスを指定します。このフィールドを空白のままにすると、TACACS+ 認証は無効になります。
   • TACACS+ Authentication Protocol: TACACS+ クライアントが使用するプロトコルです。オプションは ascii または pap です。
   • TACACS+ サーバーへの認証用の共有シークレット: TACACS+ 認証サーバーの秘密鍵。
7. TACACS+ client address sending enabled は、デフォルトでは無効になっています。クライアントアドレスの送信を有効にするには、チェックボックスをオンにします。

8. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

   注記

   このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

9. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
10. 作成時にこの認証方法を有効にするには、Enabled を選択します。

11. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。

    認証方法の作成 をクリックします。

1. この手順に従って、Microsoft Entra ID 認証を使用するように Ansible Automation Platform を設定 します。
2. Quickstart: Register an application with the Microsoft identity platform に従って、Ansible Automation Platform を Microsoft Entra ID に登録 します。このプロセスにより、アプリケーション (クライアント) ID とアプリケーションシークレットが得られます。
3. Microsoft Entra ID にリダイレクト URL を追加 します。プラットフォームで Microsoft Entra ID 認証の設定ウィザードを完了したら、Azure AD OAuth2 Callback URL フィールドに表示される URL をコピーします。次に、Azure で登録したエンタープライズアプリケーションに移動し、How to add a redirect URI to your application の説明に従って、この URL を Redirect URL (Ansible Automation Platform では Callback URL とも呼ばれます) として追加します。この手順は、ログインフローを正しく機能させるために必要です。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから Azuread を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。
6. Edit をクリックし、Microsoft の Application (Client) ID をコピーして OIDC Key フィールドにペーストします。

7. グループクレーム内でユーザーグループ情報を提供するように Microsoft Entra ID が設定されている場合は、必ず Microsoft Entra ID 設定と一致する Groups Claim 名を使用してプラットフォームを設定します。これにより、Microsoft Entra ID を通じてログインするユーザーのグループを、プラットフォームが正しく識別して関連付けることが可能になります。

   注記

   Microsoft Entra ID からのグループは、グループ名の代わりに一意の ID を使用します。Microsoft Entra ID オーセンティケーターのグループマップを作成するときは、一意の ID を使用する必要があります。

   デフォルトでは、Microsoft Entra ID はグループをデフォルトのグループクレーム名として使用します。したがって、値をデフォルトに設定するか、IdP で設定したカスタムオーバーライドに設定してください。現在のデフォルトは、明示的に変更されない限り、既存の動作を保持するように設定されています。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから Google OAuth を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. Google OAuth2 Key および Google OAuth2 Secret フィールドは事前に入力されています。

   入力されていない場合は、Web アプリケーションのセットアッププロセス中に Google から提供された認証情報を使用します。次の手順で使用するためにこれらの設定を保存します。

7. Google のクライアント ID をコピーして、Google OAuth2 Key フィールドにペーストします。
8. Google のクライアントシークレットをコピーして、Google OAuth2 Secret フィールドにペーストします。

9. オプション: 指示と必要な形式を示すツールヒントを使用して、次のフィールドに情報を入力します。

   • Access Token URL
   • Access Token Method
   • Authorization URL
   • Revoke Token Method
   • Revoke Token URL
   • OIDC JWT Algorithm(s)
   • OIDC JWT

10. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

    注記

    このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

11. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
12. 作成時にこの認証方法を有効にするには、Enabled を選択します。

13. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。

    認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから Generic OIDC を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. 以下の情報を入力します。

   • OIDC Provider URL: OIDC プロバイダーの URL。
   • OIDC Key: サードパーティー IdP からのクライアント ID。
   • OIDC Secret: IdP からのクライアントシークレット。
7. オプション: Access Token Method リストからアクセストークンを要求するときに使用する HTTP メソッドを選択します。デフォルトのメソッドは POST です。

8. オプションで、指示と必要な形式を示すツールヒントを使用して、次のフィールドに情報を入力します。

   • Access Token Method - デフォルトのメソッドは POST です。
   • Access Token URL
   • Access Token Method
   • Authorization URL
   • ID Key
   • ID Token Issuer
   • JWKS URI
   • OIDC Public Key
   • Revoke Token Method - デフォルトの方法は GET です。
   • Revoke Token URL
   • Response Type
   • Token Endpoint Auth Method
   • Userinfo URL
   • Username Key
9. Verify OIDC Provider Certificate を使用して、OIDC プロバイダー SSL 証明書の検証を有効または無効にします。
10. Redirect 状態を使用して、リダイレクト URI の状態パラメーターを有効または無効にします。Cross Site Request Forgery (CSRF) 攻撃を阻止するために、これを有効にすることを推奨します。

11. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

    注記

    このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

12. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
13. 作成時にこの認証方法を有効にするには、Enabled を選択します。
14. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
15. 認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから Keycloak を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。
6. Keycloak Access Token URL フィールドに、ユーザーのトークンを取得できるロケーションを入力します。
7. オプション: Keycloak Provider URL フィールドに、ユーザーがログインフロー中にリダイレクトされるロケーションを入力します。
8. Keycloak OIDC Key フィールドに、Keycloak インストールからのクライアント ID を入力します。
9. Keycloak レルムから提供された RS256 公開鍵を Keycloak Public Key フィールドに入力します。
10. Keycloak OIDC Secret フィールドに、Keycloak インストールからの OIDC シークレット (クライアントシークレット) を入力します。

11. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

    注記

    このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

12. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
13. 作成時にこの認証方法を有効にするには、Enabled を選択します。
14. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
15. 認証方法の作成 をクリックします。

1. Keycloak 設定のナビゲーションから、Client scopes YOUR-CLIENT-ID-dedicated Add mapper Audience を選択します。
2. マッパーの名前を選択します。
3. Included Client Audience でクライアントに対応する Client ID を選択します。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. アプリケーションの登録が済むと、GitHub では クライアント ID および クライアントシークレット が表示されます。

   1. GitHub クライアント ID をコピーして、GitHub OAuth2 Key フィールドにペーストします。
   2. GitHub クライアントシークレットをコピーして、GitHub OAuth2 Secret フィールドにペーストします。

7. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

   注記

   このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

8. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
9. 作成時にこの認証方法を有効にするには、Enabled を選択します。
10. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
11. 認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub organization を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. アプリケーションの登録が済むと、GitHub では クライアント ID および クライアントシークレット が表示されます。

   1. GitHub クライアント ID をコピーして、GitHub OAuth2 Key フィールドにペーストします。
   2. GitHub クライアントシークレットをコピーして、GitHub OAuth2 Secret フィールドにペーストします。
7. GitHub OAuth Organization Name フィールドに、組織の URL で使用されている GitHub 組織の名前 (例: https://github.com/<yourorg>/) を入力します。

8. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

   注記

   このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

9. GitHub OAuth2 Scope フィールドにユーザーの認可スコープを入力します。デフォルトは read:org です。
10. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
11. 作成時にこの認証方法を有効にするには、Enabled を選択します。
12. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
13. 認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub チーム を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. アプリケーションの登録が済むと、GitHub では クライアント ID および クライアントシークレット が表示されます。

   1. GitHub クライアント ID をコピーして、GitHub OAuth2 Key フィールドにペーストします。
   2. GitHub クライアントシークレットをコピーして、GitHub OAuth2 Secret フィールドにペーストします。
7. GitHub のチーム ID をコピーして、GitHub OAuth2 Team ID フィールドにペーストします。
8. GitHub OAuth2 Scope フィールドにユーザーの認可スコープを入力します。デフォルトは read:org です。

9. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

   注記

   このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

10. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
11. 作成時にこの認証方法を有効にするには、Enabled を選択します。
12. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
13. 認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub enterprise を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. アプリケーションの登録が済むと、GitHub では クライアント ID および クライアントシークレット が表示されます。

   1. GitHub クライアント ID をコピーして、GitHub OAuth2 Key フィールドにペーストします。
   2. GitHub クライアントシークレットをコピーして、GitHub OAuth2 Secret フィールドにペーストします。
7. Base URL フィールドに、GitHub Enterprise インスタンスのホスト名を入力します (例: https://github.example.com)。
8. Github OAuth2 Enterprise API URL フィールドに、GitHub Enterprise インスタンスの API URL を入力します (例: https://github.example.com/api/v3)。

9. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

   注記

   このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

10. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
11. 作成時にこの認証方法を有効にするには、Enabled を選択します。
12. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
13. 認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub enterprise organization を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. アプリケーションの登録が済むと、GitHub では クライアント ID および クライアントシークレット が表示されます。

   1. GitHub クライアント ID をコピーして、GitHub OAuth2 Key フィールドにペーストします。
   2. GitHub クライアントシークレットをコピーして、GitHub OAuth2 Secret フィールドにペーストします。
7. Base URL フィールドに、GitHub Enterprise インスタンスのホスト名を入力します (例: https://github.example.com)。
8. Github OAuth2 Enterprise API URL フィールドに、GitHub Enterprise インスタンスの API URL を入力します (例: https://github.example.com/api/v3)。
9. GitHub OAuth2 Enterprise Org Name フィールドに、組織の URL で使用されている GitHub Enterprise 組織の名前 (例: https://github.com/<yourorg>/) を入力します。

10. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

    注記

    このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

11. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
12. 作成時にこの認証方法を有効にするには、Enabled を選択します。
13. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
14. 認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub enterprise team を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。

6. アプリケーションの登録が済むと、GitHub では クライアント ID および クライアントシークレット が表示されます。

   1. GitHub クライアント ID をコピーして、GitHub OAuth2 Key フィールドにペーストします。
   2. GitHub クライアントシークレットをコピーして、GitHub OAuth2 Secret フィールドにペーストします。
7. Base URL フィールドに、GitHub Enterprise インスタンスのホスト名を入力します (例: https://github.orgexample.com)。
8. Github OAuth2 Enterprise API URL フィールドに、GitHub Enterprise インスタンスの API URL を入力します (例: https://github.example.com/api/v3)。
9. GitHub 開発者アプリケーションの OAuth2 キー (クライアント ID) を GitHub OAuth2 チーム ID フィールドに入力します。

10. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

    注記

    このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

11. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
12. 作成時にこの認証方法を有効にするには、Enabled を選択します。
13. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
14. 認証方法の作成 をクリックします。

手順

1. ナビゲーションパネルから、Access Management Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから Radius を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Auto migrate users from リストからレガシーオーセンティケーターのメソッドを選択します。2.4 から 2.5 にアップグレードした後、このレガシーオーセンティケーターから、ユーザーがこの新しい認証設定に自動的に移行されます。ユーザーの移行に関する重要な情報は、「RPM によるアップグレードと移行」ガイドの Ansible Automation Platform のアップグレード後の手順 を参照してください。
6. RADIUS Server フィールドに RADIUS サーバーのホストまたは IP を入力します。このフィールドを空白のままにすると、RADIUS 認証は無効になります。
7. RADIUS サーバーへの認証用の共有シークレット を入力します。

8. オプション: このオーセンティケーターが使用できる Additional Authenticator Fields を入力します。これらのフィールドは検証されず、オーセンティケーターに直接返されます。

   注記

   このフィールドで定義された値は、UI で提供される専用フィールドをオーバーライドします。ここで定義されていない値はオーセンティケーターに提供されません。

9. 正常にログインした際に組織、ユーザー、チームを自動的に作成するには、Create objects を選択します。
10. 作成時にこの認証方法を有効にするには、Enabled を選択します。
11. このソースから認証する際に以前に追加されたグループからユーザーを削除するには、Remove users を選択します。
12. 認証方法の作成 をクリックします。