クライアントは、企業ソリューション（Active Directory）に基づいてユーザーに「シングルサインオン」認証機能を提供するためには、主要なアプリケーションが必要です。 これは、ビジネスアプリケーションがブラウザから提供された資格情報を信頼し、標準のログイン/パスワードのペアをユーザーに要求しないことを意味します。サーバー/ブラウザーの信頼はWindows統合認証メカニズムを基に構築されています。ASP.Net Webアプリケーションのシングルサインオン
私たちはIIS 5.0でホストされているドットネットフレームワーク2.0でASP.Net Webアプリケーションを使用しています。私たちはSSO機能を実装する必要があります。
これはほぼすべてのイントラネットアプリケーションが従うのと同じ要件であると確信しています。
IISでWindows統合ログインを有効にしたばかりの場合、＃1の項目に設定されます。
他の要件と矛盾するので、＃2でも可能かどうかわかりません。ブラウザはローカルログインしているユーザーの資格情報のみを渡します（＃1の必要に応じて）。あなたがAD経由で認証するWebフォームを構築した場合は、あなたの物語/段落に記載されている要件に違反します。
あなたのクライアントは＃2が本当に意味すると思いますか？彼らはここで何を望んでいるのですか？別のユーザーとしてログインする方法は？彼らは単にコンピュータからログオフし、他のユーザーとしてログインすることができます。
一般に、SSOの要件は、WS-FederationやSAML 2.0などのクレームベースのプロトコルで最もよく対処されます。原則として、これらのプロトコルはオープンスタンダードなので実装できますが、多くの専門知識が必要です。
新しいWindows Identity Foundation（旧称Genevaフレームワーク）には、SSOシナリオを有効にするプロトコルの実装が含まれていますが、プラットフォームをアップグレードする必要があります。
IDとパスワードを入力する必要がない代わりにカスタムフォーム認証を使用します。
前提条件：電子メールなどのユーザの詳細を持つ 1>データベーステーブル、役割などのユーザープロファイルが 3に格納されてい 2>エンタープライズアクティブディレクトリ> VBCOMまたはActiveXやからユーザーのドメインと名前を読み取ることができ、他のコンポーネントを書きますブラウザを介してWindowsマシン。
手順： すべてのフォームのpageloadでは、コンポーネント<を3> Active Directory <に接続する>を呼び出します。その方法はWindowsシステムから現在のユーザーの名前、ドメインを読み取る必要があります。 これらの詳細を検索します。存在する場合は、電子メールアドレスを照会して抽出するか、またはADユーザープロファイル内の一意のキーを抽出します。 このキーを使用してデータベース< 1>電子メール、ロールなどのアプリケーション固有のユーザーの詳細を格納します。 ADのユーザー電子メールがテーブルの電子メールと一致する場合、ユーザーが存在しないかロールがnull/restrictedの場合、ユーザーに適切なアクセス権を付与します。 有効なユーザーであれば、暗号化されたCookieを作成し、他のアプリケーションで読み取って実際にSSOを実装することができます。