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)相互運用で検証済みの主要なシナリオは、ユーザ名トークン、X.509トークン、 WS-Security Kerberos Token Profileを用いたKerberosトークンです。
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
次に、頂く質問は、.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を使うことができます。
[注意]
- このシナリオは明示的にOWSMで検証済みというわけではありませんが、OWSMがWS-Trustをサポートしているので動作するはずです。
- この図ではOracle STSを使っていますが、KerberosトークンのSAMLトークンへの交換をサポートするSTSである限り、任意のSTSを利用できます。
SPNEGO
また、SPNEGOのサポートに関する質問もたくさん見かけます。OWSMは、現在、SPNEGOをサポートしていません。以下のエントリでSPNEGOに関するすべてを知って頂けます。
SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft WindowsOWSMでSPENGOサポートを追加するカスタムアサーションを作成することができますが、SPNEGOの場合、WS-Security Kerberos Token Profileとは異なり、Kerberosトークンは、SOAP WS-SecurityヘッダではなくHTTPヘッダにあることに留意する必要があります。
http://www.rfc-archive.org/getrfc.php?rfc=4559
Custom Assertion in OWSM - OES, OSDT (Oracle Security Developer Toolkit) & OWSM - 11gそれゆえ、Kerberosトークンを"Negotiate"と呼ばれる認証スキームの下でHTTPヘッダにラップされています。WWW-AuthenticateとAuthorizationヘッダを使ってSPNEGOトークンをクライアント・サーバ間でやりとりします。手順は以下の通りです。
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（ロジ子訳）
- クライアントはAuthorizationヘッダなしで、保護されたドキュメントへのアクセスをサーバに要求する
- Authorizationヘッダがリクエストにないので、サーバは401（認証拒否）とWWW-Authenticate: Negotiate を返す。
- クライアントはユーザ資格証明を使ってトークンを取得し、その後新しいリクエストのAuthorizationヘッダにトークンを入れてサーバへ送信する。
[例] Authorization: Negotiate a87421000000492aa874209 - サーバはこのトークンをacceptSecContext() GSSAPIに渡してデコードする。コンテキストが完全ではない（Mutual Authenticationの場合）ときには、サーバは WWW-AuthenticateヘッダにGSS-APIデータを入れて、401ステータスコードを返す。
[例] WWW-Authentiate: Negotiate 74900a2a... - クライアントはこのデータをデコードし、新しいデータをサーバへ返す。このサイクルはセキュリティコンテキストが確立するまで継続する。
OSB自体にはSPNEGOをサポートする代替モデルがあります。A-Teamの方がOSBとSPNEGOに関する素晴らしいエントリを書いています（[注意] OSB10gR3の頃の内容ですが、現時点でも利用できます）。別のエントリでもSPNEGOを取り扱っています。
Oracle Service Bus and Kerberos (Oracle Fusion Middleware Security)NTLM
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のサポートに関するものです。OWSMは現在NTLMをサポートしていません。このwikipediaの記述にあるように、NTLMは標準とは異なります。
SPNEGOの関するWikipediaのエントリおわかりの通り、MicrosoftはNTLMを推奨していません。しかし、お客様が本当にNTLMのサポートが必要ということであれば、カスタムポリシーを作ることができます。
http://en.wikipedia.org/wiki/SPNEGO
NTLMに関するWikipediaのエントリ
http://en.wikipedia.org/wiki/NTLM
0 件のコメント:
コメントを投稿