Come è possibile fornire un UX di autenticazione moduli ASP.NET durante l'utilizzo dei provider di ruolo e autenticazione di Active Directory?

Question

È possibile utilizzare questo fornitore di ruoli AspNetWindowsTokenRoleProvider con l'autenticazione ASP.NET FORMS (tramite questo MembershipProvider System.Web.Security.ActiveDirectoryMembershipProvider)?

Sembra funzionare solo con <authentication mode="Windows">, è possibile utilizzarlo con FORMS?

background - L'obiettivo qui è fornire un modulo U. ASP.NET mentre si utilizza Active Directory come sistema di autenticazione back-end. Se c'è un altro, un modo semplice per farlo usando le tecnologie integrate, è grandioso e mi piacerebbe saperlo anche a questo proposito.

aggiornamento

Devo dire che ho il lavoro di autenticazione, quello che sto lottando con è l'aggiunta di un livello di controllo granulare (quali ruoli).

Attualmente, devo configurare la mia connessione Active Directory per puntare a una specifica unità organizzativa nel mio dominio, che limita l'accesso fisicamente solo agli utenti in quell'unità organizzativa. Ciò che mi piacerebbe è puntare la mia connessione Active Directory al mio tutto il dominio e limitare l'accesso in base all'appartenenza al gruppo (ovvero ai ruoli) funziona se utilizzo l'autenticazione di Windows, ma mi piacerebbe avere il meglio di entrambi i mondi, è possibile senza scrivere il mio RoleProvider?

Answer 1

Come altri hanno già menzionato, non è possibile utilizzare ActiveDirectoryMembershipProvider con AspNetWindowsTokenRoleProvider. Se si desidera utilizzare l'ADMP con autenticazione basata su form, si dispone di un paio di scelte:

1. utilizzare il AuthorizationManager aka AzMan. - AzMan è integrato in Windows 2003+ e può interagire con i gruppi di Active Directory. Inoltre, esiste un AuthorizationStoreRoleProvider integrato in .NET 2.0+ che è possibile utilizzare per interagire con esso. AzMan lavora su Task, Operazioni e Ruoli in cui presumibilmente la tua applicazione sarebbe codificata per agire su Task specifici che potrebbero quindi essere raggruppati in Operazioni e quindi creare Ruoli che hanno l'autorità per eseguire varie Operazioni. Esiste un'applicazione di gestione che viene installata quando si installa AzMan che è possibile utilizzare per gestire attività, operazioni e ruoli. Tuttavia, ci sono alcuni aspetti negativi di AzMan. Innanzitutto, lo AuthorizationStoreRoleProvider non riconosce le attività. Piuttosto, carica l'elenco Roles con un elenco di operazioni. Pertanto, a meno che non si crei una versione personalizzata del provider, le applicazioni dovranno cercare i nomi delle operazioni anziché i nomi delle attività. In secondo luogo, può essere un orso con cui lavorare in quell'interazione, al livello più basso, è ancora tramite COM. A meno che non si desideri che gli amministratori debbano utilizzare lo strumento AzMan, è necessario scrivere le proprie pagine per gestire le operazioni, i ruoli e l'appartenenza ai ruoli.

2. Utilizzare il SqlRoleProvider e mappare i ruoli in nomi utente. Il vantaggio di questa soluzione è che è molto semplice da implementare. Puoi praticamente usarlo subito dal momento che RoleProvider opera su nome utente e non su UserId. Nel tuo codice devi semplicemente verificare IsInRole per determinare se l'utente specificato è stato inserito in un ruolo riconosciuto dal tuo codice. Lo svantaggio significativo è che è orientato solo ai nomi utente e non ai gruppi di annunci e quindi non esiste un modo per un amministratore di utilizzare gli strumenti di Active Directory per gestire gli utenti.Invece, devi scrivere una console di gestione per gestire l'appartenenza al ruolo. Inoltre, la modifica di un nome utente a livello di AD richiede un aggiornamento all'elenco di nomi utente noti dell'applicazione.

3. Scrivere (o individuare) un RoleProvider annuncio personalizzato che rispetta i gruppi di annunci. La scrittura di un fornitore di ruoli personalizzato non è per i deboli di cuore, ma così facendo gli amministratori possono gestire l'appartenenza ai ruoli utilizzando i loro strumenti AD esistenti.

Answer 2

Sì, hai ragione; funzionerà solo con l'autenticazione di Windows Form. Puoi confermare qui: http://msdn.microsoft.com/en-us/library/system.web.security.windowstokenroleprovider.aspx

Solo un suggerimento. Prova AuthorizationStoreRoleProvider con AzMan (Authorization Manager). Ha funzionato per me (secoli fa, quindi non ricordo molto).

Answer 3

implementare il proprio ADAuthorizeAttribute ereditando da AuthorizeAttribute e prioritario AuthorizeCore. È molto più semplice dell'implementazione del proprio provider di ruolo o dell'installazione e configurazione di AzMan.

Vedere il mio esempio qui: ASP .NET MVC Forms authorization with Active Directory groups.