Discussione 'Autenticazione Middle Tier e SQL Server'

Autenticazione Middle Tier e SQL Server

Ho letto il blog di Raffaele (che le sa quasi tutte, ma le poche che non sa muore dalla voglia di impararle ...) e sono d'accordo con lui che l'autenticazione a livello di database è poco utile a quello che di solito ci si propone di fare con un software: filtrare i record secondo un criterio di accesso magari complesso. L'unica utilità che vedo nella autenticazione diretta è l'accesso a query di selezione dei dati (readonly) con le vere tabelle mascherate.

Re: Autenticazione Middle Tier e SQL Server

dovo trovo documentazione sull'argomento (possibilmente in ITALIANO)
italiano....che bestemmia!

Re: Autenticazione Middle Tier e SQL Server

wow ti saresti divertito ieri sera allora... eravamo io, alessandro e raffaele... una discussione sull`argomento infinita... ;p

cmq se proprio vuoi saperlo concordo anche nella sicurezza programmatica... associando un utente ad un applicativo o gruppo di applicativi e lasciare la capilarità al programma... ovviamente non è una scelta assoluta, diciamo che nella maggior parte delle realtà che conosco mi torna molto utile la scelta :D

a dopo,
devo correre alla sessione che mi sta iniziando...
M.rkino :D

Re: Autenticazione Middle Tier e SQL Server

Però! Sono stato ad Urbino un paio di giorni e vedo che la situazione non è migliorata... sono disposto a battermi contro i multini a vento, ma non lascierò che orde di barbari scrivano impunemnete che la sicurezza di SQL server è "poco utile" o che serve solo per proteggere carnevalesche "query di mascheramento". ;P
A parte il tono che è volutemente scherzoso, direi che è bene richiamare alcuni elementi base:
La sicurezza "comincia" del midTier dove gli utenti vengono identificati e viene concesso loro l'accesso o meno l'uso a metodi di classi che "in qualche modo" operano sui dati.
Il midTier agisce su SQL sempre con lo stesso contesto di sicurezza, cioè setsso utente, altrimenti ci giochiamo il connection pool.
SQL server deve concedere all'utente che impersona il midTier le persmission di cui ha bisogno e nulla più.
Nessun'altro al di fuori del midTier ha permessi sui dati.

ciao,
AS

Re: Autenticazione Middle Tier e SQL Server

In Italiano meno che mai. Queste sono scelte progettuali che ho approfondito all'inizio dell'era com/dcom su diversi libri, articoli (msdn magazine) etc.

Raffaele

Re: Autenticazione Middle Tier e SQL Server

Vedi che vieni nel mio carruggio ...
L'uso di impersonation nel middle tier va nella direzione opposta di quello che dici tu e che dico anch'io.

Non escludo, come sostiene anche Alessandro Ghizzardi, l'uso di stored procedure per evitare che il developer acceda direttamente alle tabelle. Questo è tipicamente necessario solo in progetti molto grossi. In progetti di dimensioni più ridotte l'uso di sp spezza la logica di business sia nel data server che nel middle tier e gestire il riallineamento diventa un caos. Nelle grandi realtà bisogna poi anche vedere se il dba è veramente abbastanza abile da stare dietro alle richieste del developer.

Infine ci sono almeno due casi in cui la sicurezza sulle sp sono un vero incubo:
1. Se il middle tier non deve accedere solo a risorse db ma anche a file per uno stesso metodo. Spezzare la gestione di security su ntfs e db è folle. È molto più semplice affrontarlo nel middle tier.
2. Se devi usare la sicurezza imperativa per selezionare i risultati da ritornare all'utente (o da mandare al db) l'uso di stored procedure è possibile ma richiede uno skill troppo elevato, tanto da renderlo inutilizzabile. Inoltre introdurre la sicurezza imperativa nelle stored procedure implica spostare una parte fondamentale della logica di business all'interno del data server, cosa che è deplorevole.

Raffaele

Re: Autenticazione Middle Tier e SQL Server

Sul forum ADO scrivevi:
> SQL Server non implementa la security rowLevel direttamente ma possiamo
> costruire View e Trigger che ci permettono di fatto di implementarla, con un
> certo successo.

Per quanto riguarda l'uso dei trigger, mi sa che rischiamo di aprire un'altra discussione infinita. Sono della schiera di quelli che non li usano mai. O meglio che li usano solo quando il danno da parte dell'architect è già fatto. Non è un segreto che i trigger siano altamente penalizzanti.

Molte sessioni di tipo db al teched fornivano consigli utili ma tipicamente orientati al dba. Il dba non ha i mezzi tantomeno le capacità per disegnare un'architettura di sicurezza diversa da quella 'classica'. Questo non significa che sia il mezzo giusto. Infatti nelle sessioni db orientate agli sviluppatori, improvvisamente il tono cambia, spostando tutto sul middle tier.
Le motivazioni di questo shift sono tante e le prime che mi sono venute in mente le ho già scritte nell'altro post 'sibling' di questo.

Raffaele

Re: Autenticazione Middle Tier e SQL Server

Ciao Raffaele,
Rispondo a questo post per rispondre ad entrambi i post.
Intanto non ho mai sostenuto che la sicurezza va tolta dal midTier e se l'ho fatto mi smentisco categoricamente. La sicurezza appunto "comincia" da li, ma non si ferma.
La scicurezza o meglio protezione imperativa riguarda la protezione programmatica dell'assembly, non capisco cosa intendi quando dici
>Se devi usare la sicurezza imperativa per selezionare i risultati da ritornare
>all'utente (o da mandare al db) l'uso di stored procedure è possibile ma richiede
>uno skill troppo elevato.
Intendi forse sicurezza implementativa? Certo che va gestita nel midTier! Su queso sono d'accordissimo, il problema che a volte il midTier non esiste e la sicurezza viene spostata sul client... e lì invece non sono per nulla d'accordo.

I trigger sono penalizzanti se sono scritti male, in altri casi come il riepilogo di dati di dettaglio in testata (es totFattura) potrebbero aumentare le performance in caso di frequente estrazione dei dati. OK lo si puo' fare nel midTier ma converrai che è una cosa che va fatta "molto" attaccata ai dati.

Infine tu scrivi
>In progetti di dimensioni più ridotte l'uso di sp spezza la logica di business sia nel >data server che nel middle tier e gestire il riallineamento diventa un caos.
Dipende cosa ci metti nelle SP. Le SP sono oggetti che sono preposti alla manipolazione o estrazione dei dati. Non dovrebbero contenere la vera logica di business: inserire una riga di fattura non è logica di business, è inserire una riga di fattura.
Scusa ma non capisco cosa intendi per riallineamento.

Sull'abilità o meno dei dba, sarà che sono fortunato, (ok Andrea, adesso non gongolare...), ma il livello medio di skill dei dba è generalmente alto, in grado di staredietro alle richieste dei dev.

In questo post ho volutamente evitato l'argomento "SQL nel codice" sul quale direi è il succo della "polemica". Se vuoi ne possiamo discutere, ma io sposterei la questione su questi punti:
1) Quando le store procedures sono Business Object e quando sono Interfaccia per i Dati.
2) Quanto è veramente portabile un progetto .Net scritto con SQL nel codice.
3) Performance
4) Varie ed eventuali

per ora ti saluto e ti auguro buon weekend.
AS

Re: Autenticazione Middle Tier e SQL Server

> Intanto non ho mai sostenuto che la sicurezza va tolta dal midTier e se l'ho fatto mi
> smentisco categoricamente. La sicurezza appunto "comincia" da li, ma non si ferma.
Finalmente cominciamo ad essere daccordo su qualcosa ;-)

> La scicurezza o meglio protezione imperativa riguarda la protezione programmatica
> dell'assembly, non capisco cosa intendi quando dici [...]
Dico solo che per gestire determinate problematiche di security (vedi security sul record) preferisco usare la sicurezza imperativa nel middle tier e non la sicurezza sulle stored procedure. La sicurezza in SQL può risultare in grossolani errori perchè il db espone risorse 'rozze' mentre il middle tier espone funzionalità logiche ad alto livello che sono più faclimente identificabili come punti di accesso o di sbarramento.

> I trigger sono penalizzanti se sono scritti male, in altri casi come il riepilogo di dati di
> dettaglio in testata (es totFattura) potrebbero aumentare le performance in caso di frequente
> estrazione dei dati. OK lo si puo' fare nel midTier ma converrai che è una cosa che va fatta
> "molto" attaccata ai dati.
Non concordo. I trigger sono sempre penalizzanti e richiedono un lavoro consistente del db. Nel middle tier si può fare un lavoro migliore che richiede ovviamente una base dati all'altezza. Il middle tier può anche essere separato su diversi server, il db no. Ecco un altro buon motivo per lasciare al db meno lavoro possibile.

> Infine tu scrivi
> >In progetti di dimensioni più ridotte l'uso di sp spezza la logica di business sia nel >data
> server che nel middle tier e gestire il riallineamento diventa un caos.
> Dipende cosa ci metti nelle SP. Le SP sono oggetti che sono preposti alla manipolazione o
> estrazione dei dati. Non dovrebbero contenere la vera logica di business: inserire una riga di
> fattura non è logica di business, è inserire una riga di fattura.
> Scusa ma non capisco cosa intendi per riallineamento.
Molte query possono contenere un po' della logica di business. Io sono tra quelli a cui piace tenere tutto assieme nel middle tier, ma non sono talebano in questo senso. È prima di tutto una questione di gusto personale.
Per riallineamento intendo le tante persone che aggiornano il middle tier senza aggiornare le corrispondenti sp. Credimi che sono in tanti a fare l'erroraccio.
Quando devo usare sp, preferisco implementare delle procedure con SqlDmo che si occupano di installare le nuove sp nel db. Questo mi consente di sopravvivere al riallineamento e conservare nel middle tier la query, almeno per la leggibilità del sorgente.

> Sull'abilità o meno dei dba, sarà che sono fortunato, (ok Andrea, adesso non gongolare...), ma
> il livello medio di skill dei dba è generalmente alto, in grado di staredietro alle richieste
> dei dev.
Al Teched si è detto in diverse sessioni che il livello medio non è poi così alto.... ritieniti molto fortunato.


> 1) Quando le store procedures sono Business Object e quando sono Interfaccia per i Dati.
Su questo eviterei la discussione perchè ci potremmo scrivere un enciclopedia, ... nel frattempo annoiremmo troppo quelli che ci leggono.

> 2) Quanto è veramente portabile un progetto .Net scritto con SQL nel codice.
Provato sul campo ti dico si, è fattibile e più pratico della soluzione sp. Ma potremmo anche dire che è una questione di gusti.

> 3) Performance
Molto variabile da progetto a progetto.

Credo che non ne usciremo più da questo thread ;-)
Raffaele

Re: Autenticazione Middle Tier e SQL Server

Eilà pensavo ci avessi mollato. Ed invece no! Eccoci qua in piena notte come goni buon programmatore che si rispetti ;)
Concordo con te col fatto che non si finirà mai di ciarlare di ste panzane, anche se ho letto di gente che sta a leggere ciò che scriviamo.
Non ti nascondo che sono un buon fan di SQL Server (nonchè socio UGISS) utilizzandolo dalla versione 4.21a. Alla fine credo però che scrivendo SQL portabile si deve rispettare una sintassi (ANSI-SQL) che poco sfrutta il databse.
Il DB non è un rozzo figuro appana un po' più furbo di un fileshare, ma uno molto strumento efficente per manipolare i dati, ancora di più se si usano le sue funzionalità specifiche. Le "Funzioni" di SQL server sono in grado di aumentare molto le prestazioni, l'uso di tabelle temporanee anche, in alcuni casi la sintassi TSQL è più efficente di quella ANSI...se no mi spieghi che ci fanno tutti a penzolare davanti alla beta di yukon se poi dobbiamo scivere ANSI SQL? E questo vale per altri DB Server.
Chi l'ha detto che i trigger sono sempre poco performanti? Non dobbiamo guardare la singola transazione, ma l'economia dell'applicazione complessiva.
E poi lo sanno tutti che si guadagna 5 centesimi a transazione no?.. Oggi ne ho fattte 2.117.542... offro da bere?
ciao
AS

Re: Autenticazione Middle Tier e SQL Server

Ormai che abbiamo opinioni diverso l'hanno capito tutti e poi se continuiamo così, Alessandro mi ha promesso che ci stronca il thread perchè siamo OT ;-)

Per la presentazione di Yukon mi piacerebbe essere in una platea di dba, ben protetto da una gabbia di ferro, mentre presentano le nuove stored procedure in c# e vb.net... che risate... qualche decina di ambulanze fuori per gli svenimenti sarebbero proprio d'obbligo.

Raffaele

[OT ma non troppo] Re: Autenticazione Middle Tier e SQL Server

OK
passo e chiudo.
Io sarò in WPC... se ci becchiamo ne parelermo....
Ciao
AS

Re: Autenticazione Middle Tier e SQL Server

> e poi se continuiamo così, Alessandro mi ha promesso
> che ci stronca il thread perchè siamo OT ;-)

Hem... non dire così che poi mi associano ad Himmler :)
Cmq ho detto solo che l'avrei spostato, non trinciato :)

Per le stored procedure in c# e vb.net ne riparliamo di persona, altrimenti qui facciamo partire un flame :p

bye
Alessandro

Re: Autenticazione Middle Tier e SQL Server

> Per le stored procedure in c# e vb.net ne riparliamo di persona, altrimenti qui facciamo
> partire un flame :p

eheheh