タグ付けされた質問 「claims-based-identity」

まあ、厳密には5歳ではありませんが、可能であれば流行語や企業の発言は避けてください。 クレームベースの認証は今では大流行しているようですが、実際の内容、つまり現在のものとどのように異なるのかについてのシンプルで現実的な説明は見つかりませんでした（「今あるもの」を想定しています）。役割ベースの認証であること）、それを使用する利点など

188 terminology  claims-based-identity 

CBACとRBACを使用する主な利点は何ですかですか？いつCBACを使用するのが適切で、いつRBACを使用するのが適切ですか？ CBACモデルの一般的な概念を理解しようとしていますが、一般的な考え方はまだはっきりしていません。

147 asp.net-mvc  claims-based-identity  access-control  role-base-authorization  role-based 

偽造防止トークンに問題があります:(私は自分のUserクラスを作成しましたが、正常に機能しましたが、/ Account / Registerページにアクセスするたびにエラーが発生します。エラーは次のとおりです。 タイプ「http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier」または「http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider」のクレームは、提供されたClaimsIdentityには存在しません。クレームベースの認証で偽造防止トークンのサポートを有効にするには、構成されたクレームプロバイダーが、生成するClaimsIdentityインスタンスでこれらのクレームの両方を提供していることを確認してください。構成されたクレームプロバイダーが一意の識別子として別のクレームの種類を使用する場合は、静的プロパティAntiForgeryConfig.UniqueClaimTypeIdentifierを設定することで構成できます。 私はこの記事を見つけました： http://stack247.wordpress.com/2013/02/22/antiforgerytoken-a-claim-of-type-nameidentifier-or-identityprovider-was-not-present-on-provided-claimsidentity/ Application_Startメソッドを次のように変更しました。 protected void Application_Start() { AreaRegistration.RegisterAllAreas(); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes); BundleConfig.RegisterBundles(BundleTable.Bundles); AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Email; } しかし、それを行うと、次のエラーが発生します。 タイプ ' http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress 'のクレームは、提供されたClaimsIdentityに存在しませんでした。 誰かこれに出くわしたことはありますか？もしそうなら、それを解決する方法を知っていますか？ 事前に乾杯、 r3plica アップデート1 これが私のカスタムユーザークラスです： public class Profile : User, IProfile { public Profile() : base() { this.LastLoginDate = DateTime.UtcNow; this.DateCreated = DateTime.UtcNow; } public …

122 c#  asp.net-mvc  authentication  claims-based-identity 

Entity Framework 5 Database Firstアプローチを使用してMVC 5 Webアプリケーションを開発しています。ユーザーの認証にOWINを使用しています。以下は、私のアカウントコントローラー内の私のログインメソッドを示しています。 public ActionResult Login(LoginViewModel model, string returnUrl) { if (ModelState.IsValid) { var user = _AccountService.VerifyPassword(model.UserName, model.Password, false); if (user != null) { var identity = new ClaimsIdentity(new[] { new Claim(ClaimTypes.Name, model.UserName), }, DefaultAuthenticationTypes.ApplicationCookie, ClaimTypes.Name, ClaimTypes.Role); identity.AddClaim(new Claim(ClaimTypes.Role, "guest")); identity.AddClaim(new Claim(ClaimTypes.GivenName, "A Person")); identity.AddClaim(new Claim(ClaimTypes.Sid, …

119 asp.net  asp.net-mvc  authentication  asp.net-mvc-5  claims-based-identity 

私はclaimsin の使用にまったくASP.NETIdentity慣れていないので、の使用のベストプラクティスについて知りたいと思いRoles and/or Claimsます。 このすべてを読んだ後、私はまだ次のような質問があります... Q：ロールを使用しなくなりましたか？ Q：その場合、なぜ役割がまだ提供されているのですか？ Q：クレームのみを使用する必要がありますか？ Q：ロールとクレームを一緒に使用する必要がありますか？ 私の最初の考えは、それらを一緒に「使用すべき」であるということです。私ClaimsはRoles彼らがサポートするサブカテゴリとして見ています。 例： 役割：会計 クレーム：CanUpdateLedger、CanOnlyReadLedger、CanDeleteFromLedger Q：それらは相互に排他的であることを意図していますか？ Q：または、クレームのみに進み、クレームを「完全に修飾」する方が良いですか？ Q：では、ここでのベストプラクティスは何ですか？ 例：ロールとクレームを一緒に使用する もちろん、このために独自の属性ロジックを作成する必要があります... [Authorize(Roles="Accounting")] [ClaimAuthorize(Permission="CanUpdateLedger")] public ActionResult CreateAsset(Asset entity) { // Do stuff here return View(); } 例：申し立てを完全に修飾する [ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")] public ActionResult CreateAsset(Asset entity) { // Do stuff here return View(); }

94 asp.net-mvc  roles  claims-based-identity