
まず、少しの理論。 SSO、透過的な承認、ユーザーがコンピューターにログオンするときにActive Directoryでアカウントのユーザー名/パスワードを入力し、Webアプリケーション(だけでなく、それについて話している)を開くと、データで自動的に承認されるという考え方あなたのアカウント。
原則は、このためにブラウザーで定められています-Get要求への応答としてHTTPコード401「Not Authorized」を受信し、<WWW-Authenticate:Negotiate> HTTPヘッダーで、ブラウザーであるKDC(Key Distribution Center- ADサービスの1つ)を使用して、このWebサービスの特別なSPNEGOトークンを受け取ります。 ADにそのようなWebサービスのアカウントがない場合、ブラウザはNTLMを介して認証の標準応答を取得します。 しかし、この場合、何かがうまくいかなかったと信じています。
そのため、ADでこのWebサービスが正しく設定されている場合、ブラウザーは再びGet要求を応答401に送信しますが、<Authorization:YIIJvwYGKw ...>という見出しを付けて、トークンが「YII」で始まる場合、これはKerberosエンコードされます認証用のデータを含むチケット。
Kerberosは暗号化の一種ですが、主にSSOに使用されるため、これらの概念は密接に関連しています。
次に、トークンを受け取ったWebサービスは、Kerberosクライアントを使用した検証のためにトークンをKDCに送信します。 そして、成功した場合、ADでユーザー名を取得します。 さらに、別のADアクセスサービスであるLDAPを介して、ユーザーに関するデータ(たとえば、ユーザーがメンバーとなっているグループ)を検索するために既に使用できます。
このプロセスの最も鮮明な説明は、Microsoftの公式ドキュメントからのものです。 そして、驚くべきことに、このテーマを最もよく理解したのは彼らのドキュメントだったと言わなければなりません。
.gif)
ここから
したがって、Webアプリケーションの作成に加えて、次のアクションが必要です。
AD管理者の側で行う必要があること
-WebサービスのAD SPN名(HTTP/webservice.example.com@EXAMPLE.COMの形式)を設定します。 これにより、クライアントブラウザーはこのサービスのトークンを要求し、HTTPヘッダーでトークンをWebサービス、およびこのサービスを介してKerberosクライアントに転送し、キーに基づいてユーザーを認証し、
-このサービスのkrb5.keytabキーを生成します。これは、ユーザーを認証するためにKerberosクライアントで使用されます。
Webサービスサーバーでの追加のアクション
-Kerberosクライアントをインストールする必要があります(Windowsの場合、Linuxの場合は既に存在します-たとえば、RedHatの場合、インストールするコマンド:yum install krb5-workstation krb5-libs krb5-auth-dialog krb5-devel)。
-そのためには、KDCにアクセスするためにkrb5.conf構成ファイルを構成する必要があります(AD管理者が正しい設定に名前を付けるため、メインパラメーターはkdcです)。
-また、キーファイル/etc/krb5.keytabを添付します。
Webアプリケーションで
-Kerberosモジュールは、Kerberosクライアントと連動するようにインストールされます。
-およびLDAPクエリを実行するためのactivedirectoryモジュール。
不快な瞬間-Windowsの場合、kerberosモジュールは別のAPIを提供しますが、うまくいきませんでした。 誰かが解決策を持っている場合、それは非常に役立つでしょう。
Linuxの場合、kerberosモジュールは、作業に必要な2つの主な方法を提供します。
-authGSSServerStep-検証のためのトークンの送信、
-authUserKrb5Password-透過的な認証が機能しなかった場合のログイン/パスワードによる認証。
メソッドの使用に関するドキュメントはありませんが、ファイルlib \ kerberos.jsには適切なコメントがあります。
ブラウザから送られたトークンをチェックする主要なコードは次のとおりです。
//cut phrase "Negotiate " var ticket = req.headers.authorization.substring(10); //init context kerberos.authGSSServerInit("HTTP", function(err, context) { //check ticket kerberos.authGSSServerStep(context, ticket, function(err) { //in success context contains username res.set( 'WWW-Authenticate', 'Negotiate ' + context.response); res.send(context.username); }); });
→ GitHubのテストプロジェクトへのリンク
このコードには、すべてのユーザーグループを検索するためのボーナスフィルターがあり、多数のグループを操作することは、ActiveDirectoryモジュールで提案されている方法よりも1桁高速です。
その結果、ページを開いたときに、すべてが正しく行われていれば、

予想される制限:
-URLアドレスをip:portの形式にすることはできませんが、DNS名のみ(ADでのWebサービスの登録に関連付けられています)
-この認証は特定のIE設定でのみ機能しますが、これらはデフォルト設定です(「イントラネットゾーンでのみネットワークに自動的にログオンする」、「組み込みWindows認証を許可する」)。 ChromeはIE設定を使用します。 他のブラウザでは設定が必要な場合があります。