Come utilizzare OAuth con Active Directory

6

Sto creando un servizio WCF REST e voglio utilizzare OAuth per autenticare la richiesta di ciascun utente. Gli account utente sono archiviati in Active Directory, quindi ho accesso al loro nome di accesso AD sull'applicazione client e posso trasmettere tali informazioni insieme all'intestazione della richiesta.

Ho usato Oauth con l'API REST di FatSecret prima, quindi ho familiarità con come funziona l'autenticazione.

Fondamentalmente non sono sicuro di come gestire l'assegnazione e la memorizzazione delle chiavi segrete per gli utenti e come fare per legare la chiave segreta di un utente al loro nome di accesso AD.

Avrei solo un altro database che conteneva una tabella di mappatura dei nomi di accesso AD degli utenti alle chiavi segrete e quindi basta fare una ricerca della chiave segreta su quella tabella quando arriva la richiesta?

Come faccio a garantire che la richiesta in arrivo provenga effettivamente dall'utente il cui nome di accesso è nella richiesta in arrivo, nessuno potrebbe aprire Fiddler e creare una richiesta con il nome di accesso AD di un altro utente ?

    
posta KodeKreachor 25.03.2012 - 06:20
fonte

2 risposte

4

Non sono sicuro di ciò che OAuth ti dà che non può essere realizzato usando altri mezzi. WCF + Rest funziona molto bene con l'autenticazione basata sulle attestazioni in bundle in WIF.

Poiché WCF implica che stai usando ASP.NET, ti consiglio di utilizzare Windows Identity Foundation (WIF) sul lato server. Dai un'occhiata a questo ebook per maggiori informazioni.

Quindi hai bisogno di un modo per esporre l'annuncio alla tua app. Puoi utilizzare ADFSv2 , che è gratuito su Windows 2008 R2. Dai un'occhiata all'installazione SQL che protegge dagli attacchi di replay delle sessioni.

Copiare e incollare le credenziali da Fiddler non è qualcosa che puoi fermare completamente. HTTPS aiuta, ma se vuoi veramente investigare su questo problema, consulta questo Q & A su Stackoverflow .

    
risposta data 27.03.2012 - 01:11
fonte
1

OAuth può essere un'ottima scelta se stai supportando le applicazioni mobili. In questo modo l'app mobile può memorizzare un token di accesso senza dover portare con sé la password dell'utente sul dispositivo. Lo scenario di base è che l'applicazione richiede il token da un gateway che richiede agli utenti le credenziali (userid / pw) e quindi convalida con l'annuncio. Una volta convalidato, il gateway rilascia il token di accesso (eventualmente tramite lo scambio di codici di accesso) all'app. L'app utilizza il token per richiedere servizi. L'applicazione che fornisce i servizi può verificare con il gateway per verificare il token E ottenere la mappatura dal token di accesso al nome utente. In questo modo, il gateway mantiene le mappature ma solo per la durata utile per il token di accesso.

    
risposta data 27.03.2013 - 19:48
fonte