мелкозернистые разрешения; PrincipalPermission - роли отдельно от разрешений;

Question

Я некоторое время использую PrincipalPermission в службах wcf. [PrincipalPermission (SecurityAction.Demand, Role = SecurityRoles.CanManageUsers)]

Наши роли имеют префикс: Can * и как мы достигаем управления мелкозернистыми действиями со встроенной системой членства asp.net.

Это затрудняет понимание бизнес-единицы, какие мелкие роли мы можем предоставить пользователю.

Вот мой новый подход и хотел бы посмотреть, сможет ли кто-нибудь обеспечить обратную связь, обзор кода, прежде чем я воплощу свое предложение.

1) aspnet_roles - бизнес-единица роль

2) Расширить систему членства asp.net путем создания таблицы разрешений и Role_Permission таблицы и User_Permission таблицу (многие ко многим)

3) создавать пользовательские CodeAccessSecurityAttribute + который смотрит на новые таблицы [CustomPermissionCheck (Security.Demand, HasPermission = "can *")] первая итерация я статически новый зависимый репозиторий. В идеале я хотел бы использовать атрибут стиля aop, в который встроен репозиторий IPermissionRepository.HasPermission (...);

Если я подхожу к новому способу, я, вероятно, перестану наследовать от CodeAccessSecurityAttribute - что могут сказать об этом ребята из безопасности?

Кто-нибудь еще решил это, есть ли что-то в рамках, которое я пропустил?

Answer 1

Я бы сказал, что если вы находитесь в ASP.NET, тогда вы должны реализовать custom RoleProvider.

В вашем пользовательском RoleProvider вы получите доступ к другой таблице, в которой бы были объединены бизнес-группы с мелкозернистыми разрешениями.

Затем, когда вы узнаете пользователя, вы можете узнать, в какой бизнес-группе они находятся, и назначить все соответствующие роли в RoleProvider и не изменять какой-либо существующий код, который у вас есть.

Он также работает лучше, потому что он позволяет вам изменять, какие группы имеют какие разрешения легко, сохраняя при этом модель домена для разрешений чистой на стороне кода.

Answer 2

Я реализовал первую итерацию, и она работает красиво. [PermissionValidate (SecurityAction.Demand, HasPermission = CensusSchedulerRoles.CanUpdateCensusScheduler)]

public void Demand() 
{ 
    var principal = Thread.CurrentPrincipal; 
    if(principal == null || principal.Identity.IsAuthenticated == false) 
    { 
     throw new SecurityException("Unable to get IPrincipal."); 
    } 
    if(principal.Identity.IsAuthenticated == false) 
    { 
     throw new SecurityException("You must be authenticated."); 
    } 
    #warning this should be moved to an aop attribute that is injected by a ioc container. 
    using (var connection = new SqlConnection(System.Configuration.ConfigurationManager.ConnectionStrings["......."].ConnectionString)) 
    { 
     connection.Open(); 
     using(var command = new SqlCommand(
     @" 
      SELECT COUNT(t.name) FROM 
      (
       SELECT p.name, u.UserName FROM 
        aspnet_Users as u 
        INNER JOIN [User_Permission] as up 
         ON up.user_id = u.UserId 
        INNER JOIN Permission as p 
         ON p.id = up.permission_id 
       UNION 
       SELECT p2.name, u2.UserName FROM 
        aspnet_Users as u2 
        INNER JOIN aspnet_UsersInRoles as uir 
         ON uir.UserId = u2.UserId 
        INNER JOIN aspnet_Roles as r 
         ON r.RoleId = uir.RoleId 
        INNER JOIN Role_Permission as rp 
         ON rp.role_id = r.RoleId 
        INNER JOIN Permission as p2 
         ON p2.id = rp.permission_id 
      ) as t 
      WHERE t.UserName = @username AND t.name = @haspermission 
     ", connection)) 
     { 
      command.Parameters.Add("@username", SqlDbType.VarChar).Value = Thread.CurrentPrincipal.Identity.Name; 
      command.Parameters.Add("@haspermission", SqlDbType.VarChar).Value = _permissionRequested; 

      if(Convert.ToInt32(command.ExecuteScalar()) <=0) 
      { 
       throw new SecurityException(String.Format("User '{0}' is not assigned permission '{1}'.", principal.Identity.Name, _permissionRequested)); 
      } 
     } 
    } 
}