Devo gestire l'autenticazione da solo se l'alternativa è molto bassa nell'usabilità e sto già gestendo i ruoli?

2

Essendo un piccolo dipartimento di sviluppo interno, abbiamo solo esperienza nello sviluppo di applicazioni per la nostra intranet. Utilizziamo la Active Directory esistente per la gestione degli account utente. Contiene i conti di tutti i dipendenti della società e molti (ma non tutti) i partner commerciali con i quali collaboriamo.

Ora, il top management desidera un'applicazione per lo scambio di tecnologia e io sono lo sviluppatore principale del nuovo progetto. Fondamentalmente, è un database che contiene il nostro know-how, con un front-end web. I nostri dipendenti, i nostri partner commerciali che collaborano e le persone che desiderano diventare nostri partner commerciali che collaborano dovrebbero avere accesso ad esso e vedere quali tecnologie abbiamo, in modo che possano commerciare con il dipartimento che le possiede. Le tecnologie non sono brevettate, ma molto preziose per i concorrenti, quindi i capi dipartimento sono su qualcuno a cui non è autorizzato l'accesso alla descrizione della loro tecnologia. Questo vincolo richiede un modello ibrido RBAC multi-dimensionale estremamente complicato.

Poiché Active Directory non contiene nemmeno tutte le informazioni necessarie per dedurre i ruoli che utilizzo, dovrò gestire i ruoli oltre alle eccezioni di accesso concesse per tecnologia per utente all'interno il mio sistema . Il piano corrente prevede l'uso di Active Directory per l'autenticazione. Ciò comporterà un processo di registrazione di più ore per i nostri partner commerciali in cui il proprietario del database deve creare manualmente gli accessi nella nostra Active Directory e inviare loro le credenziali.

Se gestisco gli accessi nel mio sistema , potremmo migliorare l'usabilità molto, ad esempio consentendo alle persone di avere un account attivo (ma non privilegiato) al più presto mentre si registrano. Mi sembra che, dopo avere comunque una tabella utenti nel DB (e gestire i brutti dettagli come la memorizzazione degli ID utente storici in modo che gli ID utente riciclati all'interno di Active Directory non ottengano inaspettatamente i diritti per visualizzare le tecnologie di qualcuno), < la strong> complessità aggiuntiva dall'implementazione della funzionalità di autenticazione sarà minima. Pertanto, sto iniziando a orientarmi verso la gestione dei miei account utente e dimenticando completamente l'AD.

D'altra parte, vedo alcuni motivi per rimanere con Active Directory . Innanzitutto, la saggezza convenzionale che ho sentito dai programmatori esperti è non fare la tua gestione degli utenti se puoi evitarlo. In secondo luogo, abbiamo codice che posso riutilizzare per la connessione alla directory attiva, mentre dovrei codificare l'autenticazione se eseguita in-system (e il mio capo ha affermato chiaramente che il progetto è stato consegnato in tempo priorità molto più alta rispetto alla fornitura di un sistema con un'elevata usabilità). In terzo luogo, non sono uno sviluppatore molto esperto (questa è la mia prima posizione di leadership) e non ho mai fatto prima la gestione degli utenti, quindi temo di trascurare alcuni motivi importanti per utilizzare l'annuncio o Sto sottovalutando la quantità di lavoro rimasto per fare la mia autenticazione.

Mi piacerebbe sapere se ci sono più motivi per andare con il meccanismo di autenticazione AD . Specificamente, se voglio fare la mia autenticazione, cosa dovrei implementare oltre a una connessione sicura per la schermata di login (che mi servirebbe comunque anche se sto solo trasportando la pw in AD), ricerca di un hash della password e un meccanismo per il recupero della password (che probabilmente include la verifica dell'identità manuale, quindi non c'è bisogno di soluzioni complesse simili a mTAN)? E, se hai esperienza con questi sistemi critici per la sicurezza, quale useresti e perché?

Aggiornamento Quando ho scritto la domanda, il mio capo mi ha detto che otterrò l'accesso in sola lettura ad Active Directory e che tutti gli utenti del mio sistema avrebbero seguito le procedure interne per gestione degli account (come mostrare un ID immagine al nostro segretario per reimpostare una password dimenticata). Non avrei avuto la possibilità di creare i miei gruppi personali. Ma dopo aver spiegato la situazione al mio capo e all'amministratore di AD, ho ottenuto il permesso di salvare gli account dei miei utenti in un'unità organizzativa separata e gestirli come ritengo opportuno. Così ora posso usare Active Directory e offrire comunque un'esperienza utente accettabile. Tuttavia, se avete una risposta che affronta la mia domanda sotto i vecchi vincoli, scrivetela, sarei interessato a saperne di più anche se il mio interesse è solo accademico ora.

    
posta rumtscho 14.12.2012 - 13:29
fonte

1 risposta

3

Ti consigliamo di utilizzare un approccio basato su AD e di migliorare l'ambiente AD esistente per fornire i gruppi / i ruoli necessari per supportare l'applicazione.

Un elemento che non hai discusso nella tua domanda è Controllo . Come verificherete di avere tutti i ruoli e le regole corretti e bla bla bla che il proprietario del processo paranoico richiede? (n.b paranoia non è sempre una brutta cosa)

AD ha già una vasta serie di strumenti già costruiti attorno al fine di semplificare il processo di registrazione, gestire il controllo e la disattivazione rapida dell'account. Il tuo team di sviluppo può fornire tutte queste funzionalità? C'è un valore reale nella tua squadra che costruisce quella funzionalità? Ecco perché AD è l'opzione più attraente dei due.

La gestione degli utenti è un grande reame e non è essenziale per la tua attività. Questi sono ottimi motivi per utilizzare uno strumento di terze parti (AD in questo caso) per semplificare le attività di sviluppo. I problemi di pianificazione e consegna aggiungono semplicemente più peso a questo argomento.

    
risposta data 14.12.2012 - 15:43
fonte

Leggi altre domande sui tag