Servicio de informes y rol de aplicación

Primer cartel, mucho tiempo al acecho aquí. ¿Cuál es la mejor manera de activar el rol de aplicación en un informe?

He intentado cosas diferentes y hasta ahora el único método que funciona es incrustar la llamada al rol de aplicación de la siguiente manera:

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

en el conjunto de datos. Funciona ... pero no es de mi agrado (ciertamente no en la forma en que me gustaría pasar al entorno de producción).

Preferiría si de alguna manera pudiera 'secuestrar' o 'inyectar' la línea de activación del rol de la aplicación en tiempo de ejecución, ya sea a través de ensamblajes personalizados o probablemente algún tipo de 'enlace de servidor' en el Servicio de informes (que en ambos casos, no tengo idea de cómo )

Muy apreciado por su tiempo + atención amable.

YS.

sql-server ssrs role

— YS.
fuente

puede comenzar desde aquí msdn.microsoft.com/en-us/library/aa237582(v=SQL.80).aspx para comprender cómo extender Reporting Service (inyectar código que establece el rol de la aplicación), pero no tomaría este comentario como respuesta, no estoy seguro de que esta sea la forma más fácil y no se pudo hacer en la configuración

dependiendo de cómo las personas estén accediendo a este informe, podría incrustar las credenciales del Usuario del informe en el conjunto de datos y luego configurar el lado del servidor sql de inicio de sesión para que tenga privilegios limitados.

— DForck42

Hola DForck: todo el sistema se había basado en Aprole y queremos mantenerlo así.

Veo un par de maneras en que esto podría hacerse sin recurrir a nada demasiado elegante.

El primero sería utilizar la autenticación integrada de Windows y asignar permisos a los grupos que representan a los usuarios de la aplicación.
Puede crear roles que podrían otorgarse y luego usar set rolepara asumir el rol en su código en la base de datos. De esta manera, no está ingresando una contraseña y está autenticando la aplicación primero.

La ventaja de la primera es que es fácil de administrar, en un dominio AD, quién tiene acceso a la aplicación. La gestión sería relativamente simple. Las principales desventajas serían que se limitaría a los casos en que la autenticación integrada tiene sentido, y tendría que admitir la autenticación integrada en todo momento. Además, cada salto termina requiriendo autenticación de 3 vías (entre servidor, cliente y KDC).

La ventaja de la segunda es que probablemente sea más fácil calzar, y no expone información de seguridad a través de la red, y funciona en casos donde la autenticación integrada no funcionará bien.

Intentaría ambos enfoques antes de intentar ampliar el servicio de informes. Como sugiere el comentario, http://msdn.microsoft.com/en-us/library/aa237582%28v=SQL.80%29.aspx puede ser útil y puede funcionar, pero es conceptualmente más complejo que tratar de administrar roles directamente.

— Chris Travers
fuente