Служба отчетности и роль приложения

Первый постер, долгое время скрывался здесь. Как лучше всего активировать роль приложения в отчете?

Я пробовал разные вещи, и до сих пор единственный метод, который работает, это встроить вызов в роль приложения следующим образом:

EXEC sp_setapprole 'REPORTZ', 's3cr3t';
select *
from mytable
where ID < 10000

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

Я бы предпочел, чтобы я мог как-то «перехватить» или «внедрить» строку активации роли приложения во время выполнения либо с помощью пользовательских сборок, либо, возможно, с помощью какого-то «перехвата сервера» в Службе отчетов (что в обоих случаях я понятия не имею, как )

Очень ценится за ваше время + доброе внимание.

YS.

sql-server ssrs role

— YS.
источник

отсюда вы можете начать с msdn.microsoft.com/en-us/library/aa237582(v=SQL.80).aspx, чтобы понять, как расширить службу отчетов (внедрить код, который устанавливает роль приложения), но я бы не стал принимать этот комментарий как ответ, не уверен, что это действительно самый простой способ, и это не может быть сделано в конфигурации

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

— DForck42

Привет, DForck - вся система была основана на апплете, и мы хотим, чтобы все было так.

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

Первый - использовать встроенную проверку подлинности Windows и назначать разрешения группам, представляющим пользователей приложения.
Вы можете создавать роли, которые можно предоставлять, а затем использовать их set roleдля принятия роли в вашем коде в БД. Таким образом, вы не вводите пароль и сначала аутентифицируете приложение.

Преимущество первого состоит в том, что в домене AD легко управлять тем, у кого есть доступ к приложению. Управление будет относительно простым. Основными недостатками будет то, что это будет ограничено случаями, когда интегрированная аутентификация имеет смысл, и вам придется поддерживать интегрированную аутентификацию на всем протяжении. Кроме того, для каждого прыжка требуется трехсторонняя аутентификация (между сервером, клиентом и KDC).

Преимущество второго заключается в том, что его, вероятно, легче всего включить, и он не предоставляет никакой информации о безопасности по сети, и он работает в тех случаях, когда встроенная аутентификация не будет работать хорошо.

Я бы попробовал оба этих подхода, прежде чем пытаться расширить службу отчетности. Как следует из комментария, http://msdn.microsoft.com/en-us/library/aa237582%28v=SQL.80%29.aspx может быть полезен и может работать, но это концептуально более сложно, чем пытаться управлять ролями непосредственно.

— Крис Траверс
источник