Web アプリケーションの 1 つにシングル サインオン (SSO) を追加しようとしています。現時点では重いものは必要ありません。ユーザー名を入力する必要なく、ログインしているユーザーの userId を知りたいだけです。
Web アプリは内部アプリケーションであるため、Windows PC などからのものであることは保証できます。
私は jCIFS を見てきましたが、これはもはやサポートされていないようで、商用製品を推奨しています。
WAFFLEも見ましたが、サーブレットスタックを使用しないplayframeworkアプリケーション用のSSOを構築しているため、SecurityFilterを利用できません。WindowsLoginModule の意味を理解しようとしましたが、それを実装するために何をしなければならないかを本当に理解できませんでした。
HTTPヘッダーからユーザー名を取得することは可能ですか、それともヘッダーを投稿する前に最初に交渉が必要ですか?
ActiveDirectoryとワークステーションがドメインに登録されているイントラネットコンテキストでは、HTTPSPNEGONegotiationサポートが最適なオプションです。ただし、ActiveDirectoryとJavaKerberosの実装に関する特定のスキルが必要です。
Spring Securityは、それを設定するための実装とドキュメントを提供します。ただし Secure.Security、HTTPネゴシエーションのようなトークンベースの認証をサポートするようには設計されていません。したがって、Spring Securityを使用するには、特定の統合モジュールが必要になります。
他のオプションはOpenIDとshibbolethですが、どちらも専用サーバーが必要であり、SPNEGO自体を実行するように構成できます。利用可能なPlayモジュールのおかげで、アプリケーションへの統合が容易になります。
クライアント側の複雑で安全でない/信頼性の低い調整を行わずにHTTPヘッダーでユーザー名を取得する唯一の方法は、ブラウザーとアプリケーションサーバーの間で認証プロキシを使用することです。これらのプロキシのほとんどは、認証手段としてKerberosSPNEGOもサポートしています。
Windows ユーザーがイントラネット webapp に自動的にログインできるようにします。したがって、ユーザー アカウントは Active Directory に置かれ、Microsoft の通常の方法は、NTMLまたはKerberosなどのプロトコルを使用することです。SSO に NTML (および jCIFS) をまだ使用している企業もありますが、通常、アプリケーションは NTLM を使用しないことをお勧めします。
Kerberos と Java をすばやく検索すると、この記事が表示されました。Java EEスタック(JAAS)に依存しているようです。
より簡素化されたアプローチの場合: 通常、移植可能な方法で http 要求でユーザー名を送信することはできません。ActivX を使用すると、次のことができます。
var wshshell=new ActiveXObject("wscript.shell");
var username=wshshell.ExpandEnvironmentStrings("%username%");
サーバー側では、http ヘッダーを解析し、選択したテクノロジーでユーザー名を抽出できます。
playframework アプリケーションでは、セキュリティは重要ではないのですか? 寿命の長い Cookie を使用しないのはなぜですか?
それが役に立てば幸い！
Active Directory は Kerberos を使用するため、ログインしているすべてのユーザーは kerberos チケットを持っている必要があります。速いグーグルはこれを見つけました：
Windows ログオンの詳細が必要な場合は、それが唯一の選択肢だと思います。
重くない答え
運用チームに、ログインしたユーザー名を HTTP ヘッダーとして送信するグループ ポリシーを実装させることが可能であるように思われます。
それ以外の場合は、IE とサーバーの間にある種のネゴシエーション「ダンス」があるという前提で正しいです。ここを参照してください。おそらく、Play コードでこのダンスを偽造することができます。
重い答え
私はjCIFSを知っており、この例ではサーブレットとフィルターを使用していますが、コードの重要な部分を抽出して、カスタムの Play Authenticator を構築できます (Scala のサンプル オーバーライドを貼り付けることができますplay.api.mvc.Security.Authenticatedが、回答は Java とタグ付けされています)。リクエストヘッダーのみが必要なので（本文ではありません）、オーセンティケーターで実行できるはずです。
PS jCIFSはあなたの投稿後に更新されたようです。そのため、ハッキングの使用を再考することになると思います。私はメンテナンスされていないライブラリにも警戒していますが、成熟度と安定性に達し、それ以上の更新の必要性が軽減されることがあります。
アプリケーションで SSO を有効にするために Shiro を使用することができます。Shiro id はサーブレットから独立しています。フレームワークはサーブレットをサポートしていないため、Shiro を簡単に使用できます。
hashPassword を定義する Realm を作成できます。
ユーザー名と hashPassword を構成し、hashPassword でユーザーを認証するように shiro に依頼できます。
次に、SSO の目的を果たすユーザーにロールを割り当てます。
複数のアプリケーションでユーザーを認証できるため、ユーザーが別のアプリケーションにログインすると、shiro はすでにあなたを認証しているため、すぐにアプリケーション内にログインします。
次のリンクから shiro のドキュメントを参照できます (網羅的で、最初から設定できるはずです)。
セキュリティおよび暗号化モジュールとともに、認証および承認のための多くのすぐに使用できる機能を提供します。
ユーザー名はヘッダーで送信されません。たとえ知識のあるユーザーが値を偽造する可能性があるため、これに頼るべきではありません。
NTLM が有効なオプションである場合、 Jespaは JCIFS の優れた代替手段になる可能性があります。Jespa は (JCIFS とは異なり) 特に NTLM v2 をサポートしています。限定バージョン (最大 25 ユーザー) は無料です。
フィルターからいつでも任意のヘッダーを取得できます。HttpServletRequest の javadoc を参照してください。