ユーザーがイントラネットWebアプリに透過的にログインすることにより、Active DirectoryでのSSOはどのように機能しますか？
ログインを必要としないWebアプリが作れると聞いています。ユーザーはWindowsにログインし、WindowsはActive Directory（LDAP）ルックアップを介して認証します。その後、彼らは私のウェブアプリケーションに行くことができ、ログインプロンプトが表示されないはずです。これらの顧客はこれをシングルサインオンと呼んでいます（おそらく間違っていて、私の混乱の一部です）。
しかし、Tomcatのドキュメントからシングルサインオンを読んだところ、
シングルサインオンバルブは、仮想ホストに関連付けられたWebアプリケーションのいずれかにサインオンする機能をユーザーに提供する場合に使用されます、および次に、同じ仮想ホスト上の他のすべてのWebアプリケーションでIDを認識させます。
これは私には完全に明らかです。ユーザーは1回ログインする必要があり、Tomcatのインスタンス上のすべてのWebアプリケーションにアクセスできます。しかし、私がしなければならないことは、Tomcatサーバーに資格情報を提供せずに、どういうわけかログインを許可することです。
だから、これが機能するために私は想像します：
- ユーザーがページをリクエストする
- サーバーはセッショントークンを認識せず、クライアントにいくつかの資格情報を要求します。
- ユーザーの介入なしにクライアントのブラウザがサーバーに資格情報を提供します。
- 次に、クライアントのブラウザから提供された資格情報を使用して、LDAPで検索を行います。
私はクライアント側の証明書を使用するいくつかの例を見てきました...特にDoD PKIシステムは私にとっていくつかの意味があります。それらの場合、クライアント側の証明書を要求するようにTomcatを 構成するためです 、しかし、ウィンドウにログインするだけでは、これがどのように機能するのか、ブラウザがサーバーにどのような情報を渡すのかわかりません。これは、NTLMが何のために使用されるのですか？
まず、他のユーザーがこのページにアクセスした場合に備えて、プロンプトなしのSSOを実行できる認証方法はいくつかあります。これらは[〜＃〜] ntlm [〜＃〜]と- Kerberos。一方、LDAPでは、プロンプトなしのSSOは提供されません。
NTLMは実際にはNTLMv1およびNTLMv2です。これらは大きく異なり、深刻なセキュリティ上の問題があるため、NTLMv1は廃止されました。 Java認証ソリューションは、NTLMv1またはNTLMv2をサポートしているかどうかを正しく識別できないため、ドキュメントで「NTLM」という単語のみを使用しているため、避けてください。セキュリティ開発者が言っているセキュリティソリューションはファイアエスケープを探す理由はそれだけです。
従来の考え方に反して、NTLMv1とNTLMv2の両方がMicrosoftによって完全に文書化されていますが、プロトコルを「リバースエンジニアリング」したと主張する解決策が見つかるはずです。これは、Microsoftが2006年または2007年頃に私が信じるプロトコルを文書化する前に必要であったことは事実です。とにかくNTLMv1はノーノーです。 NTLMv2自体には何の問題もありませんが、Microsoftはすべての製品でKerberos認証を支持してNTLM（任意の形式）を段階的に廃止しています。 NTLMv1は長い間使用されておらず、ドメインコントローラが利用できない場合にのみ、NTLMv2がMicrosoftによって使用されています。結論：NTLM（任意の形式）は実際には前進しません。ここで標準ベースのアプローチをとったことについて、マイクロソフトに敬意を表します。
これにより、Kerberosが残ります。マイクロソフトは、HTTPを介して認証情報をネゴシエートおよび転送するためのプロトコルを作成しました。これはMicrosoft製品では " Integrated Windows Authentication "として知られていますが、[〜＃〜 ] spnego [〜＃〜]。これはあなたが探しているべきものです。 SPNEGOは、基礎となる認証メカニズムとしてNTLMv2とKerberosの両方をサポートしますが、上記の理由から、NTLMv2ではなくKerberosをターゲットにする必要があります。
SourceForgeのSPNEGOプロジェクト を使用して、いくつかのTomcatアプリケーション（Linux/Solaris上で実行）をActive Directoryと正常に統合しました。これが最も簡単なアプローチであることがわかりました。これにより、たとえばSharePointサーバーが行うのと同様のプロンプトレスSSOが得られます。これは、ユーザーが「SSO」について話すときに期待することです。 Kerberos構成を正しく取得し、キーを生成し、Active Directoryで「ダミー」アカウントを設定するのは面倒な作業ですが、正しく設定すると、魅力的に機能します。
SourceForgeのSPNEGOプロジェクト について私が気に入らない唯一のことは、認証を実行する頻度がわからないことです。私の厄介な疑いは、セッションごとに1回ではなく、すべてのページビューに対してそれを行うことです。おそらく私はこれで間違っています。とにかく、これはSSOソリューションで考慮すべきもう1つのことを強調しています。不要な要求でIDプロバイダー（Active Directoryなど）を「スパム」するソリューションを実装したくない場合です。
Windows Active Directory環境では、シングルサインオンは、内部のWebページにアクセスするとWindowsのログイン権限が与えられ、Webサーバーがそれらにアクセスできることを意味します。これはNTLMが使用されるものですが、新しい実装では代わりにKerberosを使用します。
SharepointサーバーのWebサイトを開くと、ログインユーザー名とパスワードがなくても誰であるかがわかりますが、これは同じネットワーク上の内部Webサイトでのみ機能します。パブリックWebサイトで機能することはあまり意味がないと思います。 （Apache vhostのように「仮想ホスト」を意味するのか、外部委託のホストサーバーのように意味するのかはわかりません）。
IIS/ASP.Net： http://msdn.Microsoft.com/en-us/library/ ff647076.aspx
Apache/Tomcat/Javaで実行できるように見えます。ここにPDFその英国大学の実装を説明しています： http://gfivo.ncl.ac.uk/documents/UsingKerberosticketsfortrueSingleSignOn.pdf とCodeplexプロジェクトit： http://tomcatspnego.codeplex.com/ とOpenfireには、Java/Kerberosの一般的な操作に関するドキュメントがいくつかあります（ http://community.igniterealtime.org/docs）/DOC-106 ）。
まず第一に、あなたはログインを避けることはできません。ユーザーを識別したい場合は、ユーザーにログインしてもらう必要があります。 NTLMを忘れて、Kerberosが救いに来ます-それは完全に透過的な方法ですべてを行うことができます。
SingleSignOnValveは、探しているものではありません。 Tomcat 7を使用する場合、すぐに SpnegoAuthenticator を使用できますが、6では this を使用する必要があります。
マイクロソフトが統合Windows認証と呼んでいるものを説明しているようですね。
Tomcatは この記事 に基づいてWindows認証をサポートしているようです。