Как получить доступ к ролям/разрешениям пользователей с помощью SSRS и пользовательского расширения безопасности BIDS?


Я написал и развернул пользовательское расширение безопасности для SSRS 2008r2, и оно прекрасно работает, кроме как при попытке развернуть отчеты из BIDS 2008/Visual Studio.

Архитектура расширения безопасности обрабатывает входы через несколько инстанций, и я управляю этим, создавая пользовательский сеанс в LogonUser (), сохраняя его в базе данных, а затем загружая сеанс в клиентский прокси-класс для веб-службы RS, используя UID, передаваемый cookie из службы, затем переписать билет проверки подлинности, чтобы содержать uid сеанса плюс роли пользователя для текущего пользователя. Затем эти значения можно использовать в пользовательском расширении авторизации для управления разрешениями пользователей на действия и объекты служб SSRS.

Проблема, с которой я столкнулся, заключается в том, что он не работает при развертывании отчетов из заявок. Он обращается непосредственно к службе, и поэтому прокси-класс службы не требуется. Я попытался обработать событие post-authentication в контексте HTTP но, увы, файл cookie сеанса не сохраняется службой RS, поэтому я не могу получить доступ к значениям сеанса.

Так что же я упускаю? Существует ли другой метод управления ролями и разрешениями пользователей, который не требует жесткого кодирования имен пользователей в любом месте? Как я уже сказал, логины могут быть сделаны с использованием нескольких авторитетов, поэтому управление разрешениями с помощью только имени пользователя невозможно (и мысль об этом заставляет меня съежиться).

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

Любая помощь будет с благодарностью принята!

2 5

2 ответа:

Вы используете интерфейс IAuthenticationExtension? Следующая ссылка дает хороший пример управления доступом, если это то, что вам нужно. http://blogs.msdn.com/b/jameswu/archive/2008/07/15/anonymous-access-in-sql-rs-2008.aspx

Я бы предположил, что имя пользователя nt можно отслеживать здесь,а затем искать в группах active directory и т. д. Главная головная боль, которую я вижу здесь, - это включение правильной политики доверия в конфигурации политики ssrs.

Ну, я отказался от поиска элегантного решения, поэтому я пошел по пути наименьшего сопротивления и следовал тому, что, как я понял, является руководством SSRS по созданию "главной" учетной записи,которая, как я укажу, будет использоваться для развертывания отчетов и подписок. Эта учетная запись должна быть жестко закодирована или извлечена из файла настроек, я не уверен, что есть какой-либо другой способ. Овации.

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