Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

3.6. マッピング

Ansible Automation Platform サーバーにアクセスできるユーザーを制御し、ユーザーの属性 (ユーザー名やメールアドレスなど) や所属するグループに基づいて Ansible Automation Platform 組織またはチームに配置するには、オーセンティケーターマップを設定します。

オーセンティケーターマップを使用すると、ユーザーにリソースタイプへのアクセスを許可または拒否する前に満たす必要がある条件を追加できます。オーセンティケーターマップはオーセンティケーターに関連付けられ、順序が与えられます。ユーザーがログインすると、マップは順番に処理されます。これらは、ファイアウォールルールやメールフィルターのようなものだと考えることができます。

3.6.1. オーセンティケーターマッピングについて

認証
通常はユーザー名とパスワード、または信頼システムを通じてユーザーのアイデンティティーを検証します。
認可
認証されたユーザーが認証後に実行できる操作を決定します。

Ansible Automation Platform では、オーセンティケーターが認証を管理し、ユーザーを検証して、ユーザー名、ファーストネーム、メールアドレス、グループメンバーシップ (LDAP グループなど) などの詳細を返します。認可は、オーセンティケーターの関連マップに基づいて行われます。

認証プロセス中、ユーザーが認証されると、認可システムがメモリー内のデフォルトの権限セットを使用して起動します。次に、オーセンティケーターマップが順番に処理され、トリガー条件に基づいて権限が調整されます。すべてのオーセンティケーターのマップが処理されると、ユーザーの権限のメモリー内表現が既存の権限と調整されます。

たとえば、次のような簡略化されたデフォルト権限のメモリー内表現があるとします。

Copy to Clipboard Toggle word wrap 
Access allowed = True
Superuser permission = Undefined
Admin of teams = None

また、処理する必要があるマップを、次の順序で処理するとします。

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

許可しない設定の最初の 許可 マップは、システムへのアクセスを拒否します。メモリー内の表現は次のようになります。

Copy to Clipboard Toggle word wrap 
Access allowed = False
Superuser permission = Undefined
Admin of teams = None

しかし、ユーザーが 2 番目の 許可 マップ (グループベースの許可) にマッチする場合、権限が次のように変更されます。

Copy to Clipboard Toggle word wrap 
Access allowed = True
Superuser permission = Undefined
Admin of teams = None

その後、ユーザーは必要なグループに属しているため、Ansible Automation Platform へのアクセス権が付与されます。

次に、スーパーユーザー マップがユーザーの属性をチェックします。マッチが見つからない場合、デフォルトでは既存の権限は取り消されません。したがって、権限は前のマップの結果と同じままです。

Copy to Clipboard Toggle word wrap 
Access allowed = True
Superuser permission = Skipped
Admin of teams = None

スーパーユーザーアクセスを取り消すには、スーパーユーザー マップの Revoke オプションを選択します。そうすることで、ユーザーが属性の基準を満たさない場合、次のように権限が False に更新されます。

Copy to Clipboard Toggle word wrap 
Access allowed = True
Superuser permission = False
Admin of teams = None

最後の チーム マップは、オーセンティケーターから取得したユーザーのグループをチェックし、チーム “My Team” への管理者アクセス権を確認します。ユーザーが必要なグループに属している場合、権限が次のように更新されます。

Copy to Clipboard Toggle word wrap 
Access allowed = True
Superuser permission = False
Admin of teams = “My Team”

ユーザーが必要なグループに属していない場合、マップの Revoke オプションが選択されていない限り、権限は変更されません。このオプションが選択されている場合は、権限が次のように更新されます。

Copy to Clipboard Toggle word wrap 
Access allowed = True
Superuser permission = False
Admin of teams = Revoke admin of “My Team”

定義された順序ですべてのマップが処理された後、最終的な権限が調整され、マップルールに基づいてユーザーのアクセスが更新されます。

要約すると、オーセンティケーターはユーザーを検証し、システム認可をオーセンティケーターマップに委譲します。オーセンティケーターマップは順番に実行され、ユーザーの権限のメモリー内表現が作成されます。この表現は、すべてのマップが実行された後に実際の権限と調整されます。

デフォルトでは、オーセンティケーターマップは ALLOW または SKIPPED のいずれかを返します。

ALLOW
マッチが検出され、対応するロールまたは権限 (スーパーユーザーやチームメンバーなど) へのアクセスをユーザーに許可する必要があることを意味します。
SKIPPED
ユーザーがマップ内のトリガーにマッチしなかったことを意味します。このマップの処理はスキップされ、残りのマップのチェックが続行されます。これは、オーセンティケーターマップを変更せずに、システム内の追加の権限をユーザーに付与する場合に便利です。

ただし、Revoke オプションを選択すると、SKIPPED は DENY になり、必要なトリガー条件を満たさないユーザーに対して、対応するロールまたは権限へのアクセスが拒否されます。これにより、トリガー条件にマッチするユーザーにのみアクセスが許可されます。

3.6.2. オーセンティケーターマップの種類

Ansible Automation Platform は、次のルールタイプをサポートしています。

Allow
ユーザーにシステムへのログインを許可するかどうかを決定します。
Organization
ユーザーを組織に配置する必要があるかどうかを決定します。
Team
ユーザーをチームのメンバーにする必要があるかどうかを決定します。
Role
ユーザーがロールのメンバーであるかどうかを決定します (System Auditor など)。
Is Superuser
ユーザーがシステムのスーパーユーザーであるかどうかを決定します。

これらのオーセンティケーターマップタイプは、あらゆるタイプのオーセンティケーターで使用できます。

3.6.3. オーセンティケーターマップトリガー

各マップには、マップがいつ true として評価されるかを定義するトリガーがあります。トリガーの種類は次のとおりです。

Always
トリガーは常に起動される必要があります。
Never
トリガーを決して起動しません。
Group

ユーザーがソースシステムにグループを持っているか、持っていないか、または複数のグループを持っているかに基づいて、マップが true または false になります。Group トリガーの使用は、オーセンティケーターマップの例 を参照してください。

グループトリガーを定義すると、認証マッピングが拡張され、次の選択項目が追加されます。

  • Operation: このフィールドには、指定した Groups 条件に基づいてルールの処理をトリガーする条件設定を含めます。選択肢には and と or があります。たとえば、and を選択した場合、このトリガーが true になるには、ログインするユーザーが Groups フィールドに指定されたすべてのグループのメンバーである必要があります。or を選択した場合、トリガーを起動するには、ログインするユーザーが、指定されたいずれかの Groups のメンバーである必要があります。

    注記

    1 つのグループのみを条件として使用する場合は、"and" または "or" のどちらを選択しても問題ありません。

  • Groups: これは、ユーザーが属している必要がある、認証システムからの 1 つ以上のグループのリストです。Groups エントリーを初めて作成するときは、値を手動で入力する必要があります。入力すると、その選択項目を Groups リストから利用できるようになります。

    トリガーに複数のグループを指定する場合にトリガーの動作を決定するには、Operation フィールドを参照してください。

    注記

    グループ識別子は小文字で入力する必要があります。たとえば、CN=johnsmith,DC=example,DC=com ではなく、cn=johnsmith,dc=example,dc=com です。

属性

ソースシステムから取得されるユーザー属性に基づいて、マップが true または false になります。Attribute トリガーの使用は、オーセンティケーターマップの例 を参照してください。

属性トリガーを定義すると、認証マッピングが拡張され、次の選択項目が追加されます。

  • Operation: このフィールドには、指定した Attribute 条件に基づいてルールの処理をトリガーする条件設定を含めます。バージョン 2.5 では、このフィールドは、ソースシステムが 1 つの値ではなく属性のリストを返す場合の処理を指定します。たとえば、ソースシステムがユーザーに対して複数のメールを返し、Operation が and に設定されている場合、トリガーが True になるには、それらのメールがすべて Comparison と一致する必要があります。Operation が or に設定されている場合、返されるメールのいずれかがトリガーの Comparison と一致すると、トリガーが True に設定されます。

    注記

    複数の属性マップを試す場合は、API を介して実行できます。ただし、オーセンティケーターが UI を介して保存されている場合、UI フォームで複数の属性マップが削除されます。マップに複数の属性を追加する場合、Operation は属性にも適用されます。

  • Attribute: このトリガーの評価に使用する、ソースシステムからの属性の名前。たとえば、ユーザーの姓に基づいてトリガーを起動するのであれば、ソースシステムの姓フィールドの名前が users_last_name である場合、このフィールドに値 ‘users_last_name’ を入力します。

  • Comparison: ユーザーの値を評価する方法をトリガーに指示します。ソースシステム内の Attribute を、トリガーに指定した Value と比較します。使用可能なオプションは、contains、matches、ends with、in、equals です。各 Comparison タイプの詳細を以下に示します。

    • contains: Value に指定された文字列が、ソースから返される属性値内に含まれているかどうかを判定します。たとえば、ソースの属性値が ‘John’ であり、Comparison が contains の場合、トリガーの Value が ‘Jo’ であれば、トリガーは True に設定されます。トリガーの Value が ‘Joy’ であれば、トリガーは False に設定されます。
    • matches: トリガーの Value が Python 正規表現として扱われ、指定された Value とソースシステムから返された値の間で 正規表現マッチ (re.match) (大文字と小文字の区別なし) が実行されます。たとえば、トリガーの Value が ‘Jo’ の場合、ソースからの値が ‘John‘ または ‘Joanne‘、あるいは正規表現 ‘Jo’ に一致するその他の値であれば、トリガーは True を返します。属性のソース値が ‘Dan’ の場合、‘Dan’ は正規表現 ‘Jo’ と一致しないため、トリガーは False を返します。
    • ends with: ソースから提供される値の末尾が、トリガーで指定された Value であるかどうかを判定します。たとえば、ソースから John という値が提供された場合、トリガーの Value が ‘n’ または ‘on’ に設定されていれば、トリガーは True になります。トリガーの Value が ‘z’ に設定されている場合、ソースから取得された値 ‘John’ の末尾が、トリガーで指定された値 ‘z’ ではないため、トリガーは False になります。
    • equal: ソースによって提供される値が、トリガーで指定された Value (全体) と等しいかどうかを判定します。たとえば、ソースから ‘John’ という値が返された場合、その Value が ‘John’ に設定されていれば、トリガーは True になります。ソースから ‘John’ 以外の値が返された場合、このトリガーは False になります。
    • in : in 条件では、値が複数の値のいずれかと一致するかどうかを判定します。Comparison に in を指定した場合、Value フィールドにコンマ区切りのリストを指定できます。たとえば、トリガーの Value が ‘John,Donna’ の場合、ソースからの属性の値が ‘John’ か ‘Donna’ であれば、トリガーは True になります。それ以外の場合、トリガーは False になります。

    • Value: Comparison フィールドに基づいてユーザー属性を照合するときに使用する値。このセクションにある Comparison の定義の例を参照してください。

      注記

      Comparison タイプが in 場合、このフィールドにコンマ区切りのリスト (スペースなし) を指定できます。

3.6.4. オーセンティケーターマップの例

次の例を使用して、プラットフォームへのユーザーアクセスを制御するために実装できるグループや属性値などのさまざまな条件を確認してください。

属性に基づいて組織にユーザーを追加する

この例では、Organization 属性の値が Networking である場合に、そのユーザーを Networking 組織に追加します。

組織にユーザーを追加するマッピングの例。各フィールドの機能を説明した下記リストと関連するコールアウト番号により、すべての項目に注釈が付いています。
  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 組織に追加されます。

ユーザーグループに基づいてチームにユーザーを追加する

この例では、次のいずれかのグループに属するユーザーを Apple チームに追加します。

Copy to Clipboard Toggle word wrap 
cn=Administrators,ou=AAP,ou=example,o=com

または

Copy to Clipboard Toggle word wrap 
cn=Operators,ou=AAP,ou=example,co=com
チームにユーザーを追加するマッピングの例

権限を昇格させない

この例では、ユーザーをスーパーユーザーに昇格しません。ただし、このルールでは、Revoke オプションが設定されていないため、ユーザーのスーパーユーザー権限は取り消されないことに注意してください。

権限を昇格しないマッピングの例

ユーザーがグループに属しているかどうかに基づいて権限を昇格する

この例では、ユーザーが次のグループに属している場合、ユーザー権限をスーパーユーザーに昇格します。

Copy to Clipboard Toggle word wrap 
cn=Administrators,ou=AAP
権限を昇格するマッピングの例

マッピング順序を使用して例外を作成する

マップは順番に実行されるため、例外を作成することもできます。前述の 権限を昇格しない 例を拡張して、権限を昇格する など、上位の別のルールを追加できます。

最初のルール (権限を昇格しない) は、どのユーザーもスーパーユーザーに昇格しませんが、2 番目のルール (権限を昇格する) は、その決定を変更し、ユーザーが Administrators グループに属している場合、そのユーザーにスーパーユーザー権限を付与します。

マッピング順序の例

3.6.5. 許可マッピング

許可マッピングを使用すると、満たす必要のある条件を定義することで、システムにアクセスできるユーザーを制御できます。

手順

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

次のステップ

  1. Manage mappings をクリックすると、認証マッピングの順序を管理できます。

  2. マッピングをリストに上下にドラッグしてドロップします。

    注記

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

  3. Apply をクリックします。

3.6.6. 組織マッピング

ユーザー名やメールアドレスなどの属性、またはオーセンティケーターから提供されるグループに基づいて、どのユーザーをどの Ansible Automation Platform 組織に配置するかを制御できます。

組織マッピングが肯定的に評価されると、マップに関連付けられたオーセンティケーターがオブジェクトの作成を許可されている場合で、指定された組織が存在しない場合は、その組織が作成されます。

手順

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

次のステップ

  1. Manage mappings をクリックすると、認証マッピングの順序を管理できます。

  2. マッピングをリストに上下にドラッグしてドロップします。

    注記

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

  3. Apply をクリックします。

3.6.7. チームマッピング

チームマッピングは、オーセンティケーターからチームメンバー (ユーザー) をマッピングすることです。

各チームのメンバーシップのオプションを定義できます。各チームごとに、どのユーザーをチームのメンバーとして自動的に追加するか、またどのユーザーがチームを管理できるかを指定できます。

チームマッピングは、アカウント認証ごとに個別に指定できます。

チームマッピングが肯定的に評価されると、関連付けられたオーセンティケーターがオブジェクトの作成を許可されている場合で、指定されたチームと組織が存在しない場合は、そのチームと組織が作成されます。

手順

  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. Manage mappings をクリックすると、認証マッピングの順序を管理できます。

  2. マッピングをリストに上下にドラッグしてドロップします。

    注記

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

  3. Apply をクリックします。

3.6.8. ロールマッピング

ロールマッピングとは、ユーザーを Platform Auditor などのグローバルロールに、またはチームや組織のロールにマッピングすることです。

チームや組織が適切なロールとともに指定されている場合、動作は Organization マッピングまたは Team マッピングと同じになります。

ロールマッピングは、アカウント認証ごとに個別に指定できます。

手順

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

次のステップ

  1. Manage mappings をクリックすると、認証マッピングの順序を管理できます。

  2. マッピングをリストに上下にドラッグしてドロップします。

    注記

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

  3. Apply をクリックします。

3.6.9. スーパーユーザーのマッピング

スーパーユーザーのマッピングは、システム管理者などのスーパーユーザーロールへのユーザーのマッピングです。

手順

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

次のステップ

  1. Manage mappings をクリックすると、認証マッピングの順序を管理できます。

  2. マッピングをリストに上下にドラッグしてドロップします。

    注記

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

  3. Apply をクリックします。

3.6.10. オーセンティケーターマップの結果の確認

プラットフォーム管理者は、API のユーザーページ (api/gateway/v1/users/X) からオーセンティケーターマップの結果を確認し、ユーザーがプラットフォームにログインしたときにマップがどのように評価されたかを確認できます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat, Inc.