SSRS 2005 Безопасность на основе параметров - PullRequest
0 голосов
/ 08 октября 2009

Я работаю в компании A. Компания A имеет дочернюю компанию B. Обе компании A и B используют одну и ту же базу данных ERP. Я создал отчет SSRS 2005 , который может использоваться обеими компаниями. Он имеет параметр CompanyID, который определяет, отображать ли данные для компании A или компании B.

Для большинства отчетов это будет нормально, но для конфиденциальной информации компании (такой как платежная ведомость) это будет проблемой, так как любой в компании A может изменить параметр CompanyID на ID компании B, и наоборот.

Моей первоначальной идеей для решения этой проблемы было создание связанного отчета t для каждой компании в их соответствующих папках A и B, где защита только для папки A разрешала только пользователям компании A и безопасность для папки B только разрешено пользователям B Затем я бы добавил параметр CompanyID по умолчанию к каждому связанному отчету и скрыл параметры от пользователя. Все идет нормально. Проблема в том, что вы все еще можете изменить значения параметров, используя строку запроса URL. Например, пользователь в компании A может изменить URL-адрес отчета с:

http://server/ReportServer/ReportViewer.aspx?/Payroll/A&rs:Command=Render

до:

http://server/ReportServer/ReportViewer.aspx?/Payroll/A&rs:Command=Render&CompanyID=B

Теперь они полностью обошли скрытый параметр по умолчанию.

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

Обновление: У нас также есть корпоративные сети ASP.NET, которые уже ограничивают доступ на основе компании через домен AD. Я полагаю, что мог бы использовать элемент управления ReportViewer на странице интрасети, чтобы применять соответствующие параметры во время выполнения. Я мог бы включить эту логику в общую страницу отчета, которую можно использовать для любого отчета, верно? (Прошу прощения за мое невежество, я полный SSRS n00b)

Ответы [ 2 ]

1 голос
/ 08 октября 2009

Какой у вас охранник здесь? Мне кажется, надежным и безопасным решением было бы обеспечить доступ к данным на основе учетной записи пользователя. Как собираются данные отчета? Это SELECT прямо в вашем наборе данных? Вы вызываете процедуры? Выбор против просмотра?

РЕДАКТИРОВАТЬ: поскольку вы выбираете для VIEW, объединяющего данные соответствующей компании, если вы предоставляете права на представления пользователям или ролям, которые имеют доступ, вы можете создать сценарий, в котором данные возвращаются пользователю основываясь на своих правах.

0 голосов
/ 08 октября 2009

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

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

...