WebアプリのLDAP統合を構築する方法は？
私の会社は、何百人もの顧客がいるSaaSアプリケーションを開発および販売しています。一部の顧客は、別のログインアカウントを作成する代わりに、既存のシステムに対してユーザーアカウントを認証するためのLDAP統合をサポートするように求めていますこれは多くの場所でシングルサインオン（SSO）と呼ばれていますか？当然、システムには既にユーザーアカウントプロファイルを維持し、ログインページからそれらのユーザーアカウントを認証するメカニズムがあります。
私たちはLDAPについて少し無知であり、いくつかのことについて混乱しています。間違った用語を使用する可能性があることをお許しください（これについては、私たちは少し無知です）.
これがどのように機能するかの基本を理解していると思います。
- お客様は、アカウントの「リモート認証」機能を「オン」にするようにアカウントを構成します。ユーザーを認証するリモートURLを提供します。
- ユーザーがログインページにアクセスし、会社のLDAPシステムから提供されたユーザー名とパスワードを使用してログインを試みます。
- ログインページは、ログイン資格情報（おそらく合意された形式で暗号化およびハッシュ化されたもの）を、お客様から提供された「リモート認証」URLに安全に転送します。
- 顧客のスクリプトはユーザーを認証し、「認証ステータス」を使用してサイトにリダイレクトします。
- このページは「認証ステータス」を分析し、ログインしているユーザーを受け入れるかどうかを決定します。
上記の情報が多少正確であっても、各ユーザーがシステムにアカウントを持っている必要があります。ユーザーアカウントプロファイルをLDAPディレクトリ内のユーザープロファイルと同期させる方法は必要ありませんか？これは単に、LDAPシステム内のユーザーのIDを参照する「外部ID」ですか？次に、システムのどのユーザーアカウントにログインを関連付けるかを知るために、顧客の「リモート認証」スクリプトがシステムにそのIDを提供する必要がありますか？
何が欠けていますか？
ところで、私たちのプラットフォームはIIS、ASP.Net 2.0、およびSQL Server 2005です。
いくつかのオプションがあります。 Active Directoryとは対照的に、本当にLDAPを意味する場合、System.DirectoryServices.Protocolsを使用して、安全なチャネルを介して提供された資格情報を使用してLDAPバインドを実行することを検討します。
厳密には、これはシングルサインオンではありません。 SSOとは、最初にログオンしたときに一度だけ資格情報を送信することを意味します。これは、IDを1つだけにすることで、ユーザーの複雑さを軽減するだけです。通常、プラットフォームとテクノロジーが混在するエンタープライズ環境のWindowsクライアントの場合、SSOは、さまざまなシステムへの認証を管理するデスクトップに追加されたクライアントによって実現されます。 MSのみの環境では、すべてのWebアプリがIIS上にある場合、SSOを実現できます。IEを使用し、統合Windows認証、偽装などを使用します。
プロファイルタイプのデータを事前に設定する必要がない限り、認証されたユーザーをシステムに自動登録することを検討できます。ユーザーの事前設定が必要な場合は、管理者が既存のリストから選択しないように、LDAPディレクトリからユーザー（またはすべてのフィルター処理されたサブセット）を定期的にインポートして未構成状態にすることを検討できます-IDを入力するのではなく、構成されたユーザー。そうしないと、管理者が間違ったユーザーIDを入力して不一致になる危険があります。
IDとアクセス管理ソリューション（Microsoftの傾斜を考慮して、ILM2 007を例として参照）がシステムと統合し、ユーザーアカウント管理のすべてを実行できるようにAPIを提供できます。
いつものように、送信されたパスワードが空白でないことを確認するために認証テストを検証することを忘れないでください。
ユーザー名がありパスワードが設定されていないバインドは、標準に従って匿名バインドと見なされ、成功したように見えます！実際には、そうではありませんでした。
これは、LDAPサーバーが煩わしい標準ですが、それでも標準に準拠しているため、アプリケーションが処理する問題です。
おそらく認証と承認を検討してください
認証-これはどのユーザーですか？承認-アプリケーション、指定されたユーザー、グループを使用できるのは誰ですか？
現在、アプリに登録されているユーザーのみがアプリの使用を許可されているため、認証による承認を暗示しています。
カスタムデータストアの代わりにディレクトリを使用する場合
- ディレクトリ接続方法を使用してユーザーを認証する
- あなたは（無料で）認証を取得します-ユーザーはwindowsに知られており、windowsはiisとsqlserverに識別できます。
- 承認されているユーザーよりも多くのユーザーを知っており、制限を適用する必要があります-特定のグループへの接続を制限します。
- sqlサーバーのアプリデータではなく、ディレクトリにユーザーデータを保存できます。
ユーザーが本当に汎用LDAPを必要とする場合は、（C）ldap_connect, ldap_bind_s（C＃）LDAPConnection System.DirectoryServices.Protocols
または、ADに戻ります Demystified .Net Appシングルサインオン
これがシステムでどのように機能するか：
- ユーザーがWebアプリに移動すると、REMOTE_USERサーバー変数はユーザートークンであると想定されます
- ログインコードは、検索固有のアカウントでldapディレクトリに接続します
- ログインコードは、REMOTE_USERと「一致する」LDAPアカウントを探します。
- 次に、ログインコードは、そのアカウントをシステム内のアカウントと一致させようとします
- 照合が最後まで可能である場合、ユーザーが照合されたアカウントとしてログインしていると想定し、通常どおり続行します
これにより、ユーザーはアプリ内でWindowsドメイン認証を再利用できます。
JSON-RPCを使用して、Web経由でLDAPディレクトリにアクセスできるソフトウェアの便利なビットを次に示します。 Json2Ldap
LDAPユーザーをアプリケーション内のアカウントにリンクする方法を決定する必要があります。
たとえば、LDAPシステム内のユーザー名がアプリ内のユーザー名と一致するように要求したり、アプリ内の各ユーザーアカウント内でLDAPユーザー名を明示的に指定するよう要求したりできます。
そのリンクがわかれば、LDAPバインドを実行するだけでユーザー資格情報をテストできます。