Usługa raportowania i rola aplikacji

Pierwszy plakat, dawno tu czai się. Jaki jest najlepszy sposób aktywacji roli aplikacji w raporcie?

Próbowałem różnych rzeczy i jak dotąd jedyną metodą, która działa, jest osadzenie wywołania roli aplikacji w następujący sposób: -

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

w zestawie danych. Działa ... ale nie w moim guście (na pewno nie w kształcie, który chciałbym wdrożyć do środowiska produkcyjnego).

Wolałbym, gdybym mógł jakoś „przejąć” lub „wstrzyknąć” linię aktywacyjną roli aplikacji w czasie wykonywania albo za pomocą niestandardowych zestawów lub prawdopodobnie pewnego rodzaju „przechwycenia serwera” w usłudze Reporting Service (co w obu przypadkach nie mam pojęcia, jak to zrobić )

Bardzo ceniony za poświęcony czas i życzliwość.

YS.

sql-server ssrs role

— YS.
źródło

możesz zacząć od tutaj msdn.microsoft.com/en-us/library/aa237582(v=SQL.80).aspx, aby zrozumieć, jak rozszerzyć usługę raportowania (wstrzyknąć kod określający rolę aplikacji), ale nie chciałbym przyjąć tego komentarza w odpowiedzi nie jestem pewien, czy jest to naprawdę najłatwiejszy sposób i nie można tego zrobić w konfiguracji

w zależności od tego, jak ludzie uzyskują dostęp do tego raportu, możesz osadzić poświadczenia użytkownika raportu w zestawie danych, a następnie skonfigurować stronę logowania do serwera sql, aby miał ograniczone uprawnienia.

— DForck42,

Cześć DForck - cały system był oparty na approle i chcemy to utrzymać.

Widzę kilka sposobów, w jaki można to zrobić bez uciekania się do czegoś zbyt wymyślnego.

Pierwszym byłoby użycie zintegrowanego uwierzytelniania systemu Windows i przypisanie uprawnień do grup reprezentujących użytkowników aplikacji.
Można utworzyć role, które można przyznać, a następnie użyć, set roleaby przejąć rolę w kodzie w bazie danych. W ten sposób nie podajesz hasła i najpierw uwierzytelniasz aplikację.

Zaletą pierwszego jest to, że w domenie AD łatwo jest zarządzać, kto ma dostęp do aplikacji. Zarządzanie byłoby stosunkowo proste. Główną wadą byłoby to, że byłoby ograniczone do przypadków, w których zintegrowane uwierzytelnianie ma sens, i trzeba było wspierać zintegrowane uwierzytelnianie przez cały czas. Dodatkowo każdy przeskok wymaga uwierzytelnienia trójstronnego (między serwerem, klientem i KDC).

Zaletą tego drugiego jest to, że prawdopodobnie najłatwiej jest go wtargnąć, i nie ujawnia żadnych informacji o bezpieczeństwie w sieci, i działa w przypadkach, gdy zintegrowane uwierzytelnianie nie działa dobrze.

Wypróbuję oba te podejścia, zanim spróbuję rozszerzyć usługę raportowania. Zgodnie z sugestią komentarza http://msdn.microsoft.com/en-us/library/aa237582%28v=SQL.80%29.aspx może być pomocny i może działać, ale jest koncepcyjnie bardziej złożony niż próba zarządzania rolami bezpośrednio.

— Chris Travers
źródło