アイデンティティ連携

このトピックでは、ゲートウェイでアイデンティティ連携がどのように扱われるかを説明します。
gateway90
このトピックでは、
Layer7 API Gateway
でアイデンティティ連携がどのように扱われるかを説明します。
アイデンティティ サイロの問題
Web サービスとして公開したアプリケーションへのアクセスを制御するには、要求元のアイデンティティの認証および許可が必要です。認証は提示された認証情報を検証することを伴い、許可は認証結果の解釈に基づいて、アクセス権、権限、または資格を付与することを伴います。整合性のある管理を行うために、通常、アイデンティティはアプリケーションと同じセキュリティ ドメインに格納されます。認証および許可プロセスでは、アイデンティティの厳密な要素が、アイデンティティ プロバイダが提供するサービスの機能要件と照合されます。あるアイデンティティ プロバイダからのアイデンティティが、それらのローカル セキュリティ ドメインの外部と関連付けられているということはほとんどありません。これは「アイデンティティ サイロ」の作成につながります。アイデンティティ サイロは、異なるセキュリティ ドメインに属するアプリケーションの統合を考えている企業にとっては深刻な問題です。
正当なリクエスタが、あるアイデンティティ サイロ内の対応するアイデンティティ プロバイダに対して認証を行ったとしても、企業の内部または外部の別のアイデンティティ サイロ内の別の Web サービスへのアクセスを要求する際には、そのアイデンティティや認証の証拠は関連付けられていない可能性があります。企業内またはパートナー間にさまざまなアイデンティティ プロバイダが存在することで、認証および許可プロセスが複雑になり、結果的に統合は失敗し、あるサイロでの認証が成功しても別のサイロでの許可に失敗することになります。
クロスドメイン アプリケーション統合のためのアイデンティティ連携
アイデンティティ連携は、異なるセキュリティ ドメインからのアイデンティティをマージし、アイデンティティ サイロを解消するための強力なメカニズムです。アイデンティティ連携では、リクエスタ ドメインが認証を担当し、許可は Web サービスをホストするプロバイダ ドメインで処理されるか、ソースで委任されています。合併買収シナリオで、たとえば、企業 A が企業 B を合併したと想定します。それぞれの企業には自身のアイデンティティ プロバイダがあり、最小のリソースで、既存のセキュリティ アーキテクチャを中断せずに、アイデンティティを共有したいと考えています。
Layer7 API Gateway
の製品を使用し、SAML (Security Assertion Markup Language)トークンまたは X.509 証明書の 2 つの認証情報ソース タイプのいずれかを使用して、企業 A と企業 B との間でアイデンティティ連携が設定されています。
簡潔に表わすために、一般的な「信頼できる認証局」および「フェデレーション Gateway」の参照がアイデンティティ連携のすべての例、ワークフロー、および手順で使用されています。「信頼できる認証局」は、セキュリティ認証情報の発行および管理を行い、認証を担当する認証局(CA)です。「フェデレーション Gateway」は、許可を担当する Web サービス プロバイダです。「トラステッド」および「フェデレーション」という用語は、サービス リクエスタの視点から見て使用されています。
SAML 認証情報ソースを使用するアイデンティティ連携
image2014-10-20 9:12:29.png
データ フローの説明
  • 信頼は設計時に確立されます。フェデレーション アイデンティティ プロバイダが信頼できる証明書にマップされます。
  • 設計時には、フェデレーション Gateway のポリシーが、フェデレーション アイデンティティ プロバイダの認証局によって署名された SAML トークンを必要とする制約で設定されます。
  • 実行時に、クライアントはセキュリティ トークン サービスに署名済みの SAML トークンをリクエストし、SAML トークン プロファイルとしてメッセージにそれを添付します。
    Layer7 API Gateway
    はシグネチャを確認し、メッセージをルーティングします。
X.509 証明書の認証情報ソースを使用するアイデンティティ連携
image2014-10-20 9:14:24.png
データ フローの説明
  • 信頼は設計時に確立されます。フェデレーション アイデンティティ プロバイダが作成されます。
  • フェデレーション Gateway のポリシーには SSL CMA または WS Signature が含まれます。
Layer7 API 管理製品を使用したアイデンティティ連携
Layer7 API Gateway
「フェデレーション Gateway」という必要なプロバイダ側
Layer7 API Gateway
は、アイデンティティ連携設定で許可に使用されます。フェデレーション Gateway は、信頼できる証明書を自身のトラスト ストアにインポートすることにより、認証ソースとの証明書ベースの信頼関係を確立します。認証ソースは、任意の認証局(CA)、または CA として動作する別の
Layer7 API Gateway
です。*
* 認証局として動作する
Layer7 API Gateway
は、
Layer7 API Gateway
- XML VPN Client の使用時にのみ使用可能です。
フェデレーション Gateway は、リクエスタの認証情報の受け渡しにフェデレーション ユーザ、フェデレーション グループ、および仮想グループの 3 種類のフェデレーション アイデンティティを使用します。これにより、フェデレーション Gateway に対する許可を保持し、1 つ以上の信頼できる認証局に認証を委任します。
任意の
Layer7 API Gateway
製品をアイデンティティ連携に使用できます。アイデンティティ連携設定で SAML が認証情報ソースとして使用される場合、認証ソースは SAML トークンを発行できる必要があります。別の
Layer7 API Gateway
が認証情報ソースとして使用される場合、それはすでに SAML トークンを発行できます。「SAML を使用するワークフロー」を参照してください。
Layer7 API Gateway
- XML VPN Client
リクエスタ側の
Layer7 API Gateway
- XML VPN Client は、フェデレーション Gateway で定義されている Web サービス ポリシー アサーションに基づいて、リクエスト メッセージの修飾を担当します。修飾されたメッセージは、Web サービスの許可のために、
Layer7 API Gateway
- XML VPN Client からフェデレーション Gateway に送信されます。ポリシーに Require SAML Token Profile アサーションが含まれている場合、クライアントの修飾タスクの一部で、最初の接続時または元の SAML トークンの期限切れ時に、信頼できる認証局からの SAML トークンの取得を伴うことがあります。
Layer7 API Gateway
- Policy Manager
Policy Manager は、信頼できる証明書(CA 証明書または信頼できる認証局から取得したサーバ証明書)をフェデレーション Gateway のトラスト ストアにインポートするためのインターフェースを提供します。また、Policy Manager は、1 つ以上のフェデレーション アイデンティティ プロバイダ(FIP)を設定および管理し、トラスト ストアの証明書を FIP にリンクし、フェデレーション Gateway の SAML ポリシーを設定するためのインターフェースを提供します。
アイデンティティ連携での
Layer7 API Gateway
- XML VPN Client の使用
アイデンティティ連携設定では、
Layer7 API Gateway
- XML VPN Client を使用して、Web サービスをホストしているフェデレーション Gateway に対する許可の保持中に、信頼できる認証局に認証を委任できます。
Layer7 API Gateway
- XML VPN Client は、リクエスタの SAML または X.509 証明書の許可ソースへのインターフェースとなって、認証を検証します。
Layer7 API Gateway
- XML VPN Client は、認証アサーションまたはトークンを受信すると、その証明を埋め込み、SOAP メッセージに署名します。その後、フェデレーション Gateway はこの証明を使用して、保護されている Web サービスへのアクセスを安全に許可します。