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

21.1. Azure Active Directory (AD)¶

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

1. Ansible Tower ユーザーインターフェースの設定 () メニュー画面から 認証 をクリックします。

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

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

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

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

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

21.2. LDAP 認証¶

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

21.3. RADIUS 認証設定¶

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

1. Ansible Tower ユーザーインターフェースの設定 () メニュー画面から 認証 をクリックします。

デフォルトでは、Azure AD タブが最初に表示されます。

2. Radius タブを選択します。

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

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

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

21.4. SAML 認証設定¶

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

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

SAML 認証の設定方法:

1. Ansible Tower ユーザーインターフェースの設定 () メニュー画面から 認証 をクリックします。

デフォルトでは、Azure AD タブが最初に表示されます。

2. SAML タブを選択します。

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

4. SAML Service Provider Entity ID は、Tower Base URL と同じように設定します。Tower Base URL は、設定 アイコンからアクセス可能な Tower の設定画面の システム タブにあります。API では、TOWER_BASE_URL 変数の /api/v2/settings/system で確認できます。エンティティー ID は、個別の Tower クラスターノードの 1 つに設定できますが、サービスプロバイダーの URL に設定することが推奨されます。Base URL は、ロードバランサーの FQDN (使用する場合) と一致させるようにしてください。

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

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

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

パブリック証明書の例:

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

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

秘密鍵の例:

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

7. SAML サービスプロバイダーの組織情報 フィールドで、SSO プロセス中に Tower クラスターに関する詳細を 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 Enabled Identity Providers フィールドでは、一覧の各 ID プロバイダーの接続方法に関する情報を指定します。以下の例では、Tower に以下の 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 属性、ユーザー名属性またはカスタムの一意識別名が Tower ノードに送信される場合は name_id に設定します。

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

• url: シングルサインオン (SSO) が有効な場合に Tower がユーザーをリダイレクトする 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 プロバイダーが使用する特別な属性で、一意のユーザー識別子が何であるかをサービスプロバイダー (Tower クラスター) に渡します。これを使用する場合には、例にあるように、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 属性を使用して、ユーザーを特定しますが、この属性は Tower では読み込みできない属性です。Tower は一意の識別名、つまり URN は理解します。以下の例にあるように、ユーザー属性の SAML の「Name」属性に記載の URL を使用します。

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

12. Tower は、Tower へのログイン時に、ユーザーに関連するチームや組織のメンバーシップなどの特定の属性を検索するように設定できます。これらの属性名は、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>

以下は、対応する Tower の設定です。

{
  "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: Tower チーム -> Tower 組織からのマッピングを定義する { "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"
}

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

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

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

Tower は、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. 完了したら 保存 をクリックします。

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

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

    

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

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

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

2. IdP-initiated ログインが機能したら、Ansible Tower ユーザーインターフェースのシステムウィンドウの設定 () メニューで、ログインリダイレクトオーバーライド URL フィールドを使用して、デフォルトの Tower ログインページ以外の場所に、ログインしていないユーザーをリダイレクトする URL を指定します。以下の例のように、透過的な SAML ログインには、これは /sso/login/saml/?idp=<name-of-your-idp> に設定する必要があります。

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

21.5. TACACS+ 認証テスト¶

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

1. Ansible Tower ユーザーインターフェースの設定 () メニュー画面から 認証 をクリックします。

デフォルトでは、Azure AD タブが最初に表示されます。

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. 完了したら 保存 をクリックします。