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

このセクションでは、以下のエンタープライズシステムの認証の設定について説明します。

Azure Active Directory (AD)
LDAP 認証
RADIUS 認証設定
SAML 認証設定
TACACS+ 認証テスト

注釈

LDAP 認証については「LDAP 認証の設定」を参照してください。

SAML、RADIUS および TACACS+ ユーザーは 'Enterprise' ユーザーとして分類されます。以下のルールがエンタープライズユーザーに適用されます。

エンタープライズユーザーは、リモートの認証バックエンドからのログインに初めて成功した場合にのみ作成できます。
Tower 内にエンタープライズ以外のユーザーが同じ名前で作成されている場合は、エンタープライズユーザーは作成/認証できません。
エンタープライズバックエンドが有効になっている場合には、エンタープライズユーザーの Tower パスワードは常に空でなければならず、ユーザーによる設定はできません。
エンタープライズバックエンドが無効の場合には、パスワードフィールドを設定してエンタープライズユーザーを通常の Tower ユーザーに変更できます。ただし、切り替えられた Tower ユーザーはエンタープライズユーザーとみなされないので、この操作は元に戻すことはできません。

19.1. Azure Active Directory (AD)¶

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

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

すでにデフォルトビューになっていない場合には、Azure AD タブを選択します。

_images/configure-tower-auth-azure-select.png

Azure AD OAuth2 コールバック URL フィールドには、事前に情報が入力されており、編集できません。

アプリケーションが登録されたら、Azure はアプリケーション ID とオブジェクト ID を表示します。

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

Azure AD のドキュメント『Connect your app to Microsoft Azure Active Directory: Create the Key』に従い、認証用にクライアントにキー (一度のみ表示) を指定します。

Tower の設定の認証画面にある Azure AD OAuth2 Secret フィールドに、Azure AD アプリケーション用に作成した実際のシークレットキーをコピーアンドペーストします。
マッピングフィールドの入力に関する情報は、「組織およびチームマッピング」を参照してください。
完了したら保存をクリックします。
認証が正しく設定されたかどうかは、Ansible Tower からログアウトします。ログイン画面に、Microsoft Azure のロゴが表示され、Azure の認証情報を使用してログインできるようになっていることを確認してください。

Azure AD でのアプリケーションの登録の基本については、https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-scenarios#basics-of-registering-an-application-in-azure-ad を参照してください。

19.2. LDAP 認証 ¶

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

19.3. RADIUS 認証設定 ¶

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

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

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

Radius タブを選択します。

_images/configure-tower-auth-radius-select.png

Radius Server フィールドに Radius サーバーのホストまたは IP を入力してください。このフィールドを空の状態にすると、Radius 認証は無効になります。
次の 2 つのフィールドには、ポートとシークレットの情報を入力します。
完了したら保存をクリックします。

19.4. SAML 認証設定 ¶

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

_images/configure-tower-auth-saml-topology.png

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

SAML 認証の設定方法:

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

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

SAML タブを選択します。

_images/configure-tower-auth-saml-select.png

SAML Assertion Consume Service (ACS) URL および SAML Service Provider Metadata URL フィールドには、事前にデータが入力されており、編集できません。アイデンティティープロバイダーの管理者に問い合わせて、これらのフィールドの情報を指定してください。
SAML Service Provider Entity ID は、Tower Base URL と同じに設定します。Tower Base URL は、設定アイコンからアクセス可能な Tower の設定画面の システム タブにあります。API では、/api/v2/settings/system の TOWER_BASE_URL 変数で確認できます。エンティティー ID は、個別の Tower クラスターノードの 1 つに設定可能ですが、サービスプロバイダーの URL に設定することが推奨されます。Base URL は、ロードバランサーの FQDN (使用する場合) と一致させるようにしてください。

注釈

Tower Base URL は、クラスター内のノードごとに異なります。通常、ロードバランサーは単一のエントリーのポイント (Tower クラスター FQDN) となるように多数の Tower クラスターノードの配置されます。SAML サービスプロバイダーは、送信接続を確立して、SAML Service Provider Entity ID で設定された Tower クラスターノードまたは Tower クラスター FQDN にルートします。

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

_images/configure-tower-auth-saml-spentityid.png

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

注釈

SAML サービスプロバイダーの公開証明書 フィールドには、「-----BEGIN CERTIFICATE-----」および「-----END CERTIFICATE-----」など、証明書全体を含める必要があります。

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

_images/configure-tower-auth-saml-cert.png

パブリック証明書の例:

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

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

秘密鍵の例:

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

SAML Service Provider Organization Info フィールドで、SSO プロセス中に Tower クラスターに関する詳細を IdP に指定します (任意)。

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

例:

_images/configure-tower-auth-saml-org-info.png

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

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

例:

_images/configure-tower-auth-saml-techcontact-info.png

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

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

例:

_images/configure-tower-auth-saml-suppcontact-info.png

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"
  }
}

_images/configure-tower-auth-saml-idps.png

注釈

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

_images/configure-tower-auth-saml-idps-urn.png

オプションで SAML 組織マップ に指定します。詳細は、「組織およびチームマッピング」を参照してください。
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 の設定です。

{
    "SOCIAL_AUTH_SAML_ORGANIZATION_ATTR": {
        "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 セキュリティー設定 フィールドに、セキュリティー設定を指定します。このフィールドは、API の SOCIAL_AUTH_SAML_SECURITY_CONFIG フィールドと同じです。詳細は、「OneLogin's SAML Python Toolkit 」を参照してください。

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

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

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

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

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

19.5. TACACS+ 認証テスト ¶

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

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

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

TACACs+ タブを選択します。

_images/configure-tower-auth-tacacs-select.png

以下のフィールドに情報を入力します。

TACACS+ Server: 認証する TACACS+ サーバーのホスト名または IP アドレスを指定します。このフィールドを空のままにすると、TACACS+ 認証が無効になります。
TACACS+ Port: TACACS+ はデフォルトでポート49 を使用するので、事前に入力されています。
TACACS+ Secret: TACACS+ 認証サーバーの秘密鍵
TACACS+ Auth Session Timeout: セッションのタイムアウトの値は秒単位です。デフォルトは 5 秒です。
TACACS+ Authentication Protocol: TACACS+ クライアントが使用するプロトコル。オプションは ascii または pap です。

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

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

19.1. Azure Active Directory (AD)¶

19.2. LDAP 認証¶

19.3. RADIUS 認証設定¶

19.4. SAML 認証設定¶

19.5. TACACS+ 認証テスト¶

19.2. LDAP 認証 ¶

19.3. RADIUS 認証設定 ¶

19.4. SAML 認証設定 ¶

19.5. TACACS+ 認証テスト ¶