Ciao a tutti,
la domanda sorge spontanea: l'autenticazione è da considerarsi un servizio di business?
:-)
Ciao e grazie,
Giulio
--
Domanda difficile, io lo considero spesso infrastrutturale, però il concetto di utente e della gestione dei permessi è un servizio sicuramente, ma la mera tecnologia utilizzata per l'autenticazione è infrastrutturale IMHO
alk.
--Blog Eng: http://www.codewrecks.com/blogBlog Ita: http://blogs.ugidotnet.org/rgmTwitter: http://twitter.com/alkampfer
Come dice G.M. la risposta non è semplice...per esperienza personale direi che è qualcosa di "ortogonale" ai servizi di business.
Ciao
melkio
Blog: http://blog.codiceplastico.com/melkioTwitter: http://twitter.com/amelchiori
la domanda è: l'autenticazione "partecipa" al business o è "soltanto" una "commodity" che, data una coppia username/password, ti dice "SI" o "NO"?
.A
Ciao Andrea,
l'autenticazione ti dice SI/NO e dal profilo dell'utente il servicelayer/applicationlayer decide se una operazine si può fare o no. :-)
Ciao,
e allora direi che ti sei risposto da solo :-)
...e la risposta è? :-)
Scherzi a parte, sarà il caldo, sarà che sono iper-concentrato su altro, ma onestamente la risposta mi sfugge. :-/
Spero di interpretare bene la sinteticità di Andrea: se il processo di autenticazione è solo SI/NO (come, mi sembra di capire, nel tuo caso) può essere considerato ortogonale al servizio stesso e quindi implementato tramite AOP o altro, e quindi un po' nascosto (e non sempre mi piace)
Qualora il concetto del chi-fa-cosa è legato al business, preferirei che fosse più esplicito e concorresse alla definizione del processo/use-case
Fai una cosa: chiedilo al tuo Ubiquitous Language :-)
Io solitamente ho due differenti situazione per l'autenticazione e mentalmente separo in due situazione
1) le regole di business sono complesse e per capire se un utente può fare una certa operazione debbo interrogare il dominio o il db se non sono DDD, o in generale fare una logica complessa (Es. l'operazione di DeleteRilevazione un admin la può fare sempre, uno user normale solamente se è l'unico utente associato alla rilevazione.
2) Non ho complesse regole di business, ma per ogni operazione del servizio (chiamata dalla UI) so a compile time che ruolo può chiamarla, uso la security .NET decorando i metodi con i PrincipalPermission e sono a posto.
In entrambi i casi, viene tirata una securityException, che viene recuperata da un intercettore messo in AOP che logga tutto e lato client fa apparire ad esempio una grande MessageBox con su scritto "UNPERMITTED", e se ho più di X unpermitted automaticamente sloggo e faccio mostrare nuovamente la form di login.
Io ho implementato un framework di security simile a Rhino.Security, quindi di infrastruttura. Poi abbiamo avuto la necessita' di evolvere la logica di business, rendendo partecipe il framework di security e sempre seguendo l' esempio di rhino.security abbiamo esposto delle interfacce sul dominio dal framework di security.
Adesso e' sempre un servizio di infrastruttura ma puo' essere usato anche come integration nella logica di business.
La nostra necessita' era quella di poter fare una cosa del tipo:
var query = repository.GetOrdersQuery() // ritorna una IQueryable<Order>()
var securequery = securityService.SecureQuery(query, "Posso vedere gli ordini?")
E lanciare l' SQL statement dall' O/RM solamente alla fine.