Ресурсы разработки схемы разрешений веб-сайта

Question

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

У меня много вопросов и не так много достоверной информации. И я не могу сформулировать плюсы и минусы доступных ответов.

• Должно ли оно быть основано на ролях и есть ли у пользователей роли?
• Должно ли это быть на основе группы?
  • Должны ли группы быть членами групп, как в AD?
  • Или только пользователи могут быть членами групп?
• Как мне обращаться с разрешениями по умолчанию?
  • Должно ли быть установлено на основе инструмента, который создает страницу?
  • Должен ли создатель создавать права на создание страницы?
• Должны ли пользователи создавать свои собственные группы?

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

Answer 1

Эти идеи могут быть полезны для вас, а могут и не быть полезными, но я с нуля создал веб-систему, основанную на разрешениях (мне нужно было низкоуровневое управление для интеграции с другой системой), например:

• Пользователи или группы могут иметь права доступа
• Действующий набор разрешений пользователя - это расширенный набор всех разрешений и запрещений для пользователя и групп, членом которых является пользователь
• Отмена отмены позволяет
• Права на уровне пользователя переопределяют любые настройки группы (позволяя вам предоставлять привилегии администраторам, супервизорам и т. Д.)
• Эффективный набор разрешений пользователя сохраняется в сеансе при входе в систему, а затем разрешения проверяются с помощью диспетчера разрешений (с использованием побитовых операций)

• Каждая область разрешений имеет свою собственную битовую маску, которая хранится в БД, что позволяет вам автоматически генерировать служебный класс разрешений как часть процесса сборки. Утилита класса выглядела так:

  public static class Area1
  {
      public static int AreaId { get { return 1; } }
      public static int Permission1 { get { return 1; } }
      public static int Permission2 { get { return 2; } }
      public static int Permission3 { get { return 4; } }
  }
  public static class Area2
  {
      public static int AreaId { get { return 2; } }
      public static int Permission1 { get { return 1; } }
      public static int Permission2 { get { return 2; } }
      public static int Permission3 { get { return 4; } }
      public static int Permission4 { get { return 8; } }
      public static int Permission5 { get { return 16; } }
  }
  

  и т.д ...

• Затем вы можете определить базовую страницу разрешений:

  public class PermissionsPage: BasePage
  {
      int _permissionAreaId;
      int _permissionValue;
      string _page;
  
  public PermissionsPage(int permissionAreaId, int permissionValue)
      : base()  
  {
      Init += new EventHandler(PermissionsPage_Init);
      _permissionTypeId = permissionTypeId;
      _permissionValue = permissionValue;
  }
  
  void PermissionsPage_Init(object sender, EventArgs e)
  {
      if (!IsPostBack)
      {
          _page = Request.Url.Segments.Last();
          if (!PermissionsManager.TestPermission(UserWebSession.User, _permissionTypeId, _permissionValue))
          {
              // handle permission denied
          }
          else
          {
              // log page access
          }
      }
  }
  

  }

• Файл утилиты позволяет вам делать такие вещи во время разработки:

  public partial class yourControlledPage : PermissionsPage
  {
       // test permission over an entire page
       public yourControlledPage()
          : base(PermissionDef.Area1.AreaId, PermissionDef.Area1.Permission1)
       {
       }
  }
  

• или

   // test permission over a specific control
   yourDropDownList.Enabled = PermissionsManager.TestPermission(UserWebSession.User, PermissionDef.Area2.AreaId, PermissionDef.Area2.Permission4);
  

* Где 'Area1' и 'Permission1', например, заменены значимыми именами .. очевидно!

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

Answer 2

Я был впечатлен гибкостью и мощью системы разрешений KnowledgeTree .

Это примерно организовано следующим образом: Бизнес-единицы -> Группы (и подгруппы) -> Роли -> Пользователь

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

Это позволяет вам устанавливать довольно широкие разрешения для групп и действительно сужать их, устанавливая более явные разрешения для роли. Затем пользователи назначаются на роли по мере необходимости; Пользователь A может быть назначен на роль редактора для каталога X, но не на Y. Эти полномочия будут располагаться поверх группы пользователей A, в которой он уже находится.

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

TYPOlight webCMS устраняет эту проблему, хотя и не так надежно. Каждый пользователь в CMS может использовать свои групповые разрешения (только), расширять свои групповые разрешения индивидуальными разрешениями или использовать индивидуальные разрешения (только).