web-dev-qa-db-ja.com

2つのIDプロバイダーを持つことの長所と短所

私の会社はクラウドとイントラネット上にアプリケーションを持っています。また、従業員、顧客、パートナーなど、さまざまな役割を担っています。パブリッククラウドでホストされているサービスと内部アプリケーション間のIDフェデレーションを希望しています。以下のシナリオが可能です

  1. イントラネットからクラウドサービスにアクセスする従業員
  2. インターネットからクラウドサービスにアクセスする従業員、顧客、パートナー
  3. 企業ネットワークの内部でホストされているデータサービスにアクセスするクラウドホストサービス
  4. インターネットから企業ネットワークで内部的にホストされているWebアプリケーション/サービスにアクセスする従業員、顧客、パートナー。
  5. イントラネットから企業ネットワーク上で内部的にホストされているWebアプリケーション/サービスにアクセスする従業員、顧客、パートナー。

インターネットから内部でホストされているアプリケーションまたはクラウドベースのアプリケーションへのアクセスの場合は常に、多要素認証を介してSSOを作成する必要がありますが、イントラネットから同じアプリケーションにアクセスする場合は、userid-passwordで十分です。クラウドベースのサービス/アプリケーションに統合されます。

DMZと内部ネットワークに1つずつデプロイされている2つのIDプロバイダーを使用することの賛否両論があるかどうかについて議論しています。DMZイントラネットからクラウドベースのサービスへのアクセス、またはインターネットからクラウドベースのサービスにアクセスするユーザーは、このIDPにフェデレーションされます。また、インターネットから内部アプリケーションにアクセスしようとするユーザーは、dmzのこのIDPによって認証される多要素になります。内部ネットワーク内のIDPイントラネットアプリケーションにアクセスする従業員のみが使用します。

私の質問は、上記の一種のデュアルIDPがアクセスを許可する標準的な方法であることです。 IDPが1つしかない場合の害は何ですか？

identityfederationssoidentity-management
4
Jimm

私が考える最も簡単な方法は、単一のIDプロバイダー（認証/承認）を「信頼できるソース」として識別することです。これにより、すべてのアプリケーションとサービスにわたってすべてのID情報が保存されます。

これにより、すべてのユーザーに認証と承認を提供できるマスターレコードが提供されます。この単一の信頼できるソースは、データをDMZゾーンにフィードして、クラウド上にある他のアプリケーションに情報を提供できるようにする必要があります。これにより、誰かが原因でアカウントを復元できないようにします。 DMZ内でアカウントを有効にする。

また、2つまたは3つの異なるソース間でユーザーを無効にするのではなく、1つのレコードからユーザーを削除するだけでよいので、IDをプロビジョニングおよびプロビジョニング解除するときにこれは非常に役立ちます。 （絶望的なプロセスを作成し、IdMプロセスの弱点を引き起こします。）

|   Cloud Infrastructure  |
---------------------------
|          Internet    ^  |
|                      |  |
---------------------------
|    DMZ               |  | <= External copy of authoritative source (read only from external)
|                      |  |
--------------------------|
| Internal - Authoritative| <= Authoritative Source (HR records/etc) reside here.
1
m3r1n