アクセス管理と認証

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。

3. オーセンティケーターの一意の Name を入力します。名前は必須で、すべてのオーセンティケーター間で一意である必要があり、512 文字を超えることはできません。これは、オーセンティケーターに対して生成される一意の識別子になります。

   注記

   名前を変更しても、オーセンティケーターの一意の識別子は更新されません。たとえば、My Authenticator という名前のオーセンティケーターを作成し、後でその名前を My LDAP Authenticator に変更した場合、一意の識別子が引き続き使用されているため、My Authenticator という名前の別のオーセンティケーターを作成することはできません。

4. Authentication type リストから、オーセンティケータータイプを選択します。利用可能な認証プラグインの完全なリストは、認証タイプの設定 を参照してください。

5. Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。必要な詳細は、「認証タイプの設定」の各セクションを参照してください。

   すべての認証タイプに、Name、Additional Authenticator Fields、および Create Objects を入力します。

6. Enabled を有効または無効にして、オーセンティケーターを有効にするか無効にするかを指定します。有効にすると、ユーザーはオーセンティケーターからログインできます。無効にすると、ユーザーはオーセンティケーターからログインできません。

7. Create Object を有効または無効にして、ユーザーがログインした際にオーセンティケーターがシステムにチームと組織を作成するかどうかを指定します。

   Enabled

   オーセンティケーターマップ内で定義されたチームと組織が作成され、ユーザーがそれらに追加されます。

   Disabled

   オーセンティケーターマップ内で定義された組織とチームは、システム内で自動的に作成されません。ただし、マップがすでに存在する場合 (スーパーユーザーによって作成された場合)、マップをトリガーするユーザーにはマップへのアクセスが許可されます。

8. Remove Users を有効または無効にします。有効にすると、ユーザーがこのソースから認証される際に、以前にユーザーに付与されたアクセス権がすべて削除されます。無効にすると、このオーセンティケーターのオーセンティケーターマッピングの結果に基づいてのみ、ユーザーに権限が追加されたり、権限が削除されたりします。

   たとえば、ユーザーにシステム内で is_superuser 権限が付与されているとします。そして、そのユーザーがログインするオーセンティケーターのマップでは、そのユーザーがスーパーユーザーであるべきかどうかは判断されません。Remove Users が有効な場合、is_superuser 権限はユーザーから削除されます。オーセンティケーターマップはその権限を持たせるべきかどうかを判定しないため、ログイン後、ユーザーは is_superuser 権限を持ちません。

   Remove Users が無効な場合、is_superuser 権限はユーザーから 削除されません。オーセンティケーターマップはその権限を持たせるべきかどうかを判定しないため、ログイン後、ユーザーは is_superuser 権限を 持ちます。

9. Create Authentication Method をクリックし、Define authentication mapping rules and triggers に進みます。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. リストビューで、Name 列に表示されているオーセンティケーター名を選択します。
3. オーセンティケーターの Details ページから Mapping タブを選択します。
4. Create mapping をクリックします。

5. Authentication mapping リストからマップのタイプを選択します。各マップのタイプの詳細な説明は、オーセンティケーターマップのタイプ を参照してください。次の選択肢があります。

   • Allow
   • Organization
   • Team
   • Role
   • Is Superuser
6. ルールを識別するための一意のルールの Name を入力します。

7. リストから Trigger を選択します。詳細は、オーセンティケーターマップトリガー を参照してください。次の選択肢があります。

   • Always
   • Never
   • Group
   • Attribute
8. Create mapping をクリックします。
9. この手順を繰り返して、オーセンティケーターのマッピングルールとトリガーをさらに作成します。

10. 必要に応じてオーセンティケーターのマッピングの順序を変更するには、マッピング順序の調整 に進みます。

    注記

    マッピング順序の設定は、複数のオーセンティケーターマップが定義されている場合にのみ使用できます。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. リストビューで、Name 列に表示されているオーセンティケーター名を選択します。
3. オーセンティケーターの Details ページから Mapping タブを選択します。
4. Manage mappings をクリックします。

5. ドラッグ可能なアイコンを使用して、リスト内でマッピングを上または下にドラッグアンドドロップして、マッピングの順序を調整します。

   注記

   マッピングの優先順位は、マッピングがリストされている順序によって決まります。

6. オーセンティケーターマップが正しい順序になったら、Apply をクリックします。

手順

1. Ansible Automation Platform UI 内のオーセンティケーターの設定詳細に移動し、callback_url を見つけます。

   詳細は、オーセンティケーターの詳細の表示 を参照してください。

2. Ansible Automation Platform が特定の認証方法に対して提供する自動生成された コールバック URL、リダイレクト URL、または 応答 URL を特定してコピーします。
3. 必要に応じて、Ansible Automation Platform からコピーしたリダイレクト URL を IdP の設定に貼り付けて、IdP の設定を更新します。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. このローカル設定の Name を入力します。設定名は必須で、すべてのオーセンティケーター間で一意である必要があり、512 文字を超えることはできません。
4. Authentication type リストから Local を選択します。

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

   注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから LDAP を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. LDAP Server URI フィールドで、接続する LDAP サーバーのリストを入力または変更します。このフィールドは複数のアドレスをサポートします。

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

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

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

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

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

   Expand

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

   LDAP グループタイプ	Description	初期化メソッド (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'

   Show more
   注記

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

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

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

   Copy to Clipboard Toggle word wrap

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

   注記

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

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

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

    注記

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

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

    OPT_REFERRALS: 0
    OPT_NETWORK_TIMEOUT: 30

    Copy to Clipboard Toggle word wrap

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

13. 選択した 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 です。

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

    Copy to Clipboard Toggle word wrap

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

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

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

    Copy to Clipboard Toggle word wrap

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

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

    Copy to Clipboard Toggle word wrap

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

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

    Copy to Clipboard Toggle word wrap

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

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

    Copy to Clipboard Toggle word wrap

    複数の検索の実行中に一意でないユーザーが複数見つかった場合、それらのユーザーは 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 フィールドよりも優先され、ユーザーの認証にテンプレートのみが使用されます。

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

手順

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

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

   注記

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

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

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

    注記

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

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

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

    GET_ALL_EXTRA_DATA: true

    Copy to Clipboard Toggle word wrap

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

    注記

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

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

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

    Copy to Clipboard Toggle word wrap

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

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

    Copy to Clipboard Toggle word wrap

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

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

    Copy to Clipboard Toggle word wrap

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

    {
    "sign_request": True,
    }

    Copy to Clipboard Toggle word wrap

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

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

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

    Copy to Clipboard Toggle word wrap

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

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

    - Department
    - UserType
    - Organization

    Copy to Clipboard Toggle word wrap

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

    重要

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

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

24. Create Authentication Method をクリックします。

    重要

    Operator ベースのデプロイメントでは、SAML の HTTPS リダイレクトを設定すると、ユーザーのログインを簡素化できます。これを設定する手順は、OpenShift Container Platform 上のプラットフォームゲートウェイでシングルサインオン (SSO) を有効にする を参照してください。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから TACACS+ を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。

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

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

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

   注記

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

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

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. Edit をクリックし、Microsoft の Application (Client) ID をコピーして OIDC Key フィールドにペーストします。

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

   注記

   Microsoft Entra ID からのグループは、一意の ID またはグループ名を使用して識別できます。Microsoft Entra ID オーセンティケーターのグループマッピングを作成するときは、一意の ID またはグループ名のいずれかを使用できます。

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

7. アプリケーションを Microsoft アイデンティティープラットフォームに登録する ための手順に従って、認証用のキー (一度だけ表示) をクライアントに提供します。
8. Microsoft Entra ID/Microsoft Azure AD アプリケーション用に作成された秘密鍵をコピーして、OIDC Secret フィールドに貼り付けます。
9. オプション: デフォルトでは、Microsoft Entra ID の名前属性が、Ansible Automation Platform 内のユーザー名フィールドとして使用されます。デフォルト値をオーバーライドして Microsoft Entra ID の別の属性を使用する場合は、ユーザー名フィールドにその属性を入力します。

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

    注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから Google OAuth を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。

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

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

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

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

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

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

   注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから Generic OIDC を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。

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

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

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

   • Access Token Method - デフォルトのメソッドは POST です。
   • Access Token URL
   • Access Token Method
   • Authorization URL
   • Callback URL - OIDC Callback URL フィールドでは、設定した各 OIDC プロバイダーにサービスをサービスプロバイダー (SP) として登録します。このフィールドは空白のままにしてください。この認証方法を保存すると、URL が自動的に生成されます。認証フローの一部としてこの URL へのリダイレクトを許可するように IdP を設定します。
   • 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
8. Verify OIDC Provider Certificate を使用して、OIDC プロバイダー SSL 証明書の検証を有効または無効にします。
9. Redirect 状態を使用して、リダイレクト URI の状態パラメーターを有効または無効にします。Cross Site Request Forgery (CSRF) 攻撃を阻止するために、これを有効にすることを推奨します。

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

    注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから Keycloak を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. Keycloak Access Token URL フィールドに、ユーザーのトークンを取得できるロケーションを入力します。
6. オプション: Keycloak Provider URL フィールドに、ユーザーがログインフロー中にリダイレクトされるロケーションを入力します。
7. Keycloak OIDC Key フィールドに、Keycloak インストールからのクライアント ID を入力します。
8. Keycloak レルムから提供された RS256 公開鍵を Keycloak Public Key フィールドに入力します。
9. Keycloak OIDC Secret フィールドに、Keycloak インストールからの OIDC シークレット (クライアントシークレット) を入力します。

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

    注記

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

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

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

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

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

   注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub organization を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。

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

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

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

   注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub team を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。

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

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

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

   注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub Enterprise を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。

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

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

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

   注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub enterprise organization を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。

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

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

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

   注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから GitHub enterprise team を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。

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

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

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

   注記

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

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

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. Create authentication をクリックします。
3. この認証設定の Name を入力します。
4. Authentication type リストから Radius を選択します。Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。
5. RADIUS Server フィールドに RADIUS サーバーのホストまたは IP を入力します。このフィールドを空白のままにすると、RADIUS 認証は無効になります。
6. RADIUS サーバーへの認証用の共有シークレット を入力します。

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

   注記

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

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

1. 許可しない設定の 許可 ルール
2. グループに基づく 許可 ルール
3. ユーザー属性に基づく スーパーユーザー ルール
4. ユーザーグループに基づく チーム 管理ルール

1. このページの Organization というタイトルは、組織の設定権限を設定中であることを示しています。
2. このフィールドには Network Organization が入力されています。これは、このマップ設定の一意のわかりやすい名前です。
3. ソースシステムの属性 (この例では Organization) に基づいて認証を設定するために、Trigger リストから Attributes を選択します。
4. Operation は or と定義されています。これは、認証が成功するには少なくとも 1 つの条件が true である必要があることを意味します。
5. ソースシステムから取得される Attribute は Organization です。
6. Comparison 値は matches に設定されています。これにより、ユーザーが属性の Value として Networking を持つ場合、そのユーザーは Networking 組織に追加されます。
7. ソースシステムから取得される Value は Networking です。
8. メンバーを追加する Organization の名前は Networking です。
9. ユーザーは、Organization Member ロールを持つ Networking 組織に追加されます。

手順

1. 認証方法の認証の詳細を設定した後、Mapping タブを選択します。
2. Add authentication mapping リストから Allow を選択します。
3. ルールを識別するための一意のルールの Name を入力します。
4. リストから Trigger を選択します。マップのトリガーに関する詳細は、オーセンティケーターマップトリガー を参照してください。
5. トリガー条件がマッチしない場合にシステムへのユーザーアクセスを拒否するには、Revoke を選択します。
6. Next をクリックします。

手順

1. 認証方法の認証の詳細を設定した後、Mapping タブを選択します。
2. Add authentication mapping リストから Organization を選択します。
3. ルールを識別するための一意のルールの Name を入力します。
4. リストから Trigger を選択します。マップのトリガーに関する詳細は、オーセンティケーターマップトリガー を参照してください。
5. トリガー条件がマッチしない場合に、選択した組織ロールへのユーザーアクセスを削除するには、Revoke を選択します。
6. 一致するユーザーを追加またはブロックする Organization を選択します。
7. 一致するユーザーに適用または削除する Role を選択します (たとえば、Organization Admin または Organization Member)。
8. Next をクリックします。

手順

1. 認証方法の認証の詳細を設定した後、Mapping タブを選択します。
2. Add authentication mapping リストから Team を選択します。
3. ルールを識別するための一意のルールの Name を入力します。
4. リストから Trigger を選択します。マップのトリガーに関する詳細は、オーセンティケーターマップトリガー を参照してください。
5. トリガー条件がマッチしない場合に、選択した組織ロールへのユーザーアクセスを削除し、システムへのユーザーアクセスを拒否するには、Revoke を選択します。
6. 一致するユーザーを追加またはブロックする Team および Organization を選択します。
7. 一致するユーザーに適用または削除する Role (Team Admin または Team Member など) を選択します。
8. Next をクリックします。

手順

1. 認証方法の認証の詳細を設定した後、Mapping タブを選択します。
2. Add authentication mapping リストから Role を選択します。
3. ルールを識別するための一意のルールの Name を入力します。
4. リストから Trigger を選択します。マップのトリガーに関する詳細は、オーセンティケーターマップトリガー を参照してください。
5. トリガー条件のいずれにも一致しない場合は、Revoke を選択してユーザーのロールを削除します。
6. 一致するユーザーに適用または削除する Role を選択します。
7. Next をクリックします。

手順

1. 認証方法の認証の詳細を設定した後、Mapping タブを選択します。
2. Add authentication mapping リストから Superuser を選択します。
3. ルールを識別するための一意のルールの Name を入力します。
4. リストから Trigger を選択します。マップのトリガーに関する詳細は、オーセンティケーターマップトリガー を参照してください。
5. トリガー条件のいずれにも一致しない場合は、Revoke を選択して、ユーザーからスーパーユーザーロールを削除します。
6. Next をクリックします。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. リストからオーセンティケーターを選択します。
3. Mapping タブを選択し、Create mapping をクリックします。
4. Authentication mapping で、適切なマッピングタイプ (Organization、Team、または Role) を選択します。
5. Trigger フィールドで、Attributes を選択します。

6. 組織マップの Organization フィールドなどの対応するフィールドに、Jinja のような構文を入力して名前を動的に生成します。

   • たとえば、users_orgs という属性に基づいて組織名を作成するには、Org {% for_attr_value(users_orgs) %} と入力します。
7. Attribute フィールドで、ループする値を持つ外部プロバイダーの属性の名前 (例: users_orgs) を指定します。
8. マッピングのその他の必須フィールドを入力します。詳細は、オーセンティケーターマップトリガー を参照してください。

9. Create mapping をクリックします。プラットフォームゲートウェイは、このテンプレートを使用して、指定された属性の値に基づいてユーザー割り当てを作成および管理します。

   注記

   テンプレート構文の入力に誤りがあった場合、システムは検証エラーを発生させ、新しいオーセンティケーターマップは作成されません認証中に、外部プロバイダーが指定された属性を提供しない場合、またはユーザーが Jinja 構文で指定された属性に関連付けられた値を持っていない場合、マップがトリガーされ、その理由を示すメッセージがプラットフォームゲートウェイログに記録されます。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。

   Authentication Methods ページが表示されます。

2. Create authentication をクリックし、認証タイプの設定 の認証方法を作成する手順に従います。それ以外の場合は、手順 3 に進みます。
3. メニューバーから、Order、Name および Authentication type のメニューバーの矢印を使用して、認証方法のリストを並べ替えることができます。
4. トグルをクリックして、オーセンティケーターを 有効 または 無効 にします。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. 検索バーに、検索する認証方法の適切なキーワードを入力し、矢印アイコンをクリックします。
3. 探しているものが見つからない場合は、検索を絞り込むことができます。フィルターリストから、使用する検索用語に応じて Name または Authentication type を選択します。
4. 検索結果のリストをスクロールし、確認するオーセンティケーターを選択します。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。

2. リストビューで、Name 列に表示されているオーセンティケーター名を選択します。

   オーセンティケーターの Details ページが表示されます。

3. Details ページから、オーセンティケーターに適用された設定を確認できます。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。

2. リストビューでは、次のいずれかを実行できます。

   1. 変更するオーセンティケーターの横にある Edit アイコンを選択します。
   2. Name 列に表示されているオーセンティケーター名を選択し、Details ページから Edit authenticator をクリックします。
3. 必要に応じて、認証の詳細またはマッピング設定を変更します。
4. Save をクリックします。

手順

1. ナビゲーションパネルから、Access Management → Authentication Methods を選択します。
2. リストビューで、削除するオーセンティケーターの横にあるチェックボックスをオンにします。

3. ⋮ リストから Delete authentication を選択します。

   注記

   削除する各オーセンティケーターの横にあるチェックボックスを選択し、メニューバーの ⋮ リストから Delete selected authentication クリックすると、複数のオーセンティケーターを削除できます。

手順

1. ナビゲーションパネルから、Access Management → OAuth Applications を選択します。
2. Create OAuth application をクリックします。Create Application ページが開きます。

3. 以下の詳細を入力します。

   名前

   (必須) 作成するアプリケーションの名前を入力します。

   URL

   (オプション) 外部アプリケーションの URL を入力します。このリンクは、簡単にアクセスできるようにナビゲーションパネルに追加されます。この設定は現在テクノロジープレビューとして提供されています。

   Description

   (任意) アプリケーションの簡単な説明を記入します。

   Organization

   (必須) このアプリケーションを関連付ける組織を選択します。

   Authorization grant type

   (必須) ユーザーがこのアプリケーションのトークンを取得するために使用する付与タイプを 1 つ選択します。付与タイプの詳細は、アプリケーションの機能 を参照してください。

   Client Type

   (必須) クライアントデバイスのセキュリティーレベルを選択します。

   Redirect URIS

   許可する URI のリストをスペースで区切りで指定します。これは、付与タイプを Authorization code に指定した場合に必須です。

4. Create OAuth application をクリックするか、Cancel をクリックして変更を破棄します。

   Client ID と Client Secret がウィンドウに表示されます。クライアントシークレットが表示されるのはこのときだけです。

   注記

   Client Secret は、Client type が Confidential に設定されている場合にのみ作成されます。

5. コピーアイコンをクリックして、外部アプリケーションを Ansible Automation Platform と統合するためのクライアント ID とクライアントシークレットを保存します。

手順

1. ナビゲーションパネルから、Settings → Platform gateway に移動します。
2. Edit platform gateway 設定をクリックします。
3. Allow external users to create OAuth2 tokens 設定を Enabled に変更します。
4. Save platform gateway settings をクリックします。

手順

1. ナビゲーションパネルから、Access Management → Organizations を選択します。
2. Search バーに、検索する組織の適切なキーワードを入力し、矢印アイコンをクリックします。
3. メニューバーから、Name の矢印を使用して並べ替えの設定を切り替えることで、組織のリストを並べ替えることができます。
4. Sort リストから、Name、Created、または Last modified を選択して、リストを並べ替えることもできます。
5. Organizations ページで組織 Name をクリックすると、組織の詳細を表示できます。

手順

1. ナビゲーションパネルから、Access Management → Organizations を選択します。
2. Create organization をクリックします。

3. 組織の 名前 を入力し、説明 を入力します。

   注記

   プラットフォーム上で Automation Controller が有効になっている場合は、ステップ 4 に進みます。そうでない場合は、ステップ 6 に進みます。

4. Execution environment の名前を選択するか、この組織のメンバーが自動化を実行するために使用できる実行環境を検索します。
5. この組織を実行する Instance Groups の名前を入力します。
6. オプション: Galaxy credentials を入力するか、既存の認証情報のリストから検索します。

7. この組織の Max hosts を選択します。デフォルトは 0 です。この値が 0 の場合、制限がないことを示します。ホストの上限に達したか、上限を超えた組織にホストを追加しようとすると、次のエラーメッセージが表示されます。

   You have already reached the maximum number of 1 hosts allowed for your organization. Contact your System Administrator for assistance.

   Copy to Clipboard Toggle word wrap
8. Next をクリックします。

9. 1 つ以上のインスタンスグループを選択した場合は、リスト内でインスタンスグループを上下にドラッグアンドドロップし、Confirm をクリックすることで、順序を管理できます。

   注記

   実行の優先順位は、インスタンスグループがリストされている順序によって決まります。

10. Next をクリックして、組織の設定を確認します。
11. Finish をクリックします。

手順

1. ナビゲーションパネルから、Access Management → Organizations を選択します。
2. Organizations リストビューから、通知を管理する組織を選択します。
3. Notification タブを選択します。
4. トグルを使用して、特定の組織で使用する通知を有効または無効にします。詳細は、通知の有効化と無効化 を参照してください。
5. 通知機能がセットアップされていない場合は、ナビゲーションパネルから Automation Execution → Administration → Notifiers を選択します。

手順

1. ナビゲーションパネルから、Access Management → Organizations を選択します。
2. Organizations リストビューから、実行環境を管理する組織を選択します。
3. Execution Environments タブを選択します。
4. 実行環境が利用できない場合は、Create execution environment をクリックして実行環境を作成します。または、ナビゲーションパネルから Automation Execution → Infrastructure → Execution Environments を選択して、実行環境を作成することもできます。

5. Create execution environment をクリックします。

   注記

   新しい実行環境を作成したら、Access Management → Organizations に戻り、実行環境を作成した組織を選択して、そのタブのリストを更新します。

6. 特定の組織で使用する実行環境を選択します。

手順

1. ナビゲーションパネルから、Access Management → Teams を選択します。
2. Search バーに、検索するチームの適切なキーワードを入力し、矢印アイコンをクリックします。
3. メニューバーから、Name と Organization の矢印を使用して並べ替えの設定を切り替えることで、チームのリストを並べ替えることができます。
4. Teams ページでチームの Name をクリックすると、チームの詳細を表示できます。
5. Organization 列のリンクをクリックすると、組織の詳細を表示できます。

手順

1. ナビゲーションパネルから、Access Management → Teams を選択します。
2. Create team をクリックします。
3. チームの Name を入力し、オプションで Description を入力します。

4. このチームに関連付ける Organization を選択します。

   注記

   各チームは 1 つの組織にのみ割り当てることができます。

5. Create team をクリックします。Details ページが開き、チーム情報とアクセス権を確認および編集できます。

手順

1. ナビゲーションパネルから、Access Management → Teams を選択します。
2. ユーザーを追加するチームを選択します。
3. Users タブを選択します。
4. 名前の横にあるチェックボックスをクリックしてリストから 1 人以上のユーザーを選択し、そのユーザーをこのチームのメンバーとして追加します。
5. Add users をクリックします。

手順

1. ナビゲーションパネルから、Access Management → Teams を選択します。
2. ユーザーを削除するチームを選択します。
3. Users タブを選択します。
4. チームから削除するユーザーの横にある Remove user アイコンをクリックします。

5. 削除する各ユーザーの横にあるチェックボックスをオンにし、More actions ⋮ リストから Remove selected users を選択すると、複数のユーザーを削除できます。

   注記

   ユーザーがチーム管理者である場合は、Administrators タブからチームへのメンバーシップを削除できます。

6. 削除を確認する確認ダイアログが表示されます。削除を確認します。チームからユーザーを削除すると、そのチームのロール割り当てがすべてユーザーから削除されることに注意してください。

手順

1. ナビゲーションパネルから、Access Management → Teams を選択します。
2. 管理者を追加するチームを選択します。
3. Administrators タブを選択し、Add administrator(s) をクリックします。
4. 名前の横にあるチェックボックスをクリックして、リストから 1 人以上のユーザーを選択し、そのユーザーをこのチームの管理者として追加します。
5. Add administrators をクリックします。

手順

1. ナビゲーションパネルから、Access Management → Teams を選択します。
2. ロールを追加するチームの Name を選択します。

3. Roles タブを選択し、Add roles をクリックします。

   注記

   プロジェクトや認証情報などのリソースは、Automation Execution (Automation Controller) と Automation Decisions (Event-Driven Ansible) の両方に関連付けることができるため、正しいコンポーネントコンテキスト内で目的のロールを選択していることを確認してください。

4. Resource type を選択し、Next をクリックします。
5. チームにロールベースのアクセス権を付与するリソースを選択し、Next をクリックします。

6. リソースに適用するロールを選択し、Next をクリックします。

   ヒント

   この手順で複数のロールを選択する場合は、チームに適切なアクセス権を付与するために、このリソースタイプに対するすべての権限を含む カスタムロールを作成する ことを検討してください。

7. 設定を確認して、Finish をクリックします。
8. ロールの割り当てが正常に適用されたかどうかを示す Add roles ダイアログが表示されます。Close をクリックしてダイアログを閉じます。

手順

1. ナビゲーションパネルから、Access Management → Teams を選択します。
2. ロールを削除するチームの Name を選択します。
3. Roles タブを選択します。

4. 単一のロールを削除するには、リソースの横にあるマイナスアイコンをクリックし、表示されるダイアログで削除を確定します。

   注記

   プロジェクトや認証情報などのリソースは、Automation Execution (Automation Controller) と Automation Decisions (Event-Driven Ansible) の両方に関連付けることができるため、正しいコンポーネントコンテキスト内で目的のロールを選択していることを確認してください。

5. ロールを一括削除するには、削除する各リソースの横にあるチェックボックスをオンにして、メニューバーの More Actions ⋮ リストから Delete selected roles をクリックし、削除を確認して Delete role をクリックします。

手順

1. ナビゲーションパネルから、Access Management → Teams を選択します。
2. 1 つのチームを削除するには、チームの横にあるマイナスアイコン - をクリックし、表示されるダイアログで削除を確定します。
3. チームを一括削除するには、削除する各チームの横にあるチェックボックスをオンにし、More Actions ⋮ アイコンをクリックして、Delete team を選択します。

手順

1. ナビゲーションパネルから、Access Management → Users を選択します。
2. Search バーに、検索するユーザーの適切なキーワードを入力し、矢印アイコンをクリックします。
3. メニューバーから、Username、Email、First name、Last name、または Last login の矢印を使用して並べ替えの設定を切り替えることで、ユーザーのリストを並べ替えることができます。
4. Users リストビューから Username を選択すると、ユーザーの詳細を表示できます。

手順

1. ナビゲーションパネルから、Access Management → Users を選択します。
2. Create user をクリックします。
3. Create user ページのフィールドに新しいユーザーの詳細を入力します。アスタリスク (*) の付いたフィールドは必須です。

4. User type が指定されていない場合は、標準ユーザーがデフォルトになります。ユーザーを管理者または監査人として定義するには、ドロップダウンメニューから User type を選択します。

   注記

   自分のパスワードを変更する場合は、変更を有効にするためにログアウトして再度ログインしてください。

5. このユーザーに割り当てる Organization を選択します。新しい組織の作成については、組織の作成 を参照してください。

6. Create user をクリックします。

   ユーザーが正常に作成されると、User の詳細画面が開きます。ここから、ユーザーのチーム、ロール、トークン、その他のメンバーシップの詳細を確認および変更できます。

手順

1. ナビゲーションパネルから、Access Management → Users を選択します。
2. 編集したいユーザーの横にある 鉛筆 アイコンをクリックし、Edit user を選択します。
3. ユーザーの Edit ページが表示されます。このページで、Password、Email、User type、Organization などのユーザーの詳細を変更できます。
4. 変更が完了したら、Save user をクリックします。

手順

1. ナビゲーションパネルから、Access Management → Users を選択します。
2. 1 人のユーザーを削除するには、削除するユーザーの横にある More Actions ⋮ アイコンを選択し、Delete user を選択します。
3. ユーザーを一括削除するには、削除する各ユーザーの横にあるチェックボックスをオンにし、More Actions⋮ リストから Delete users をクリックします。

手順

1. ナビゲーションパネルから、Access Management → Users を選択します。
2. Users リストビューから、ロールを追加するユーザーをクリックします。
3. このユーザーに割り当てられているロールのセットを表示するには、Roles タブを選択します。これらは、リソースの読み取り、変更、管理の機能を提供します。

4. 新しいロールを追加するには、Add roles をクリックします。

   注記

   プロジェクトや認証情報などのリソースは、Automation Execution (Automation Controller) と Automation Decisions (Event-Driven Ansible) の両方に関連付けることができるため、正しいコンポーネントコンテキスト内で目的のロールを選択していることを確認してください。

5. リソースタイプを選択し、Next をクリックします。
6. ロールベースのアクセスを許可するリソースを選択し、Next をクリックします。

7. リソースに適用するロールを選択し、Next をクリックします。

   ヒント

   複数のロールを選択する場合は、ユーザーに適切なレベルのアクセス権を付与できるように、このリソースタイプのすべての権限を含む カスタムロールを作成する ことを検討してください。

8. 設定を確認して、Finish をクリックします。ロールの割り当てが正常に適用されたかどうかを示す Add roles ダイアログが表示されます。Close をクリックしてダイアログを閉じます。

手順

1. ナビゲーションパネルから、Access Management → Users を選択します。
2. ロールアクセスを削除するユーザー名を選択します。

3. Roles タブを選択します。

   注記

   プロジェクトや認証情報などのリソースは、Automation Execution (Automation Controller) と Automation Decisions (Event-Driven Ansible) の両方に関連付けることができるため、正しいコンポーネントコンテキスト内で目的のロールを選択していることを確認してください。

4. 単一のロールを削除するには、ロールの横にある - アイコンをクリックし、表示されるダイアログで削除を確定します。
5. 複数のロールを削除するには、削除する各ロールの横にあるチェックボックスをオンにし、メニューバーの More actions ⋮ リストから Remove selected roles をクリックします。表示されるダイアログで、選択したロールの削除を確認し、Remove role をクリックします。

手順

1. ナビゲーションパネルから、チームにアクセス権を許可するリソースの名前をクリックします。たとえば、Automation Execution → Templates などです。
2. 詳細ページで、Team Access タブを選択します。
3. Assign Teams をクリックします。
4. チームの横にあるチェックボックスをクリックして、選択したリソースへのアクセス権をそのチームに割り当て、Next をクリックします。
5. 選択したリソースのチームに適用するロールを選択し、Next をクリックします。
6. 設定を確認して、Finish をクリックします。ロールの割り当てが正常に適用されたかどうかを示す Assign Teams ダイアログが表示されます。
7. チームの横にある Remove team アイコンを選択すると、チームのリソースアクセス権を削除できます。これにより確認ダイアログが起動し、削除を確定するように求められます。

手順

1. ナビゲーションパネルから、チームにアクセス権を許可するリソースを選択します。たとえば、Automation Execution → Templates などです。
2. User access タブを選択します。
3. Assign users をクリックします。
4. ユーザーの横にあるチェックボックスをクリックして、そのユーザーを選択したリソースに割り当て、Next をクリックします。
5. 選択したリソースのユーザーに適用するロールを選択し、Next をクリックします。
6. 設定を確認して、Finish をクリックします。ロールの割り当てが正常に適用されたかどうかを示す Assign Roles ダイアログが表示されます。
7. User Access タブで、ユーザー名の横にある鉛筆アイコン をクリックし、直接割り当てられたロールを追加または削除することで、そのユーザーのリソースへのアクセス権を編集できます。
8. ユーザーの横にある Remove role アイコンを選択すると、ユーザーのリソースアクセス権を削除できます。これにより確認ダイアログが起動し、削除を確定するように求められます。

手順

1. ナビゲーションパネルから、Settings → Platform gateway を選択します。
2. Platform gateway settings ページが表示されます。
3. オプションを設定するには、Edit をクリックします。

4. 次の Security 設定を設定できます。

   • システム管理者がセキュアでないユーザーパスワードを設定できるようにする: スーパーユーザーアカウントがローカルユーザーアカウントを編集する際にセキュアでないパスワードを保存できるかどうか。

   • Gateway basic auth enabled: プラットフォームゲートウェイ API への Basic 認証を有効にします。

     これをオフにすると、すべての Basic 認証 (ローカルユーザー) が阻止されるため、お客様はオフにする前に代替認証メカニズムが正しく設定されていることを確認する必要があります。

     ローカル認証のみが設定された状態でこれをオフにすると、UI へのすべてのアクセスも阻止されます。

     Gateway token name: プロキシーからバックエンドサービスにプッシュするヘッダー名。

   • Gateway access token expiration: アクセストークンの有効期間。

   • Jwt private key: バックエンドサービスに送信される JWT トークンを暗号化するために使用する秘密鍵。

     これは RSA 秘密鍵であり、インストール時に自動的に生成されます。

     注記

     鍵をローテーションすると、JWT 鍵がリセットされるまで現在のセッションが失敗するため、注意してください。

   • (読み取り専用) Jwt public key: バックエンドサービスに送信される JWT トークンを暗号化するために使用する秘密鍵。

     これは RSA 秘密鍵であり、インストール時に自動的に生成されます。

     注記

     他のサービスがこの鍵をどのように使用するかは、そのサービスのドキュメントを参照してください。

     警告

     この名前が変更された場合は、バックエンドを更新して補正する必要があります。

     Social auth username is full email: この設定を有効にすると、ソーシャル認証でユーザー名としてフルネームではなく完全なメールアドレスを使用するようにアラートが出されます。

   • Csrf trusted origins: サービスがリバースプロキシーまたはロードバランサーの背後にある場合、この設定を使用して、サービスが Origin ヘッダーの値を信頼すべき schema://addresses を設定します。
5. Save changes をクリックして変更を保存するか、利用可能な他のプラットフォームオプションの設定に進みます。

手順

1. ナビゲーションパネルから、Settings → Platform gateway を選択します。
2. Platform gateway settings ページが表示されます。
3. オプションを設定するには、Edit platform gateway settings をクリックします。
4. Session cookie age フィールドに、セッションの有効期限が切れるまでの時間を秒単位で入力します。
5. Save platform gateway settings をクリックして変更を保存するか、利用可能な他のプラットフォームオプションの設定に進みます。

手順

1. ナビゲーションパネルから、Settings → Platform gateway を選択します。
2. Platform gateway settings ページが表示されます。
3. オプションを設定するには、Edit platform gateway settings をクリックします。

4. 次の Password Security オプションを設定できます。

   • Password minimum uppercase letters: ローカルパスワードに必要な大文字の数。
   • Password minimum length: ローカルパスワードの最小長。
   • Password minimum numerical digits: ローカルパスワードに必要な数字の数。
   • Password minimum special characters: ローカルパスワードに必要な特殊文字の数。
5. Save platform gateway settings をクリックして変更を保存するか、利用可能な他のプラットフォームオプションの設定に進みます。

手順

1. ナビゲーションパネルから、Settings → Platform gateway を選択します。
2. Platform gateway settings ページが表示されます。
3. Edit platform gateway settings をクリックします。

4. 以下の Other settings を設定できます。

   • Jwt expiration buffer in seconds: JWT トークンの有効期限が切れてキャッシュから削除されるまでの秒数。

     認証が行われると、ユーザーに対して JWT トークンが作成され、そのトークンがキャッシュされます。その後、Automation Controller や Event-Driven Ansible などのサービスへの呼び出しが発生すると、トークンがキャッシュから取得され、サービスに送信されます。トークンとトークンのキャッシュの両方に有効期限があります。トークンがキャッシュ内にある間に期限切れになった場合、認証プロセスの試行は 401 error (unauthorized) を表示します。この設定により、トークンの有効期限が切れる前に JWT トークンをキャッシュから削除することで、Red Hat Ansible Automation Platform にバッファーが提供されます。トークンがキャッシュから取り消されると、新しい有効期限を持つ新しいトークンが生成され、ユーザー用にキャッシュされます。その結果、キャッシュ内の期限切れのトークンは使用されません。この設定のデフォルトは 2 秒です。プラットフォームゲートウェイとサービス間の遅延が大きく、401 応答が見られる場合、この設定を増やして 401 応答の発生回数を抑える必要があります。

   • Status endpoint backend timeout seconds: バックエンドに接続しようとする際に、ステータスエンドポイントが待機するタイムアウト (秒単位)。
   • Status endpoint backend verify: ステータスのために個々のノードを呼び出すときに、サービスの SSL 証明書を検証するかどうかを指定します。
   • Resource client request timeout: リソースクライアントが接続を形成した後に要求をドロップするまでのタイムアウト (秒単位)。
   • Request timeout: プロキシーがタイムアウトを報告して 504 を生成するまでの時間を秒単位で指定します。

   • Manage organization auth: 組織管理者がユーザーとチームを作成および管理する特権を持つかどうかを制御します。LDAP または SAML インテグレーションを使用している場合は、この機能を無効化することを推奨します。

     重要

     MANAGE_ORGANIZATION_AUTH 設定は、Ansible Automation Platform 2.4 から 2.6 へのアップグレード中にプラットフォームゲートウェイに移動されます。ただし、移行後、プラットフォームゲートウェイと Automation Controller の間で値は自動的に同期されません。管理上の問題を避けるため、特に自動化ワークフローを Automation Controller に対して直接実行する場合は、両方の環境で MANAGE_ORGANIZATION_AUTH の値を一致させます。

   • Stream idle timeout:Ansible Automation Platform Lightspeed チャットボットなどのアイドルストリーミング接続のタイムアウト (秒単位)。この期間内にデータが送信されない場合、ストリームは閉じられます。
   • Max stream duration: Ansible Automation Platform Lightspeed チャットボットなどのストリーミング接続の合計最大期間 (秒単位)。この期間を過ぎると、アクティビティーに関係なくストリームは閉じられます。
   • Aap deployment type: この AAP インスタンスのデプロイメントタイプ。
5. Save platform gateway settings をクリックして変更を保存するか、利用可能な他のプラットフォームオプションの設定に進みます。