[FMW, Security] .NET interoperability, Kerberos, SPNEGO, Id Propagation - All things Microsoft! - OWSM 11g

原文はこちら。
https://blogs.oracle.com/owsm/entry/net_interoperability_kerberos_spnego_id

最も多く頂く質問の中に、OWSMと.NET/WCFとの相互運用に関するものがあります。まず、公式にOWSMは.NETとの相互運用シナリオを検証しています。これらはOracle Web Services Manager相互運用ガイドに記載があります。
Oracle® Fusion Middleware Interoperability Guide for Oracle Web Services Manager 11g Release 1 (11.1.1.6)
Interoperability with Microsoft WCF/.NET 3.5 Security Environments
http://docs.oracle.com/cd/E23943_01/web.1111/e16098/interop_net.htm#BIIEHFFD
Oracle® Fusion Middleware Oracle Web Services Manager相互運用ガイド 11gリリース1 (11.1.1.6)
Microsoft WCF/.NET 3.5のセキュリティ環境との相互運用性
http://docs.oracle.com/cd/E28389_01/web.1111/b61391/interop_net.htm#BIIEHFFD
相互運用で検証済みの主要なシナリオは、ユーザ名トークン、X.509トークン、 WS-Security Kerberos Token Profileを用いたKerberosトークンです。
次に、頂く質問は、.NET環境とのIDの伝播をどうすればよいか、というものです。

シナリオ1: KerberosとSAML、OSBをアクティブな仲介者として使用して、WCFクライアントとOWSM/Fusion Middleware間のID伝播を実現する

[注意] OSBの代わりに、SOA Suiteを使うことも可能です

シナリオ2: KerberosとSAML、OSBをパッシブな仲介者として使用して、WCFクライアントとOWSM/Fusion Middleware間のID伝播を実現する

[注意] パッシブな仲介モデルではOSB(もしくはOEG)にて実現できます。SOAはパッシブな仲介モデルをサポートしていないため、SOAでは実現できません。

シナリオ3: WCFクライアントとOWSM/Fusion Middleware、アクティブな仲介者としてのOSB間で、KerberosベースのマルチホップのID伝播を実現する

このシナリオでは、Kerberosを使ってマルチホップのID伝播を実現したいというものですが、現時点ではサポートされていません。

シナリオ4: WCFクライアントとWCFサービス、アクティブな仲介者としてのOSB間で、KerberosベースのマルチホップのID伝播を実現する

シナリオ3とシナリオ4の両方で、マルチホップエンドユーザIDの伝播のためにKerberosをつかうためには、ユーザTGT(Ticket Granting Ticket)もしくはS4U(Service-for-User)拡張のどちらかのサポートが必要です。これらのいずれも、現時点ではOWSMでサポートしていません。

シナリオ5: SAMLを使ってEnd to EndのID伝播を実現する

OSBやSOA Suiteを使ってエンドユーザIDの伝播を実現する別の方法として、SAMLがあります。WCF/.NETはSTS(Secure Token Service)と会話してKerberosトークンをSAMLトークンとの交換をサポートしています。マルチホップ間でSAMLを使うことができます。
[注意]
  1. このシナリオは明示的にOWSMで検証済みというわけではありませんが、OWSMがWS-Trustをサポートしているので動作するはずです。
  2. この図ではOracle STSを使っていますが、KerberosトークンのSAMLトークンへの交換をサポートするSTSである限り、任意のSTSを利用できます。
ここには全ての可能性のあるシナリオをリストアップしていませんが、この内容で今何が出来て、何ができないのか要点をお伝えできればうれしいです。

SPNEGO
また、SPNEGOのサポートに関する質問もたくさん見かけます。OWSMは、現在、SPNEGOをサポートしていません。以下のエントリでSPNEGOに関するすべてを知って頂けます。
SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows
http://www.rfc-archive.org/getrfc.php?rfc=4559
OWSMでSPENGOサポートを追加するカスタムアサーションを作成することができますが、SPNEGOの場合、WS-Security Kerberos Token Profileとは異なり、Kerberosトークンは、SOAP WS-SecurityヘッダではなくHTTPヘッダにあることに留意する必要があります。
Custom Assertion in OWSM - OES, OSDT (Oracle Security Developer Toolkit) & OWSM - 11g
https://blogs.oracle.com/owsm/entry/custom_assertion_in_owsm_oes
http://orablogs-jp.blogspot.jp/2012/08/custom-assertion-in-owsm-oes-osdt.html(ロジ子訳)
それゆえ、Kerberosトークンを"Negotiate"と呼ばれる認証スキームの下でHTTPヘッダにラップされています。WWW-AuthenticateとAuthorizationヘッダを使ってSPNEGOトークンをクライアント・サーバ間でやりとりします。手順は以下の通りです。
  1. クライアントはAuthorizationヘッダなしで、保護されたドキュメントへのアクセスをサーバに要求する
  2. Authorizationヘッダがリクエストにないので、サーバは401(認証拒否)とWWW-Authenticate: Negotiate を返す。
  3. クライアントはユーザ資格証明を使ってトークンを取得し、その後新しいリクエストのAuthorizationヘッダにトークンを入れてサーバへ送信する。
    [例] Authorization: Negotiate a87421000000492aa874209
  4. サーバはこのトークンをacceptSecContext() GSSAPIに渡してデコードする。コンテキストが完全ではない(Mutual Authenticationの場合)ときには、サーバは WWW-AuthenticateヘッダにGSS-APIデータを入れて、401ステータスコードを返す。
    [例] WWW-Authentiate: Negotiate 74900a2a...
  5. クライアントはこのデータをデコードし、新しいデータをサーバへ返す。このサイクルはセキュリティコンテキストが確立するまで継続する。
リクエスト/チャレンジモデルがあるので、OSB/OEGが"パッシブな仲介者"として機能している場合、通常、SPNEGOセキュリティモデルはOSB/OEGのような仲介者で実現することは困難です。アクティブな仲介モデルのほうがより適切かもしれません。
OSB自体にはSPNEGOをサポートする代替モデルがあります。A-Teamの方がOSBとSPNEGOに関する素晴らしいエントリを書いています([注意] OSB10gR3の頃の内容ですが、現時点でも利用できます)。別のエントリでもSPNEGOを取り扱っています。
Oracle Service Bus and Kerberos (Oracle Fusion Middleware Security)
http://fusionsecurity.blogspot.jp/2010/03/oracle-service-bus-and-kerberos.html
How does Kerberos actually work in the HTTP world? (Oracle Fusion Middleware Security)
http://fusionsecurity.blogspot.jp/2011/01/how-does-kerberos-actually-work-in-http.html
NTLM
よく尋ねられる次の質問はNTLMのサポートに関するものです。OWSMは現在NTLMをサポートしていません。このwikipediaの記述にあるように、NTLMは標準とは異なります。
SPNEGOの関するWikipediaのエントリ
http://en.wikipedia.org/wiki/SPNEGO
NTLMに関するWikipediaのエントリ
http://en.wikipedia.org/wiki/NTLM
おわかりの通り、MicrosoftはNTLMを推奨していません。しかし、お客様が本当にNTLMのサポートが必要ということであれば、カスタムポリシーを作ることができます。

0 件のコメント:

コメントを投稿