Webアプリケーション-ドメイン間でのユーザー認証

Question

私たちのクライアントが私たちにアプリケーションを開発するようにアプローチしてきましたが、いつものようにスコープは日々成長しています。

当初は、企業ネットワーク内に限定された専用アプリとして始まりました。ユーザー認証は、ユーザーのWindowsログインを取得し、SQLServerデータベースを使用してアクセス権をホストすることにより確立されました。すべて非常に簡単です。

次のものが必要になりました：
-Webベースにするアプリケーション
-企業ネットワークの外部でホストされるアプリケーション
-同じ方法で機能するユーザー認証（パスワードを使用せず、Windowsログインのみ）

さらに複雑にするために、彼らはアプリケーションのさまざまな機能を、HTTPリクエストを発するだけの別のアプリケーションが使用できるようにしたいと考えています。
-ユーザーは企業ネットワークにログインします
-ユーザーが企業アプリケーションを起動する
-ユーザーが顧客の詳細を処理する
-ユーザーがボタンをクリックする
-企業アプリケーションは、ホストされているWebアプリにHTTPリクエストを送信します
-HTTPリクエストには、必要な認証と顧客の詳細が含まれています
-ユーザー認証は「自動的に」完了します（人間の関与なし）
-顧客データは安全に送信されます

彼らは私たちの最初のアプローチが彼らが望んだものであったので、彼らのためにこれを行うことを非常に切望しています。そのようなホストされたWebアプリは私たちの専門ではありませんが、彼らはまだこれを行うことを望んでいます。だから私は今、専門家にアプローチします;
-これにアプローチする方法についてアドバイスはありますか？
-回避すべき落とし穴に関する警告はありますか？

Answer 1

基本的に彼らはフェデレーションアクセスについて話している。ネットワーク内で認証ポイントをホストします。認証ポイントは、トークンをアプリケーションに転送し、アプリケーションがトークンを解析して許可（またはアクセスを停止）します。これはかなり標準的なものであり、MSは Geneva Framework 。これは、WSFedをプロトコルとして使用するようにアプリケーションを変更し、認証トークンをサイレントに発行するセキュリティトークンサービスと通信できる場合、Webサービスコールでも機能します。ほとんどの場合、これにはSAMLを使用します。また、企業ネットワークの外に出ることのない認証詳細の追加ボーナスもあります。

証明書ベースの認証の提案は興味深いものですが、PKIインフラストラクチャの展開にはより多くの作業が必要です。これにはコストがかかる場合があります。

CardSpaceは機能しません-彼らが望むように、それは静かではありません。 OpenIDもスターターではなく、サイレントでもありません。

Azureを見る場合の追加ポイント-Azureの認証ビットも内部でSAML / WSFedを使用し、Genevaのビットが含まれています。したがって、クラウドに移行した場合、各顧客はネットワーク内でログインページを設定するだけで済みます。そのページを信頼して認証トークンを発行し、ルールに従って解析するだけです。

Answer 2

証明書ベースの認証によるWCF通信、つまり、会社が有効な証明書を提供するサービスを使用する外部ユーザーへの通信かもしれません。これにより、ユーザー名パスワードは不要になりますが、ユーザーをそのまま使用できます。

Answer 3

すでに SAML をご覧になりましたか？

Answer 4

Windows CardSpace をご覧ください。Windowsログインと統合されており、SSOが可能です。必要なシナリオ。

Answer 5

アプリの構築方法に応じて、web.configのmachineKeyを操作して、シングルサインオン（SSO）でのAJAX呼び出しを許可できます。 これには、企業ネットワーク内の小さなasp.netアプリを使用して、認証トークンを配布し、ホストされているアプリにリダイレクトします。

2つのアプリが同じmachineKeyを共有する場合、asp.net認証システムはユーザーをホストされたアプリに喜んで許可します。

このアプローチには問題があります：

• 別の依存関係をシステム（企業ネットワーク内の認証アプリ）に導入します。これは単純なアプリですが、アクセス権がない場合に問題を診断しようとすると問題に直面します。
• ホストされたサービスは、認証アプリと同じドメインにある必要があります（そのため、HTTP Cookieの認証チケットが渡されます。）
• 情報を保護するために、ホストされているサービスのSSL証明書も必要です。 （実際には欠点ではありません。とにかくこれをやりたいと思うでしょう。）
• あなたとあなたのクライアントは共有されたmachineKeyを持っているので、あなたはあなたのアプリのインスタンスをその特定のクライアントに結び付けます。

Answer 6

これにはプライベートOpenIDプロバイダー/サーバーを使用します。