22. エンタープライズ認証の設定¶

22.1. Azure AD 設定¶

Microsoft Azure Active Directory (AD) のエンタープライズ認証を設定するには、Azure (https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app.) から組織所有のアプリケーションを登録して、OAuth2 キーとシークレットを取得する必要があります。キーとシークレットはいずれも、一意のアプリケーションに所属して、異なる認証バックエンドで供給したり、再利用したりできません。アプリケーションを登録するには、Web ページの URL と合わせて指定する必要があります。この URL は、設定認証画面に表示されるコールバック URL です。

1. 左側のナビゲーションバーで 設定 をクリックします。

2. 設定ウィンドウの左側で、認証オプションの一覧から Azure AD の設定 をクリックします。

3. Azure AD OAuth2 コールバック URL には、事前に情報が入力されており、編集できません。アプリケーションを登録すると、Azure はアプリケーション ID およびオブジェクト ID を表示します。

4. 編集 をクリックし、Azure AD OAuth2 キー フィールドに Azure のアプリケーション ID をコピーアンドペーストします。

   お使いのアプリとMicrosoft Azure Active Directory のリンクに関する Azure AD ドキュメントに従い、認証用に、キー (1 度だけ表示) をクライアントに提供します。

5. 設定の認証画面にある Azure AD OAuth2 Secret フィールドに、Azure AD アプリケーション用に作成した実際のシークレットキーをコピーアンドペーストします。

6. マッピングフィールドの入力に関する情報は、「組織およびチームマッピング」を参照してください。

7. 完了したら 保存 をクリックします。

8. 認証が正しく設定されたかどうかは、automation controller からログアウトします。ログイン画面に、Microsoft Azure のロゴが表示され、Azure の認証情報を使用してログインできるようになっていることを確認してください。

Azure AD で Basics を登録するアプリケーションについては、「Azure AD Identity Platform (v2) の概要」を参照してください。

22.2. LDAP 認証¶

「LDAP 認証の設定」セクションを参照します。

22.3. RADIUS 設定¶

automation controller は、認証情報のソースとして、RADIUS を一元的に使用するように設定することができます。

1. 左側のナビゲーションバーで 設定 をクリックします。

2. 設定ウィンドウの左側で、認証オプションの一覧から RADIUS 設定 をクリックします。

3. 編集 をクリックし、Radius サーバー フィールドに Radius サーバーのホストまたは IP を入力してください。このフィールドを空の状態にすると、Radius 認証は無効になります。

4. 次の 2 つのフィールドには、ポートとシークレットの情報を入力します。

5. 完了したら 保存 をクリックします。

22.4. SAML 設定¶

SAML を使用すると、ID プロバイダー(IdP - シングルサインオンサービスを提供するサーバーシステム) とサービスプロバイダー (今回の場合は automation controller) の間で認証および承認データを交換できます。automation controller は、コントローラーユーザーの認証用に (作成/ログイン/ログアウト) に SAML と通信するように設定できます。ユーザーチームや、組織のメンバーシップは、コントローラーへの SAML の応答に埋め込むことができます。

以下では、automation controller がサービスプロバイダーとして機能することについて説明します。RHSSO (keycloak) でユーザーを認証する方法は、「Red Hat Single Sign On Integration with the Automation Controller」のブログを参照してください。

SAML 認証の設定方法:

1. 左側のナビゲーションバーで 設定 をクリックします。

2. 設定ウィンドウの左側で、認証オプションのリストから SAML 設定 をクリックします。

3. SAML Assertion Consume Service (ACS) URL および SAML Service Provider Metadata URL フィールドには、事前にデータが入力されており、編集できません。アイデンティティープロバイダーの管理者に問い合わせて、これらのフィールドの情報を指定してください。

4. 編集 をクリックし、左側のナビゲーションバーから 設定 をクリックして、その他のシステム設定ウィンドウにある コントローラーホストの Base URL と同じになるように、**SAML サービスプロバイダーエンティティー ID* を設定します。API では、/api/v2/settings/system の CONTROLLER_BASE_URL 変数の下で確認できます。エンティティー ID は、個別のコントローラーのクラスターノードの 1 つに設定可能ですが、サービスプロバイダーの URL に設定することが推奨されます。Base URL は、ロードバランサーの FQDN (使用する場合) と一致させるようにしてください。

以下の例では、サービスプロバイダーはコントローラークラスターであるため、ID はコントローラークラスター FQDN に設定されています。

5. Ansible クラスターのサーバー証明書を作成します。通常、Ansible クラスターの設定時にコントローラーノードは HTTP トラフィックのみを処理するように設定され、ロードバランサーは SSL ターミネーションポイントとなります。今回の場合は、SSL 証明書が個別のコントローラーノード用ではなく、ロードバランサー用に必要となります。SSL は個別のコントローラーノードごとに有効化または無効化できますが、SSL でターミネーションされたロードバランサーを使用する場合には SSL は無効にする必要があります。定期的に証明書を更新しなくても良いように、期限のない自己署名証明書を使用することが推奨されます。こうすることで、証明書を更新し忘れても認証は失敗しません。

証明書で CA バンドルを使用する場合には、このフィールドにバンドル全体の情報を追加してください。

パブリック証明書の例:

-----BEGIN CERTIFICATE——
... cert text ...
-----END CERTIFICATE——

6. コントローラーをサービスプロバイダー (SP) として使用するために任意の秘密鍵を作成して、SAML サービスプロバイダーの秘密鍵 フィールドに入力します。

秘密鍵の例:

-----BEGIN PRIVATE KEY--
... key text ...
-----END PRIVATE KEY——

7. SAML サービスプロバイダーの組織情報 フィールドで、SSO プロセス中にコントローラークラスターに関する詳細を IdP に指定します。

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

たとえば、以下のようになります。

8. SAML Service Provider Technical Contact フィールドで、技術に関する問い合わせ情報を IdP に指定します。フィールドの内容は削除しないでください。

{
"givenName": "Some User",
"emailAddress": "[email protected]"
}

たとえば、以下のようになります。

9. SAML Service Provider Support Contact フィールドにサポートの問い合わせ情報を IdP に指定します。このフィールドの内容は削除しないでください。

{
"givenName": "Some User",
"emailAddress": "[email protected]"
}

たとえば、以下のようになります。

10. SAML で有効にされたアイデンティティープロバイダー フィールドでは、一覧の各 ID プロバイダーの接続方法に関する情報を指定します。以下の例では、コントローラーに以下の SAML 属性を指定する必要があります。

Username(urn:oid:0.9.2342.19200300.100.1.1)
Email(urn:oid:0.9.2342.19200300.100.1.3)
FirstName(urn:oid:2.5.4.42)
LastName(urn:oid:2.5.4.4)

これらの属性が不明な場合には、既存の SAML 属性に姓名、電子メール、ユーザー名をマッピングしてください。

IdP ごとに必要なキーを設定します。

• attr_user_permanent_id: ユーザーの一意識別名。IdP から送信された属性のいずれかに一致するように設定します。通常、 SAML:nameid 属性、ユーザー名属性、またはカスタムの一意識別名がコントローラーノードに送信される場合は name_id に設定します。

• entity_id: ID プロバイダーの管理者が指定したエンティティー ID。管理者がコントローラーの SAML プロファイルを作成し、一意 URL が作成されます。

• url - シングルサインオン (SSO) が有効な場合にコントローラーがユーザーをリダイレクトする SSO の URL。

• x509_cert: ID プロバイダーで作成した SAML プロファイルをもとに生成された IdP 管理者が提供する証明書。--BEGIN CERTIFICATE-- および --END CERTIFICATE-- ヘッダーを削除してから、改行なしの文字列 1 つで証明書を入力します。

SAML IdP は、複数サポートされています。一部の IdP はデフォルト OID とは異なる属性名を使用してユーザーデータを提供することがあります (https://github.com/omab/python-social-auth/blob/master/social/backends/saml.py)。SAML NameID は、ID プロバイダーが使用する特別な属性で、一意のユーザー識別子が何であるかをサービスプロバイダー (コントローラークラスター) に渡します。これを使用する場合には、例にあるように、attr_user_permanent_id を name_id に設定してください。他の属性名は、以下に記載の IdP ごとに上書きされる可能性があります。

{
"myidp": {
  "entity_id": "https://idp.example.com",
  "url": "https://myidp.example.com/sso",
  "x509cert": ""
},
"onelogin": {
  "entity_id": "https://app.onelogin.com/saml/metadata/123456",
  "url": "https://example.onelogin.com/trust/saml2/http-post/sso/123456",
  "x509cert": "",
  "attr_user_permanent_id": "name_id",
  "attr_first_name": "User.FirstName",
  "attr_last_name": "User.LastName",
  "attr_username": "User.email",
  "attr_email": "User.email"
  }
}

注釈

IdP は、既知の SAML URN を使用してメールおよび姓名を提供します。IdP は、カスタムの SAML 属性を使用して、ユーザーを特定しますが、この属性はコントローラーでは読み込みできない属性です。コントローラーは一意の識別名、つまり URN は理解します。以下の例にあるように、ユーザー属性の SAML の「Name」属性に記載の URL を使用します。

11. オプションで SAML 組織マップ を指定します。詳細は、「組織およびチームマッピング」を参照してください。

12. コントローラーは、コントローラーへのログイン時に、ユーザーに関連するチームや組織のメンバーシップなどの特定の属性を検索するように設定できます。これらの属性名は、SAML 組織属性マッピング フィールドや SAML チーム属性マッピング フィールドで定義します。

** SAML 組織属性のマッピングの例**

以下の例は、属性 member-of にユーザー組織メンバーシップを埋め込む SAML 属性です。

<saml2:AttributeStatement>
    <saml2:Attribute FriendlyName="member-of" Name="member-of"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml2:AttributeValue>Engineering</saml2:AttributeValue>
        <saml2:AttributeValue>IT</saml2:AttributeValue>
        <saml2:AttributeValue>HR</saml2:AttributeValue>
        <saml2:AttributeValue>Sales</saml2:AttributeValue>
    </saml2:Attribute>
    <saml2:Attribute FriendlyName="admin-of" Name="admin-of"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml2:AttributeValue>Engineering</saml2:AttributeValue>
    </saml2:Attribute>
</saml2:AttributeStatement>

以下は、対応するコントローラー設定です。

{
  "saml_attr": "member-of",
  "saml_admin_attr": "admin-of",
  "remove": true,
  "remove_admins": false
}

saml_attr: 組織アレイが含まれる SAML 属性名で、remove を True に設定すると、組織の一覧にユーザーを追加する前に全組織からユーザーを削除します。ユーザーを組織にそのまま所属させた状態で、SAML 属性の組織にユーザーを追加する場合には、remove は False に指定します。

saml_admin_attr: saml_attr 属性と同様ですが、組織のメンバーシップを指定する代わりに、この属性は管理者の組織パーミッションを指定します。

SAML チーム属性のマッピングの例

以下は、リスト内のチームメンバーシップを含む SAML 属性の例です。

<saml:AttributeStatement>
     <saml:Attribute
        xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
        x500:Encoding="LDAP"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
        FriendlyName="eduPersonAffiliation">
        <saml:AttributeValue
            xsi:type="xs:string">member</saml:AttributeValue>
        <saml:AttributeValue
            xsi:type="xs:string">staff</saml:AttributeValue>
        </saml:Attribute>
</saml:AttributeStatement>

{
    "saml_attr": "eduPersonAffiliation",
    "remove": true,
    "team_org_map": [
    {
        "team": "member",
        "organization": "Default1"
    },
    {
        "team": "staff",
        "organization": "Default2"
    }
  ]
}

• saml_attr: チームアレイが含まれる SAML 属性名。

• remove: remove は True に設定して、チームの一覧にユーザーを追加する前に、全チームからユーザーを削除します。ユーザーを組織にそのまま所属させた状態で、SAML 属性の組織にユーザーを追加する場合には、remove は False に指定します。

• team_org_map: コントローラーチーム -> コントローラー組織からのマッピングを定義する { "team": "<AWX Team Name>", "organization": "<AWX Org Name>" } フォームのディクショナリーアレイ。これは、複数の組織に同じ名前のチームが存在できるため必要です。SAML 属性にリストされたチームが所属する組織は、このマッピングがないと曖昧になってしまいます。

SAML チーム属性マッピング でチームと組織の両方をオーバーライドするエイリアスを作成できます。このオプションは、以下の例のように、SAML バックエンドが複雑なグループ名を送信する場合に非常に便利です。

{
 "remove": false,
 "team_org_map": [
  {
   "team": "internal:unix:domain:admins",
   "organization": "Default",
   "team_alias": "Administrators"
  },
  {
   "team": "Domain Users",
   "organization_alias": "OrgAlias",
   "organization": "Default"
  }
 ],
 "saml_attr": "member-of"
}

ユーザーが認証されると、コントローラーは期待どおりに組織とチームのエイリアスを作成します。

13. オプションで、SAML チームマップ フィールドにチームのメンバーシップマッピングを指定します。詳細は、「組織およびチームマッピング」を参照してください。

14. オプションで SAML セキュリティー設定 フィールドに、セキュリティー設定を指定します。このフィールドは、API の SOCIAL_AUTH_SAML_SECURITY_CONFIG フィールドと同じです。詳細は、「OneLogin's SAML Python Toolkit 」を参照してください。

コントローラーは、SAML 経由でユーザーがログインした場合に python-social-auth ライブラリーを使用します。このライブラリーは、python-saml ライブラリーに依存し、次の SAML サービスプロバイダーの追加設定データ と SAML IDP の extra_data 属性へのマッピング の任意フィールドの設定で利用できるようにします。

15. SAML Service Provider Extra Configuration Data フィールドは、API の SOCIAL_AUTH_SAML_SP_EXTRA と同じです。有効なサービスプロバイダーの extra (SP_EXTRA) パラメーターに関する詳細は、「python-saml library documentation 」を参照してください。

16. SAML IDP の extra_data 属性へのマッピング フィールドは、API の SOCIAL_AUTH_SAML_EXTRA_DATA と同じです。詳細は、Python の「SAML Advanced Settings ドキュメント」を参照してください。

17. SAML ユーザーフラグ属性マッピング フィールドを使用すると、SAML ロールと属性を特別なユーザーフラグにマップできます。このフィールドでは、次の属性が有効です。

• is_superuser_role: ユーザーにスーパーユーザーフラグを付与する 1 つ以上の SAML ロールを指定します。

• is_superuser_attr: ユーザーにスーパーユーザーフラグを付与する SAML 属性を指定します。

• is_superuser_value: ユーザーがスーパーユーザーであるために要求される is_superuser_attr に必要な特定の値を 1 つ以上、指定します。

• remove_superusers: ユーザーのスーパーユーザーフラグを削除する必要があるかどうかを示すブール値。デフォルトは``true``. (詳細は下記参照)

• is_system_auditor_role: ユーザーにシステム監査人フラグを付与する SAML ロールを指定します。

• is_system_auditor_attr: ユーザーにシステム監査人フラグを付与する SAML 属性を指定します。

• is_system_auditor_value: ユーザーがシステム監査人になるために要求される is_system_auditor_attr に必要な特定の値を 1 つ以上、指定します。

• remove_system_auditors: ユーザーに対して system_auditor フラグを削除する必要があるかどうかを示すブール値。デフォルトは``true``. (詳細は下記参照)

role``と``value``フィールドはリストであり、`or` ロジックです。したがって、2 つのロールを指定すると、`[ "Role 1", "Role 2" ]` のようになります。SAML ユーザーには、フラグに必要なロールがあるとロジックが見なすいずれかのロールがあります。`[ "Value 1", "Value 2"]` を指定する場合は、これは ``value フィールドです。この場合、SAML ユーザーの属性にいずれかの値があり、ロジックは属性値が一致したと見なします。

role と attr の両方が superuser または system_auditor のいずれかに対して指定されている場合、attr の設定は role よりも優先されます。システム管理者およびシステム監査者のロールは、SAML ユーザーのログイン時に評価されます。SAML 設定ではなく、UI でこれらのロールの 1 つを SAML ユーザーに付与すると、remove フラグが false に設定されていない限り、ロールはユーザーの次回ログイン時に削除されます。remove フラグが false に設定されている場合は、SAML アダプターは対応するフラグをユーザーから削除できません。以下の表は、そのロジックがどのように機能するか説明しています。

SAML ユーザーが automation controller に認証される度にこれらのチェックが実行され、必要に応じてユーザーフラグが変更されます。もしも、UI 内で System Administrator また System Auditor が SAML ユーザー用に設定されている場合、SAML アダプターは上記のルールに基づいて UI 設定をオーバーライドします。SAML ユーザーのログイン時に SAML ユーザーのユーザーフラグが削除されないようにしたい場合は、remove_ にフラグを false に設定します。remove フラグを false に設定した場合、UI、API、または SAML アダプターのいずれかを介してユーザーフラグ true に設定すると、削除されることはありません。ただし、ユーザーがフラグを持っておらず、上記のルールによってフラグを追加する必要があると判断された場合は、フラグが false でも追加されます。

例:

{
    "is_superuser_attr": "blueGroups",
    "is_superuser_role": ["is_superuser"],
    "is_superuser_value": ["cn=My-Sys-Admins,ou=memberlist,ou=mygroups,o=myco.com"],
    "is_system_auditor_attr": "blueGroups",
    "is_system_auditor_role": ["is_system_auditor"],
    "is_system_auditor_value": ["cn=My-Auditors,ou=memberlist,ou=mygroups,o=myco.com"]
}

18. 完了したら 保存 をクリックします。

19. 認証が正しく設定されていることを確認するには、SAML Service Provider Metadata URL にある、自動生成された URL をブラウザーで読み込みます。すると、XML の出力が表示されるはずです。表示されない場合には正しく設定されていません。

    または、automation controller をログアウトしてください。ログアウトすると、automation controller への別のログイン方法として、ログイン画面に SAML のロゴが表示されているはずです。

    

22.4.1. 透過的な SAML ログイン¶

透過的なログインを機能させるには、まず IdP-initiated ログインを機能させる必要があります。これには、以下を実行します。

1. 上記の例で先ほど説明したように、IdP の RelayState を SAML Enabled Identity Providers フィールドの IdP 定義のキーに設定します。RelayState は myidp または onelogin のいずれかでなければなりません。

2. これが機能したら、左側のナビゲーションバーからアクセスできる 設定 メニューのその他の認証設定にある ログインリダイレクトオーバーライド URL フィールドを使用して、デフォルトのコントローラーログインページ以外の場所に、ログインしていないユーザーをリダイレクトする URL を指定します。以下の例のように、透過的な SAML ログインには、これを /sso/login/saml/?idp=<name-of-your-idp> に設定する必要があります。

注釈

上記は通常の IdP 形式の例ですが、特定のケースの正しい形式になるわけではありません。この URL はすべての IdP で同じではないため、正しい透過的なリダイレクト URL に到達することが必要になる場合があります。

3. 透過的な SAML ログインが設定されたら、ローカルの認証情報または異なる SSL を使用して直接 https://<your-tower-server>/login に移動すると、SSO 認証ボタンを含む標準のコントローラーログインページが表示され、設定した方法でログインできるようになります。

22.5. TACACS+ 設定¶

Terminal Access Controller Access-Control System Plus (TACACS+) は、リモート認証と集中型のサーバーでネットワークアクセス制御を行うための関連のサービスを処理するプロトコルです。特に、TACACS+ は認証、Authentication (認証)、Authorization (許可)、Accounting (課金やユーザーのアクセス情報の収集) サービスを提供し、automation controller が認証のソースとして使用されるように設定します。

1. 左側のナビゲーションバーで 設定 をクリックします。

2. 設定ウィンドウの左側で、認証オプションの一覧から TACACS+ 設定 をクリックします。

3. 編集 をクリックし、以下のフィールドに情報を入力します。

• TACACS+ Server: 認証する TACACS+ サーバーのホスト名または IP アドレスを指定します。このフィールドを空のままにすると、TACACS+ 認証が無効になります。

• TACACS+ Port: TACACS+ はデフォルトでポート49 を使用するので、事前に入力されています。

• TACACS+ Secret: TACACS+ 認証サーバーの秘密鍵

• TACACS+ Auth Session Timeout: セッションのタイムアウトの値は秒単位です。デフォルトは 5 秒です。

• TACACS+ Authentication Protocol: TACACS+ クライアントが使用するプロトコル。オプションは ascii または pap です。

4. 完了したら 保存 をクリックします。

22.6. Generic OIDC settings¶

Similar to SAML, OpenID Connect (OIDC) is uses the OAuth 2.0 framework. It allows third-party applications to verify the identity and obtain basic end-user information. The main difference between OIDC and SMAL 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 setup OIDC with controller, refer to the documentation from the identity provider (IdP) of your choice that has OIDC support.

To configure OIDC in controller:

1. 左側のナビゲーションバーで 設定 をクリックします。

2. On the left side of the Settings window, click Generic OIDC settings from the list of Authentication options.

3. 編集 をクリックし、以下のフィールドに情報を入力します。

• OIDC Key: Client ID from your 3rd-party IdP.

• OIDC Secret: Client Secret from your IdP.

• OIDC Provider URL: URL for your OIDC provider.

• Verify OIDC Provider Certificate: Use the toggle to enable/disable the OIDC provider SSL certificate verification.

The example below shows specific values associated to GitHub as the generic IdP:

4. 完了したら 保存 をクリックします。

5. To verify that the authentication was configured correctly, logout of automation controller and the login screen will now display the OIDC logo to indicate it as a alternate method of logging into automation controller.