Serviço de Relatório e Função de Aplicativo

Primeiro pôster, há muito tempo aqui. Qual é a melhor maneira de ativar a função de aplicativo em um relatório?

Eu tentei coisas diferentes e até agora o único método que funciona é incorporar a chamada à função de aplicativo da seguinte maneira: -

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

no conjunto de dados. Funciona ... mas não do meu agrado (certamente não da forma que eu gostaria de incluir no ambiente de produção).

Eu preferiria se, de alguma forma, pudesse "sequestrar" ou "injetar" a linha de ativação da função de aplicativo em tempo de execução, por meio de assemblies personalizados ou provavelmente algum tipo de "gancho do servidor" no Reporting Service (que, em ambos os casos, não tenho idéia de como )

Muito apreciado pelo seu tempo + atenção.

YS.

sql-server ssrs role

— YS.
fonte

você pode começar aqui msdn.microsoft.com/en-us/library/aa237582(v=SQL.80).aspx para entender como estender o Serviço de Relatório (injetar código que define a função do aplicativo), mas eu não aceitaria esse comentário como uma resposta, não tenho certeza que isso é muito mais maneira mais fácil e isso não poderia ser feito na configuração

dependendo de como as pessoas estão acessando este relatório, você pode incorporar credenciais de Usuário de Relatório no conjunto de dados e, em seguida, configurar o lado do servidor sql de logon para que ele tenha privilégios limitados.

— precisa saber é o seguinte

Oi DForck - todo o sistema foi baseado em aprovações e queremos mantê-lo assim.

Vejo algumas maneiras de fazer isso sem recorrer a algo excessivamente sofisticado.

O primeiro seria usar a autenticação integrada do Windows e atribuir permissões aos grupos que representam os usuários do aplicativo.
Você pode criar funções que podem ser concedidas e depois usar set rolepara assumir a função no seu código no banco de dados. Dessa forma, você não passa uma senha e está autenticando o aplicativo primeiro.

A vantagem do primeiro é que é fácil gerenciar, em um domínio do AD, quem tem acesso ao aplicativo. A gerência seria relativamente simples. As principais desvantagens seriam que isso seria limitado aos casos em que a autenticação integrada faz sentido, e você teria que oferecer suporte à autenticação integrada o tempo todo. Além disso, todo salto acaba exigindo autenticação de três vias (entre servidor, cliente e KDC).

A vantagem do segundo é que provavelmente é mais fácil calçar, e não expõe informações de segurança na rede, e funciona nos casos em que a autenticação integrada não está funcionando bem.

Eu tentaria essas duas abordagens antes de tentar estender o serviço de relatório. Como o comentário sugeriu, http://msdn.microsoft.com/en-us/library/aa237582%28v=SQL.80%29.aspx pode ser útil e pode funcionar, mas é conceitualmente mais complexo do que tentar gerenciar funções diretamente.

— Chris Travers
fonte