ASP.NET MVC-ロールプロバイダーの代替？
私は自分の意見では不器用すぎるので、ロールプロバイダーとメンバーシッププロバイダーの使用を避けようとしています。そのため、不器用ではなく、管理しやすく、柔軟性のある独自の "バージョン"を作成しようとしています。さて、私の質問です。適切なロールプロバイダーに代わるものはありますか？ （私はカスタムのロールプロバイダー、メンバーシッププロバイダーなどができることを知っています）
より管理しやすく、柔軟性があるということは、Roles静的クラスの使用に制限されており、データベースコンテキストと対話するサービスレイヤーに直接実装しないことを意味します。代わりに、独自のデータベースコンテキストを持つRoles静的クラスを使用することにバインドしますなど、テーブル名もひどいです。
前もって感謝します。
私はあなたと同じ船に乗っています-私は常にRoleProvidersを嫌っていました。ええ、もしあなたが小さなwebsiteのために物事を立ち上げて実行したいなら素晴らしいですが、それらはあまり現実的ではありません。私がいつも見つけた主な欠点は、ASP.NETに直接結びつくことです。
私が最近のプロジェクトに行った方法は、サービス層の一部であるいくつかのインターフェースを定義することでした（注：これらはかなり単純化されていますが、簡単に追加できます）。
public interface IAuthenticationService
{
bool Login(string username, string password);
void Logout(User user);
}
public interface IAuthorizationService
{
bool Authorize(User user, Roles requiredRoles);
}
次に、ユーザーはRoles列挙型を持つことができます：
public enum Roles
{
Accounting = 1,
Scheduling = 2,
Prescriptions = 4
// What ever else you need to define here.
// Notice all powers of 2 so we can OR them to combine role permissions.
}
public class User
{
bool IsAdministrator { get; set; }
Roles Permissions { get; set; }
}
IAuthenticationServiceの場合、標準のパスワードチェックを行う基本実装を用意し、次にCookieの設定など、もう少し行うFormsAuthenticationServiceを用意できます。AuthorizationService、次のようなものが必要です。
public class AuthorizationService : IAuthorizationService
{
public bool Authorize(User userSession, Roles requiredRoles)
{
if (userSession.IsAdministrator)
{
return true;
}
else
{
// Check if the roles enum has the specific role bit set.
return (requiredRoles & user.Roles) == requiredRoles;
}
}
}
これらの基本サービスに加えて、パスワードをリセットするサービスなどを簡単に追加できます。
MVCを使用しているため、ActionFilterを使用してアクションレベルで承認を行うことができます。
public class RequirePermissionFilter : IAuthorizationFilter
{
private readonly IAuthorizationService authorizationService;
private readonly Roles permissions;
public RequirePermissionFilter(IAuthorizationService authorizationService, Roles requiredRoles)
{
this.authorizationService = authorizationService;
this.permissions = requiredRoles;
this.isAdministrator = isAdministrator;
}
private IAuthorizationService CreateAuthorizationService(HttpContextBase httpContext)
{
return this.authorizationService ?? new FormsAuthorizationService(httpContext);
}
public void OnAuthorization(AuthorizationContext filterContext)
{
var authSvc = this.CreateAuthorizationService(filterContext.HttpContext);
// Get the current user... you could store in session or the HttpContext if you want too. It would be set inside the FormsAuthenticationService.
var userSession = (User)filterContext.HttpContext.Session["CurrentUser"];
var success = authSvc.Authorize(userSession, this.permissions);
if (success)
{
// Since authorization is performed at the action level, the authorization code runs
// after the output caching module. In the worst case this could allow an authorized user
// to cause the page to be cached, then an unauthorized user would later be served the
// cached page. We work around this by telling proxies not to cache the sensitive page,
// then we hook our custom authorization code into the caching mechanism so that we have
// the final say on whether or not a page should be served from the cache.
var cache = filterContext.HttpContext.Response.Cache;
cache.SetProxyMaxAge(new TimeSpan(0));
cache.AddValidationCallback((HttpContext context, object data, ref HttpValidationStatus validationStatus) =>
{
validationStatus = this.OnCacheAuthorization(new HttpContextWrapper(context));
}, null);
}
else
{
this.HandleUnauthorizedRequest(filterContext);
}
}
private void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
// Ajax requests will return status code 500 because we don't want to return the result of the
// redirect to the login page.
if (filterContext.RequestContext.HttpContext.Request.IsAjaxRequest())
{
filterContext.Result = new HttpStatusCodeResult(500);
}
else
{
filterContext.Result = new HttpUnauthorizedResult();
}
}
public HttpValidationStatus OnCacheAuthorization(HttpContextBase httpContext)
{
var authSvc = this.CreateAuthorizationService(httpContext);
var userSession = (User)httpContext.Session["CurrentUser"];
var success = authSvc.Authorize(userSession, this.permissions);
if (success)
{
return HttpValidationStatus.Valid;
}
else
{
return HttpValidationStatus.IgnoreThisRequest;
}
}
}
次に、コントローラーのアクションを装飾できます。
[RequirePermission(Roles.Accounting)]
public ViewResult Index()
{
// ...
}
このアプローチの利点は、依存関係の注入とIoCコンテナーを使用して物事を結び付けることができることです。また、ASP.NETだけでなく、複数のアプリケーションで使用することもできます。 ORMを使用して適切なスキーマを定義します。
FormsAuthorization/Authenticationサービスの詳細や、今後の手順については、お知らせください。
編集：「セキュリティトリミング」を追加するには、HtmlHelperを使用します。これはおそらくもう少し必要です...しかし、あなたはアイデアを得ます。
public static bool SecurityTrim<TModel>(this HtmlHelper<TModel> source, Roles requiredRoles)
{
var authorizationService = new FormsAuthorizationService();
var user = (User)HttpContext.Current.Session["CurrentUser"];
return authorizationService.Authorize(user, requiredRoles);
}
そして、あなたのビューの中で（ここではRazor構文を使用しています）：
@if(Html.SecurityTrim(Roles.Accounting))
{
<span>Only for accounting</span>
}
編集：UserSessionは次のようになります。
public class UserSession
{
public int UserId { get; set; }
public string UserName { get; set; }
public bool IsAdministrator { get; set; }
public Roles GetRoles()
{
// make the call to the database or whatever here.
// or just turn this into a property.
}
}
このように、現在のユーザーのセッション内のパスワードハッシュやその他の詳細は公開されません。ユーザーのセッションの存続期間はreallyは不要だからです。
ここの@TheCloudlessSkyの投稿に基づいてロールプロバイダーを実装しました。自分が行ったことを追加して共有できると思ったことがいくつかあります。まず、アクションフィルターのRequirepPermissionクラスを属性として使用する場合は、ActionFilterAttributeクラスのRequirepPermissionクラスを実装する必要があります。
インターフェイスクラスIAuthenticationServiceおよびIAuthorizationService
public interface IAuthenticationService
{
void SignIn(string userName, bool createPersistentCookie);
void SignOut();
}
public interface IAuthorizationService
{
bool Authorize(UserSession user, string[] requiredRoles);
}
FormsAuthenticationServiceクラス
/// <summary>
/// This class is for Form Authentication
/// </summary>
public class FormsAuthenticationService : IAuthenticationService
{
public void SignIn(string userName, bool createPersistentCookie)
{
if (String.IsNullOrEmpty(userName)) throw new ArgumentException(@"Value cannot be null or empty.", "userName");
FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);
}
public void SignOut()
{
FormsAuthentication.SignOut();
}
}
UserSession calss
public class UserSession
{
public string UserName { get; set; }
public IEnumerable<string> UserRoles { get; set; }
}
もう1つのポイントは、FormsAuthorizationServiceclassと、ユーザーをhttpContext.Session["CurrentUser"]に割り当てる方法です。この状況での私のアプローチは、userSessionクラスの新しいインスタンスを作成し、FormsAuthorizationServiceクラスでわかるように、httpContext.User.Identity.NameからuserSession変数にユーザーを直接割り当てることです。
[AttributeUsageAttribute(AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Constructor | AttributeTargets.Method, Inherited = false)]
public class RequirePermissionAttribute : ActionFilterAttribute, IAuthorizationFilter
{
#region Fields
private readonly IAuthorizationService _authorizationService;
private readonly string[] _permissions;
#endregion
#region Constructors
public RequirePermissionAttribute(string requiredRoles)
{
_permissions = requiredRoles.Trim().Split(',').ToArray();
_authorizationService = null;
}
#endregion
#region Methods
private IAuthorizationService CreateAuthorizationService(HttpContextBase httpContext)
{
return _authorizationService ?? new FormsAuthorizationService(httpContext);
}
public void OnAuthorization(AuthorizationContext filterContext)
{
var authSvc = CreateAuthorizationService(filterContext.HttpContext);
// Get the current user... you could store in session or the HttpContext if you want too. It would be set inside the FormsAuthenticationService.
if (filterContext.HttpContext.Session == null) return;
if (filterContext.HttpContext.Request == null) return;
var success = false;
if (filterContext.HttpContext.Session["__Roles"] != null)
{
var rolesSession = filterContext.HttpContext.Session["__Roles"];
var roles = rolesSession.ToString().Trim().Split(',').ToList();
var userSession = new UserSession
{
UserName = filterContext.HttpContext.User.Identity.Name,
UserRoles = roles
};
success = authSvc.Authorize(userSession, _permissions);
}
if (success)
{
// Since authorization is performed at the action level, the authorization code runs
// after the output caching module. In the worst case this could allow an authorized user
// to cause the page to be cached, then an unauthorized user would later be served the
// cached page. We work around this by telling proxies not to cache the sensitive page,
// then we hook our custom authorization code into the caching mechanism so that we have
// the final say on whether or not a page should be served from the cache.
var cache = filterContext.HttpContext.Response.Cache;
cache.SetProxyMaxAge(new TimeSpan(0));
cache.AddValidationCallback((HttpContext context, object data, ref HttpValidationStatus validationStatus) =>
{
validationStatus = OnCacheAuthorization(new HttpContextWrapper(context));
}, null);
}
else
{
HandleUnauthorizedRequest(filterContext);
}
}
private static void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
// Ajax requests will return status code 500 because we don't want to return the result of the
// redirect to the login page.
if (filterContext.RequestContext.HttpContext.Request.IsAjaxRequest())
{
filterContext.Result = new HttpStatusCodeResult(500);
}
else
{
filterContext.Result = new HttpUnauthorizedResult();
}
}
private HttpValidationStatus OnCacheAuthorization(HttpContextBase httpContext)
{
var authSvc = CreateAuthorizationService(httpContext);
if (httpContext.Session != null)
{
var success = false;
if (httpContext.Session["__Roles"] != null)
{
var rolesSession = httpContext.Session["__Roles"];
var roles = rolesSession.ToString().Trim().Split(',').ToList();
var userSession = new UserSession
{
UserName = httpContext.User.Identity.Name,
UserRoles = roles
};
success = authSvc.Authorize(userSession, _permissions);
}
return success ? HttpValidationStatus.Valid : HttpValidationStatus.IgnoreThisRequest;
}
return 0;
}
#endregion
}
internal class FormsAuthorizationService : IAuthorizationService
{
private readonly HttpContextBase _httpContext;
public FormsAuthorizationService(HttpContextBase httpContext)
{
_httpContext = httpContext;
}
public bool Authorize(UserSession userSession, string[] requiredRoles)
{
return userSession.UserRoles.Any(role => requiredRoles.Any(item => item == role));
}
}
次に、コントローラーでユーザーが認証された後、データベースからロールを取得し、それをロールセッションに割り当てることができます。
var roles = Repository.GetRolesByUserId(Id);
if (ControllerContext.HttpContext.Session != null)
ControllerContext.HttpContext.Session.Add("__Roles",roles);
FormsService.SignIn(collection.Name, true);
ユーザーがシステムからログアウトした後、セッションをクリアできます
FormsService.SignOut();
Session.Abandon();
return RedirectToAction("Index", "Account");
このモデルの注意点は、ユーザーがシステムにサインインしたときに、ユーザーにロールが割り当てられている場合、ユーザーがログアウトしてシステムに再度ログインしない限り、認証が機能しないことです。
もう1つは、データベースから直接ロールを取得し、それをコントローラーのロールセッションに設定できるため、ロールに個別のクラスを用意する必要がないことです。
これらすべてのコードの実装が完了したら、最後のステップとして、この属性をコントローラーのメソッドにバインドします。
[RequirePermission("Admin,DM")]
public ActionResult Create()
{
return View();
}
Castle Windsor Dependency Injectionを使用する場合、実装を選択した任意のソースからユーザー権限を確認するために使用できるRoleProviderのリストを挿入できます。
ロールに静的クラスを使用する必要はありません。たとえば、 SqlRoleProvider を使用すると、データベースでロールを定義できます。
もちろん、独自のサービスレイヤーからロールを取得する場合、独自のロールプロバイダーを作成するのはそれほど難しくありません。実装するメソッドはそれほど多くありません。
適切なインターフェースをオーバーライドすることにより、独自の membership および role プロバイダーを実装できます。
ゼロから始めたい場合、通常、これらのタイプのものは カスタムhttpモジュール として実装され、ユーザーの資格情報をhttpcontextまたはセッションに格納します。どちらの方法でも、おそらくある種の認証トークンを使用してCookieを設定する必要があります。