[OT] Politica di gestione ruoli in Web Application: quali compiti a quale ruolo?

[Shadow976]

Carissimi, non secondo regole pratiche ma secondo le più recenti ed attendibili regole in materia di sicurezza, vorrei un vostro parere (solo da chi conosce bene tali norme).

La mia applicazione gestisce diverse persone; tutte possono accedere al programma, ognuno con operazioni solo a lei riservate. In un software per una società, ecco i ruoli:

1) Amministratore (del programma, intendo! Crea dirigenti e impiegati)
2) Dirigente (amministratore delegato, presidente, direttore)
3) Impiegato (segreteria)
4) Cliente (accede comunque per vedere i suoi ordini)

L'amministratore potrebbe anche essere un dirigente o un impiegato (incaricato magari da qualche dirigente) quindi la stessa persona potrebbe sia abilitare altri utenti che svolgere altre operazioni. Dovrà creare gli utenti dirigenti ed impiegati.

1) Posso concedergli in un unico accesso la possibilità di eseguire operazioni che competono ad entrambi i ruoli o sarebbe il caso di predisporre accessi diversi per l'uno o l'altro ruolo, ovvero farlo loggare da due pagine diverse, a seconda del motivo per il quale si sta loggando, che lo porteranno a due pannelli diversi, uno con le sole funzioni di amministrazione e l'altro con le sole funzioni di normale gestione del programma?
2) Chi dovrebbe creare i clienti, solo dirigenti e impiegati o anche l'amministratore? Per una buona separazione dei ruoli sarebbe forse il caso che l'admin crei solo dirigenti e impiegati?
3) I clienti modificano le loro credenziali di accesso. Ma siete proprio sicuri che dovrebbero poter modificare anche i loro dati anagrafici, se questi verrebbero usati anche in documenti contabili? (Esempio: un importante documento contabile non arriva perché il cliente aggiorna i suoi dati in ritardo e dopo il suo invio. Società: abbiamo inviato il documento all'indirizzo indicato nel programma, lei non lo ha aggiornato tempestivamente! Cliente maldestro e rompiscatole: lo avete inviato al vecchio indirizzo, io ho aggiornato il mio profilo due mesi fa e non una settimana fa come dite).

Grazie in anticipo a tutti!

[oregon]

Questo non e' un problema di programmazione ...

[LeleFT]

Originariamente inviato da oregon
Questo non e' un problema di programmazione ...

Esatto.

Chiedo un parere a chi di dovere per un eventuale spostamento.


Ciao.

[LeleFT]

Non sembra esserci una sezione completamente adatta a questo tipo di richiesta, quindi l'alternativa è di spostarla in OffTopic, con tutti i rischi del caso.
A questo punto la teniamo aperta qui. Se preferisci che la sposti in OT, fammelo sapere.


Ciao.

[Shadow976]

Appunto, anche io prima di postare avevo cercato una sezione adatta ma senza esito. Grazie Lele, va benissimo qui.

[cigiri18]

parlando per buon senso, non conoscendo le varie norme in ambito sicurezza, ti conviene tenere i vari log in separati, anche perché se il tizio avrà bisogno di aggiungere dipendenti o deve aggiungerne 1-2, oppure una valanga, ma in ogni caso non è un lavoro continuo, quindi può benissimo fare un login quando ne ha bisogno, di mondo anche da non far cazzate(è pieno di ebeti a questo mondo).
I clienti in genere li fa chi riceve la richiesta, quindi i dipendenti(o chi che sia), però se preferisci puoi salvare i vari dati e fin quando l'amministratore non accetta non vengono salvati sul database.
Riguardo i clienti è più rognosa, se un cliente cambia indirizzo o sbaglia a inserire qualche campo come fai? Potresti inoltrare le richieste di modifiche dal cliente all'amministratore, ma in questo caso addio privacy, quindi per me ti conviene lasciar modificare al cliente, se questo cambia via gli si rispedirà il documento, oppure puoi tener traccia dei documenti(chi è l'interessato, quando è stato fatto il documento, etc), e quando il cliente modifica i dati si controlla tra i documenti e in caso li si ristampano, tanto in un azienda la carta non manca.

[standard]

Nella mia esperienza ho visto che è preferibile tenere separate le logiche e le policy sulle credenziali di accesso, rispetto ai ruoli che le singole utenze possono avere (sia da un punto di vista del tuo repository utenze, sia da un punto di vista di logiche di business).
Ovvero, login unica con logiche centralizzate per il riconoscimento delle credenziali.
Dopodichè, step successivi per la scelta del profilo con cui l'utenza accede all'applicativo.
L'obiettivo è cercate di individuare univocamente il profilo con cui l'utente (nella singola sessione) accede. Questo consente di customizzare le pagine in funzione delle esigenze o delle funzionalità concesse ai singoli profili.

Inoltre, in una logica di SSO, potrebbe esserci uno step precedente alla scelta del profilo di accesso, che potrebbe essere la scelta dell'applicazione a cui si vuole accedere.

Sul tema dell'aggiornamento dei dati personali, esiste una normativa legata alla gestione della privacy.
In genere l'utente è in grado di poter modificare direttamente o su richiesta tutti i dati (sensibili o meno) che lo riguardano. Quindi, con l'adeguata messaggistica sul come e quando i suoi dati vengano usati, è bene lasciare autonomia all'utente sulla gestione dei propri dati.

ciao

[Shadow976]

Grazie, davvero gentilissimi e risolutivi.