2008-10-04 2 views
5

Публикации и/или совместные приложения часто связаны с доступом к ресурсам. В портале пользователю может быть предоставлен доступ к определенному контенту в качестве члена группы или из-за явного доступа. Полный набор контента может включать общедоступный контент, контент участника группы и частный пользовательский контент. Или, с совместными приложениями, мы можем захотеть передать ресурсы как часть рабочего процесса или предоставить хранилище документа для целей редактирования.Каковы наилучшие методы авторизации списка ресурсов?

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

У меня есть два вопроса:

  1. Это довольно легко разрешить пользователю, как только вы извлекаться ресурс, но как эффективно выполнять авторизацию в списке доступных ресурсов? И,

  2. Можно ли отделить эту авторизацию от ядра приложения? Возможно, в отдельную службу? Разделившись, как вы можете отфильтровать запросы, такие как «Получить все документы, которые я могу увидеть с заголовком, например [SomeSearchTerm]»? Мне кажется, что ваша отдельная система должна будет скопировать много справочных данных.

ответ

0

Я вообще есть схема, как этого

Пользователи − − ∈ UserDocuments ∋ − − Документы

Тогда я создать представление "ProfiledDocuments"

SELECT <fields> 
FROM Documents d 
INNER JOIN UserDocuments ud on ud.DocumentId = d.Id 
INNER JOIN Users u ON u.Id = ud.UserId 

Затем запустите поиск запросов на ProfiledDocuments, всегда используя фильтр UserId э. С соответствующими индексами он работает достаточно хорошо.

Если вам нужны более сложные разрешения, вы можете сделать это с дополнительным полем в таблице UserDocuments для многих таблиц, которая определяет вид разрешения.

0

Хотя ваш вопрос достаточно проработан, на самом деле есть недостающий контекст.
Что определяет документы, на которые у пользователя есть привилегии? Может ли пользователь редактировать свои «собственные» файлы? Здесь есть механизм, основанный на ролях? Является ли он более ориентированным на MAC (то есть пользователь может видеть уровень безопасности)? Существует ли определяющий атрибут для данных (например, отдела)?

Все эти вопросы вместе могут дать лучшую картину и дать более конкретный ответ.

Если документы являются «принадлежащими» конкретным пользователем, его довольно простой - иметь поле «владелец» для документа. Затем запросите все документы, принадлежащие пользователю.
Аналогично, если вы можете предварительно определить список именованных пользователей (или ролей), имеющих доступ, вы можете запросить объединенный список между документами, список авторизованных пользователей/ролей и пользователя (или его роли) ,
Если пользователь получает разрешения в соответствии с его департаментом (или другим атрибутом другого документа), вы можете запросить об этом.
Аналогичным образом вы можете запрашивать все документы с уровнем безопасности, равным или меньшим, чем у привилегий пользователя. Если это динамический рабочий процесс, каждый документ обычно должен быть отмечен текущим состоянием и/или следующим ожидаемым шагом; которые пользователи могут выполнить, следующий шаг - это просто еще одна привилегия/роль (лечите то же, что и выше).
Тогда, конечно, вы захотите сделать СОЮЗ ВСЕ между всеми этими и публичными документами ...

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

5

Возможно, вас заинтересует this article by Steffen Bartsch. Он суммирует все плагины авторизации для Ruby on Rails, и я уверен, что это поможет вам найти решение (хотя эта статья посвящена плагинам Rails, концепции легко экспортируются за пределами Rails).

Штеффен также построил свой собственный плагин, который называется «декларативный Authorization», который, кажется, чтобы соответствовать вашим потребностям, ИМХО:

  • с одной стороны, определить роли (такие, как «посетитель», «админы »...). Ваши пользователей связаны с этими ролями (в отношениях «многие ко многим»). Вы сопоставляете эти роли с привилегиями (снова в отношениях «многие ко многим»). Каждая привилегия связана с заданным контекстом. Например, роль «посетителя« может иметь привилегию »читать документы». В этом примере «, читаемый» является привилегией, и применяется к «контексту» документов.
    • Примечание: в плагине Стеффена вы можете определить иерархию ролей. Например, вы могли бы хотеть иметь роль «global_admin» включают «document_admin» роль, а также роль «comment_admin» и т.д.
    • Можно также определяет иерархию привилегий: например, "управлять" привилегия может включать "чтения", "обновление", "добавить" и "удалить" привилегии.
  • с другой стороны, вы код приложения мышления в терминах привилегий и контексты, а не с точки зрения ролей. Например, действие для отображения документа должно только проверять, имеет ли пользователь привилегию «» «в контексте« документов »(нет необходимости проверять, имеет ли пользователь« посетитель »роль или любая другая роль). Это значительно упрощает ваш код, поскольку большая часть логики авторизации извлекается в другом месте (и, возможно, даже определяется кем-то другим).

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

class DocumentController [...] 
    filter_access_to :display, :require => :read 
    def display 
    ... 
    end 
end 

И внутри вид:.

<html> [...] 
    <% permitted_to?(:create, :documents) do %> 
    <%= link_to 'New', new_document_path %> 
    <% end %> 
</html> 

плагин Штеффена также позволяет объектного уровня (т.е. row- уровень) контроля доступа. Например, вы можете захотеть, чтобы определить роль, такие как «document_author» и дать ему «управлять» привилегией «документов», но только если пользователь является автором документа. Декларация этого правила, вероятно, будет выглядеть так:

role :document_author do 
    has_permission.on :documents do 
    to :manage 
    if_attribute :author => is {user} 
    end 
end 

Это все, что есть! Теперь вы можете получить все документы, которые пользователь может обновлять так:

Document.with_permissions_to(:update) 

Поскольку «управления» привилегия включает в себя «обновление» привилегия, это будет возвращать список документов, автором которой является текущим пользователем.

Конечно, не для каждого приложения потребуется этот уровень гибкости ... но ваш может.

Смежные вопросы