Servizio di reporting e ruolo dell'applicazione

Primo poster, a lungo in agguato qui. Qual è il modo migliore per attivare il ruolo dell'applicazione in un report?

Ho provato diverse cose e finora l'unico metodo che funziona è quello di incorporare la chiamata al ruolo dell'applicazione in questo modo: -

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

nel set di dati. Funziona ... ma non per i miei gusti (certamente non nella forma che vorrei inserire nell'ambiente di produzione).

Preferirei se potessi in qualche modo "dirottare" o "iniettare" la riga di attivazione del ruolo dell'applicazione in fase di esecuzione tramite assembly personalizzati o probabilmente una sorta di "hook del server" nel servizio di report (che in entrambi i casi, non ho idea di come )

Molto apprezzato per il tuo tempo + gentile attenzione.

YS.

sql-server ssrs role

— YS.
fonte

puoi iniziare da qui msdn.microsoft.com/en-us/library/aa237582(v=SQL.80).aspx per capire come estendere il Reporting Service (iniettare codice che imposta il ruolo dell'applicazione), ma non vorrei prendere questo commento come risposta, non sono sicuro che questo sia davvero il modo più semplice e non potrebbe essere fatto in configurazione

a seconda del modo in cui le persone accedono a questo rapporto, è possibile incorporare le credenziali utente del rapporto nel set di dati e quindi impostare il lato server sql di accesso in modo che disponga di privilegi limitati.

— DForck42,

Ciao DForck - l'intero sistema era basato su approle e vogliamo mantenerlo così.

Vedo un paio di modi in cui ciò potrebbe essere fatto senza ricorrere a qualcosa di eccessivamente elaborato.

Il primo sarebbe utilizzare l'autenticazione integrata di Windows e assegnare le autorizzazioni ai gruppi che rappresentano gli utenti dell'applicazione.
È possibile creare ruoli che potrebbero essere concessi e quindi utilizzare set roleper assumere il ruolo nel proprio codice nel database. In questo modo non si passa una password e si autentica prima l'applicazione.

Il vantaggio del primo è che è facile da gestire, in un dominio AD, chi ha accesso all'applicazione. La gestione sarebbe relativamente semplice. Gli svantaggi principali sarebbero che si limiterebbe ai casi in cui ha senso l'autenticazione integrata e dovresti supportare l'autenticazione integrata fino in fondo. Inoltre ogni hop finisce per richiedere l'autenticazione a 3 vie (tra server, client e KDC).

Il vantaggio del secondo è che è probabilmente più facile da inserire, e non espone informazioni di sicurezza sulla rete e funziona nei casi in cui l'autenticazione integrata non funzionerà bene.

Proverei entrambi questi approcci prima di provare a estendere il servizio di segnalazione. Come suggerito dal commento, http://msdn.microsoft.com/en-us/library/aa237582%28v=SQL.80%29.aspx può essere utile e può funzionare, ma concettualmente è più complesso del tentativo di gestire i ruoli direttamente.

— Chris Travers
fonte