3.3. 認証方法の作成
オーセンティケーターを作成するには、次の手順に従います。
- 認証タイプを選択します。選択した認証タイプの認証詳細を含め、設定するオーセンティケータープラグインのタイプを選択します。
マッピング で、システムへのアクセスを制御するためのマッピングルールタイプとトリガーを定義します。マッピング順序 で、マッピングの優先順位を定義できます。
注記マッピング順序は、1 つ以上のオーセンティケーターマップを定義した場合にのみ使用できます。
3.3.1. 認証タイプの選択
Authentication Methods ページで、設定するオーセンティケータープラグインのタイプを選択できます。
手順
-
ナビゲーションパネルから、
を選択します。 - をクリックします。
オーセンティケーターの一意の Name を入力します。名前は必須で、すべてのオーセンティケーター間で一意である必要があり、512 文字を超えることはできません。これは、オーセンティケーターに対して生成される一意の識別子になります。
注記名前を変更しても、オーセンティケーターの一意の識別子は更新されません。たとえば、
My Authenticator
という名前のオーセンティケーターを作成し、後でその名前をMy LDAP Authenticator
に変更した場合、一意の識別子が引き続き使用されているため、My Authenticator
という名前の別のオーセンティケーターを作成することはできません。- Authentication type リストから、オーセンティケータータイプを選択します。利用可能な認証プラグインの完全なリストは、認証タイプの設定 を参照してください。
Authentication details セクションが自動的に更新され、選択した認証タイプに関連するフィールドが表示されます。必要な詳細は、「認証タイプの設定」の各セクションを参照してください。
すべての認証タイプについて、Name、Additional Authenticator Fields、および Create Objects を入力します。
- Enabled を有効または無効にして、オーセンティケーターを有効にするか無効にするかを指定します。有効にすると、ユーザーはオーセンティケーターからログインできます。無効にすると、ユーザーはオーセンティケーターからログインできません。
Create Object を有効または無効にして、ユーザーがログインした際にオーセンティケーターがシステムにチームと組織を作成するかどうかを指定します。
- Enabled
- オーセンティケーターマップ内で定義されたチームと組織が作成され、ユーザーがそれらに追加されます。
- Disabled
- オーセンティケーターマップ内で定義された組織とチームは、システム内で自動的に作成されません。ただし、マップがすでに存在する場合 (スーパーユーザーによって作成された場合)、マップをトリガーするユーザーにはマップへのアクセスが許可されます。
Remove Users を有効または無効にします。有効にすると、ユーザーがこのソースから認証される際に、以前にユーザーに付与されたアクセス権がすべて削除されます。無効にすると、このオーセンティケーターのオーセンティケーターマッピングの結果に基づいてのみ、ユーザーに権限が追加されたり、権限が削除されたりします。
たとえば、ユーザーにシステム内で
is_superuser
権限が付与されているとします。そして、そのユーザーがオーセンティケーターにログインしたとします。そのオーセンティケーターのマップは、ユーザーをスーパーユーザーにするべきかどうかを判定しません。Remove Users が有効な場合、is_superuser
権限はユーザーから削除されます。オーセンティケーターマップはその権限を持たせるべきかどうかを判定しないため、ログイン後、ユーザーはis_superuser
権限を持ちません。Remove Users が無効な場合、
is_superuser
権限はユーザーから 削除されません。オーセンティケーターマップはその権限を持たせるべきかどうかを判定しないため、ログイン後、ユーザーはis_superuser
権限を 持ちます。- 認証マッピングのルールとトリガーの定義 に進みます。 をクリックし、
3.3.2. 認証マッピングのルールとトリガーの定義
認証マップのタイプは、どのタイプのオーセンティケーターでも使用できます。各マップには、マップがいつ true として評価されるかを定義するトリガーがあります。
手順
-
ナビゲーションパネルから、
を選択します。 - リストビューで、Name 列に表示されているオーセンティケーター名を選択します。
- オーセンティケーターの Details ページから Mapping タブを選択します。
- をクリックします。
Authentication mapping リストからマップのタイプを選択します。各マップのタイプの詳細な説明は、オーセンティケーターマップのタイプ を参照してください。次の選択肢があります。
- ルールを識別するための一意のルールの Name を入力します。
リストから Trigger を選択します。詳細は、オーセンティケーターマップのトリガー を参照してください。次の選択肢があります。
- Always
- Never
- Group
- Attribute
- をクリックします。
- この手順を繰り返して、オーセンティケーターのマッピングルールとトリガーをさらに作成します。
必要に応じてオーセンティケーターのマッピングの順序を変更するには、マッピング順序の調整 に進みます。
注記マッピング順序の設定は、複数のオーセンティケーターマップが定義されている場合にのみ使用できます。
3.3.3. マッピング順序の調整
1 つ以上のオーセンティケーターマップが定義されている場合は、マップの順序を管理できます。オーセンティケーターマップは、ログイン時に一番下から一番上までの順序で実行されます。あるオーセンティケーターマップで、ユーザーをチームのメンバーにする必要があると判定されたが、後続のマップで、ユーザーをそのチームのメンバーにする必要がないと判定された場合、2 番目のマップの判定が最初のマップの判定結果よりも優先されます。同じ順番のオーセンティケーターマップは、不定の順序で実行されます。
たとえば、最初のオーセンティケーターマップが is_superuser
タイプで、トリガーが never に設定されている場合、システムにログインするユーザーに is_superuser
フラグは付与されません。
また、2 番目のマップが is_superuser
タイプで、トリガーが特定のグループを持つユーザーに基づいている場合、ログインするすべてのユーザーは最初に is_superuser
権限を拒否されます。ただし、指定されたグループのすべてのユーザーには、2 番目のルールによって is_superuser
権限がその後付与されます。
ルールの順序は、組織、チーム、ロールのうちどれを最初に処理するかよりも重要です。ルールの順序はアクセスを絞り込むためにも使用されるため、ログインの問題を回避するために慎重な検討が必要です。
以下に例を示します。
- オーセンティケーターマップ A は、すべてのユーザーによるシステムへのアクセスを拒否します。
-
オーセンティケーターマップ B は、ユーザー
john
にシステムへのアクセスを許可します。
マッピング順序が A、B に設定されている場合、最初のマップが john
を含むすべてのユーザーのアクセスを拒否します。その後、2 番目のマップが john
にシステムへのアクセスを許可します。その結果、john
はアクセスを許可され、プラットフォームにログインできるようになります。
ただし、マッピング順序が B、A に変更されると、最初のマップが john
にシステムへのアクセスを許可します。その後、2 番目のマップがすべてのユーザー (john
を含む) によるシステムへのアクセスを拒否します。その結果、john
はアクセスを拒否され、プラットフォームにログインできなくなります。
手順
-
ナビゲーションパネルから、
を選択します。 - リストビューで、Name 列に表示されているオーセンティケーター名を選択します。
- オーセンティケーターの Details ページから Mapping タブを選択します。
- をクリックします。
ドラッグ可能なアイコンを使用して、リスト内でマッピングを上または下にドラッグアンドドロップして、マッピングの順序を調整します。
注記マッピングの優先順位は、マッピングがリストされている順序によって決まります。
- オーセンティケーターマップが正しい順序になったら、 をクリックします。