2017-05-29 2 views
1

のは、私たちがあるウェブサイトを持っているとしましょう:2つの認証クッキー

  • 管理セクション
  • Clientセクション
  • ユーザーレビュー(ビジター)セクション

明らかに、最後の1つ(ゲストセクション)には管理者がアクセスすることができますが、管理者とクライアントのみがアクセスすることができます。 管理者とクライアントは異なるモデルクラス(管理者とユーザーに対応する)を持ち、それぞれ異なるデータベースに格納されており、それぞれに異なる認証クッキーを使用したいと考えています。 ASP.NET Core Identityを使用することは可能ですか?

は、我々はAddIdentityの初期化中のCookieNameプロパティを使用しようとしたが、それはアクセスがそのApplicationCookieを表示されます - 2番目の定義は、単に最初のものに書き換えるので、同じオブジェクトは、次のとおりです。

services 
    .AddIdentity<User, UserRole>(opts => { 
     opts.Cookies.ApplicationCookie.CookieName = "Client"; 
     opts.Cookies.ApplicationCookie.LoginPath = new PathString("/login"); 
      . . . . . . 

    }); 



services 
    .AddIdentity<Admin, AdminRole>(opts => { 
     //the following lines rewrite cookie options from client's to admin's 
     opts.Cookies.ApplicationCookie.CookieName = "Admin"; 
     opts.Cookies.ApplicationCookie.LoginPath = new PathString("/admin/login"); 
      . . . . . . 
    }); 
+2

はあなたが各役割に1人のアイデンティティを持っていることになっていない、あなたは、各セキュリティの必要性のための1つの役割を持っていることになっています。あなたは、ほとんどの場合、あなたがさて、あなたがそれらを別のデータベースに格納されているかもしれませんが、アプリケーションの観点から、彼らはすべてのユーザーであるいくつかのロジック –

+0

に応じて、ユーザーまたは管理DBを照会するかどうかを決定することができますカスタムのIdentityStoreを必要としています。私はこれがあなたの質問に答えないことを知っているが、私が言っていることは多分あなたのデザインを再考すべきであるということです。 – JuanR

+0

2つ(または3つ)の異なるアプリケーションが好きです。 – Mike

答えて

2

可能?はい。さまざまなクッキーを処理する独自のIDミドルウェアを作成する必要がありますが、それを行うことができます。

推奨しますか?認証と認可:NO

は、セキュリティと2つの別々の問題があります。クッキーは、認証(誰かがある)とのためにうまく動作しますが、あなたはここで解決しようとしているものである、認可(誰かがやるとへのアクセス権を持つことができるか)、のための役割及び特許請求の範囲を使用する必要があります。

ASP.NETのアイデンティティ・フレームワークでは、すでにロールとクレームの両方がサポートされているため、全員に標準のユーザー・モデルを使用したり、一部のユーザーに「管理者」ロールを追加したり、

承認を処理するためのdocumentationは非常に詳細で、あなたにオプションの偉大なチュートリアルを提供します。

役割:

[Authorize(Roles = "Administrator")] 
public class AdministrationAreaController : Controller 
{ 
    public IActionResult Index() 
    { 
    } 
} 

特許請求の範囲

[Authorize(Policy = "EmployeeOnly")] 
public class ClientAreaController : Controller 
{ 
    public IActionResult Index() 
    { 
    } 
} 
を以下に示すように両方の役割および特許請求の範囲を容易に、自分のコントローラのルート方法の[属性]を使用して、ユーザ・プロファイルに追加することによって実施することができます
+0

認証と認可の違いと、認可のための役割/クレームのアプローチがわかっています。 これらのエンティティ(ユーザーと管理者)には、適切な承認動作のための役割の独自のリストがあります。 – Sergiy

+0

ユーザーと管理者を分割する必要がある理由は、次のとおりです。 1。私たちは完全に異なる2つの場所に格納します(ユーザー - SQL DB、管理者 - Azureテーブルストレージ)。 2.名前とパスワードのハッシュを除いて全く異なるプロパティセットがあります。 3.より安全です。ハッカーが追加のロール/クレームをユーザーに追加する方法を見つけた場合、何もひどいことは起こりません。同じストレージを共有していた場合、「管理者」の役割を一部のアカウントに追加すると、そのようなハッカーはシステムに完全にアクセスできます。 – Sergiy

+1

この場合の「ユーザー」は、アプリケーションの認証された関係者です。 Cookieとアイデンティティは、ユーザーデータストレージとはまったく異なります。異なるデータベースがあるかどうかは関係ありません。カスタムロジックを使用して適切なdbをチェックし、同じクッキースペースでログインすることができます。また、可能なすべてのプロパティまたはDictionary <>を含む一般的な 'User'モデルを使用して、ロール(adminまたはclient)とクレーム(特定の権限)の組み合わせを使用して認証することもできます。 –

関連する問題