Как разграничивать права на уровне бизнес-логики хранимых процедур

Разграничение доступа осуществляется на основе ролей. Каждый компонент через настройки задает доступ по ролям (поле Роли). Но иногда требуется более точное, детальное разграничение доступа (например пользователь роли manager может иметь доступ только к определенным проектам, а не всем подряд).

Основная идея - создавать типовые функции проверки доступа к сущностям, а не размазывать бизнес-логику проверки доступа по всей системе.

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

Пример функции для сущности Проект. Мы проверяем по определенному праву доступа к целому проекту, а не к каждой отдельной части проекта - к тикету, к логам проекта и т.д.

ALTER    FUNCTION [dbo].[sec_project_hasRight]  (
            @itemID int,
            @username nvarchar(128),
            @right nvarchar(128)
)
RETURNS bit
AS
BEGIN
            declare @res bit = 0
            -- для каждого права делаем свою бизнес логику проверки на основе itemID и username
            if(@right in ('readBug', 'editBug') ) begin  
                        if( ...  CONDITION - HAS USER THIS RIGHT? ... ) begin
                                   set @res = 1
                        end
            end

            if(@right in ('manageBugChecklist') ) begin  
                        if( ...  CONDITION - HAS USER THIS RIGHT? ... ) begin
                                   set @res = 1
                        end
            end
            --- ...
   RETURN  @res
END

 В компонентах мы вначале проверяем доступ. Если нет определенного права, то выдаем сообщение об ограничении доступа (или редирект) 

if([dbo].[sec_project__hasRight](@itemID, @username, 'editDocs=')=0 ) begin
    	select 0 Result, 'No access' Msg
        return
end

Примечание:

• Эти проверки не отменяют использование свойства компонентов Роли (roles). Данное поле надежно отсекает доступ по роли (даже если ваша проверка будет забыта внедрена, roles уже базово ограничит доступ к таблице или форме).
• Не вызывайте в where функцию проверки доступа (это будет медленно работать). Проверяйте доступ до выполнения операции. Всегда можно найти некий обобщенный объект, к которому можно проверить доступ перед выполнением операции. Другими словами, не нужно проверять доступ к каждой задаче проекта, требуется проверить доступ пользователя к данному проекту.