3

顧客の主要な顧客ポータルとして機能するASP.NETソリューションがあります。このWebサイトでは、ユーザーはログインして重要な財務情報などにアクセスできます。このWebサイトは、ユーザーのユーザー名（電子メール）とパスワード（ソルトハッシュ）をUsersローカルデータベースのテーブルと照合するカスタム認証スキームを使用しています。

私は、これらの同じ顧客が注文に使用するWebアプリツールである新しいMVC.NETソリューションを構築しています。ASP.NETポータルのサインオンメカニズムを再利用して、ユーザーを認証したいと思います。目標は、ユーザーが2回のログインを覚えたり、同じログインを2回指定したりする必要がないようにすることです。

ASP.NETソリューションにサインオンしたユーザーがMVC.NETソリューションに対して自動認証されるようにするための私のオプションは何ですか？以下にいくつかのアイデアをリストしましたが、これらは「悪い」ですか、それとももっとエレガントな解決策がありますか？私はあなたの入力が大好きです。

  • 共通 のCookieASP.NETサイトが作成してMVC.NETサイトが検索する共通のCookieを作成できます。しかし、それは十分に安全ですか？
  • クエリ文字列 のトークンローカルデータベースに格納されているASP.NETサイトにトークンIDを作成し、MVC.NETサイトへのリンクのクエリ文字列で渡してトークンIDを取得し、それを検証します。同じデータベース。
  • ハイブリッド 両方のビット？
  • 他の？ より良いアイデアがありますか？
4

4 に答える 4

3

私は最近、OpenIdを使用して非常に似たようなことをしました（主な違いは、外部の顧客ではなく社内で行われたことです） 。

OpenId for .NETの実装は、DotNetOpenAuthと呼ばれ、目的に適している必要があります。

実装するのに少し時間がかかりました。しかし、それは非常にうまく機能し、非常に柔軟性があり、非常に安全です。

openidに関する詳細情報（ウィキペディアから）：

OpenIDは、サードパーティのサービスを使用して特定の協力サイト（Relying PartyまたはRPと呼ばれる）によってユーザーを認証できるようにするオープンスタンダードであり、ウェブマスターが独自のアドホックシステムを提供する必要がなく、ユーザーがデジタルを統合できるようにします。アイデンティティ。

ユーザーは、好みのOpenID IDプロバイダーでアカウントを作成し、それらのアカウントを、OpenID認証を受け入れる任意のWebサイトにサインオンするための基礎として使用できます。OpenID標準は、IDプロバイダーとOpenIDアクセプター（「依拠当事者」）の間で行われなければならない通信のためのフレームワークを提供します。2標準の拡張（OpenID属性交換）により、名前や性別などのユーザー属性をOpenID IDプロバイダーから証明書利用者に簡単に転送できます（各証明書利用者は、要件に応じて異なる属性のセットを要求できます）。 ）。

OpenIDプロトコルは、ユーザーのIDを認証するために中央機関に依存しません。さらに、サービスもOpenID標準も、ユーザーを認証するための特定の手段を義務付けていないため、一般的なもの（パスワードなど）から新しいもの（スマートカードやバイオメトリクスなど）までのアプローチが可能です。

ああ、さらに励ましが必要な場合は、StackExchangeがそれを使用します。

@Jmrnet：あなたの最後のコメントに応えて：

たぶん私ははっきりしていませんでした。OpenId自体は、ある場所から別の場所へ（多かれ少なかれ）資格情報を検証するためのものです。ユーザーが何も変わらないSSOモデルとして実装することは完全に可能です。プロバイダーを選択したり、登録したりする必要はありません。たとえば、私の設定では、ユーザーはWebポータルにユーザー名とパスワードを入力し、ボタンをクリックして、OpenIdによって自動的にログインしている別のサイトを起動します。ユーザーにとって何も変わりません！OpenIdは、考えられる任意の初期認証モデルで使用できます（ウィキペディアのスニペットの太字のセクションに注意してください）。

于 2013-03-15T15:32:49.507 に答える
2

SAMLを見てください：

http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

XMLを使用して動作し、暗号化をサポートします。

于 2013-03-15T15:47:00.793 に答える
0

現在、同じプロジェクトに2つのSSOソリューションを実装しています。

1つは、外部パートナーとのインターフェースであり、SAMLを使用しています。

もう1つは、ログインしたユーザーがSharepointにアクセスできるようにし、Sharepointがメンバーシップテーブルにアクセスすることを信頼しているため、「TokeninQueryString」アプローチを使用することです。このアプローチは、SAMLトークンを処理するよりもはるかに簡単です。

于 2013-03-15T15:38:40.767 に答える
0

使用できる方法はたくさんあります。MansfiedではOpenIDについて説明し、RandomUs1rではSAMLについて説明しています。また、関連情報をlocalStorageまたはセッションに保存できます。セッションで関連情報を保存する必要があると思います。

これをクエリ文字列に入れるのは安全ではありません。登録してログインすると、URLにUserID=1234のようなものが表示されるためです。これをUserID=1235に変更し、IDが存在する場合、他のユーザーの名前でいくつかのことを実行できます。これは個人情報の盗難と呼ばれ、可能な限りの手段で防止する必要があります。したがって、URLにこの種の情報を含めることはできません。また、ユーザーのIDを保存する場合は、なんらかの方法で難読化する必要があります。たとえば、値をローカルストレージに保存し、1234の代わりにencrypt（1234、salt）を保存すると、ユーザーアクションの一貫性が維持されます。

于 2013-03-15T16:38:02.400 に答える