2017-12-19 4 views
1

MVCアプリケーションでOpenID-Connectを使用してAzure AD認証を実装し、管理されたロールクレームを使用してアプリケーションでロール管理を有効にしました。カスタムクレームMVCアプリケーションのID管理

ここで、申し立て件数が非常に多いため、申し立てを管理するための新たなトラブルが発生しました。

SQL DB: 1)マスター請求表 2)ロール表 3)はRoleID - ClaimIDマッピングテーブル 4)UserClaimsテーブル - ユーザIDとroleidマッピングが維持される場所これは

C位を:

var identity = new ClaimsIdentity(new[] { 

     new Claim("UserMgt:Maintenance", "True"), 
     new Claim("UserMgt:Add", "True"), 
     new Claim("UserMgt:Add", "True") 
}, 
    "ApplicationCookie"); 

。 。 。

パフォーマンスが低下するかどうかはわかりません。 Azureでアプリケーションをホストし、ユーザーがログインするとすぐにクレジットをRediscacheに保存し、各ページの対応するクレームを読んで各ページ/モジュールにアクセスを提供します。

あなたに良い提案がある場合はお知らせください。

ありがとうございました

答えて

0

ログインクレームはCookieに保存されています。したがって、クッキーからのクレームの読み取りはかなり速く、データベースへのアクセスは必要ありません。

しかし、クッキーのサイズが問題になる可能性があります。 Cookieにあまりにも多くのデータを入れた場合、要求は過剰になります。 1つのクッキーは最大16Kbのヘッダー(ブラウザに依存)で最大4Kbになることができます。あなたがその限界にぶつかっているなら、あなたが主張でやっていることを再考する価値があります。 (AJAXのリクエストで、20文字で201リクエストが出るが、ネットワーク経由で約16KBのヘッダーがあるとする)。明らかに、クレームはクッキーで暗号化されていますが、データの増加率は約1.1です。私。クレームの1Kbのデータでは、実際のクッキーサイズは約1.1Kb(同じ問題を調査していたときのクッキーサイズを使った私の経験から)です。

これらの制限に当てはまらない場合は、私はそれについてあまり心配しないと言います。

+0

ご回答いただきありがとうございます。この問題に対する解決策はありますか?ページのナビゲーションに基づいてクレームを追加することを検討していました。そのページのアクション権限は、クレームに変換されます。ユーザーがそのページから移動した場合、クレームはユーザーIDから解放されます。だから私たちは認証クッキーのサイズを制御することができます..私はまだこのシナリオを処理するためのより良い解決策を模索しています..私はすべてのクレームをダンプし、ページを減速したくない... – user3527063

+0

私のソリューションは、それが問題になるまでは心配しないでください。生産ではそれほどデータではないことが判明しました。特に、数字でアクセス許可をエンコードする場合。許可された操作のためにページと列挙型にenumを使用しました。したがって、請求は「新しい請求(42、1)」のようになり、「42」は「MyClaimsEnum.UserManagement」に変換され、「1」は「MyEnumActions.View」に変換されます。 – trailmax

+0

私たちは約50のクレーム(いくつかのページは同じクレームの下にあります)と4つのアクション:ビュー、作成、編集、削除と約100の異なるページを持っています。そして、クレームのデータがあまりにも多くの問題を抱えていませんでした。つまり、あなたがまだ持っていない問題を解決しようとしているということです。 – trailmax

関連する問題