Condivisione dei metodi di autenticazione tra API e web app

Question

Condivisione dei metodi di autenticazione tra API e web app

#1 da (1 voti)
#2 da (0 voti)

3

Desidero condividere un'implementazione di autenticazione su un'applicazione web e un'API web. L'applicazione Web sarà ASP.NET (principalmente MVC 4), l'API sarà principalmente API Web ASP.NET, anche se prevedo che avrà anche alcuni moduli o gestori personalizzati.

Voglio:

Condividi l'implementazione dell'autenticazione tra l'app e l'API il più possibile.
Fai in modo che l'applicazione Web si comporti come l'autenticazione dei moduli (pagina di accesso attraente, opzione di disconnessione, reindirizzamento a / dalla pagina di accesso quando una richiesta richiede autenticazione / autorizzazione).
I chiamanti API utilizzano qualcosa di simile a HTTP standard (401 - Non autorizzato, non 302 - Reindirizzamento).
Fornisci meccanismi di disconnessione lato client e server che non richiedono una modifica della password (quindi HTTP basic è out, poiché i client in genere memorizzano le loro credenziali).

Il modo in cui sto pensando di implementarlo consiste nell'usare l'autenticazione semplice dei moduli ASP.NET per l'applicazione Web e nello spingere un altro modulo nello stack (molto simile a MADAM - Modulo ASP.NET per l'Autenticazione Mista ). Questo modulo cercherà un header HTTP (specifico per l'implementazione) che indichi "caller is API".

Se l'intestazione "chiamante è API" è impostata, il servizio risponderà in modo diverso rispetto all'autenticazione dei moduli ASP.NET standard, sarà:

401 anziché 302 su una richiesta priva dell'autenticazione.
Cerca nome utente + passa in un'intestazione HTTP "Login" personalizzata e restituisci un ticket FormsAuthentication in un'intestazione "FormsAuth" personalizzata.
Cerca il ticket FormsAuthentication in un'intestazione "FormsAuth" personalizzata.

Le mie domande sono:

Esiste un framework per ASP.NET che copre già questo scenario?
Ci sono dei buchi evidenti in questa implementazione proposta? La mia paura primaria è un rischio per la sicurezza che non riesco a vedere, ma sono altrettanto preoccupato che possa esserci qualcosa in merito a tale implementazione che renderà eccessivamente restrittive o goffe con cui lavorare.

api authentication asp.net

posta Snixtor 19.11.2012 - 01:32

fonte

2 risposte

Leggi altre domande sui tag api authentication asp.net

Architettura del sistema degli eventi per il networking quando si tratta di prestazioni Passando variabili da PHP a C ++

score 1 · Answer 1

Non capisco cosa voglia realmente condividere.

Suppongo che non troverai un framework perché ciò che vuoi fare non è così difficile da risolvere.

1) Un'applicazione di terze parti sta per toccare solo l'API per scopi generici. Utilizza solo l'autenticazione API (tramite l'autenticazione moduli, l'utilizzo della chiave API, accetta la selezione).

2) La propria applicazione tramite le azioni dell'utente reindirizzerà alla pagina di accesso e tale e avrà il proprio prelievo dell'autenticazione (probabilmente l'autenticazione del modulo). Si tratta di cose che l'utente può potenzialmente accedere attraverso la barra degli indirizzi del browser web. Se la tua applicazione dovesse utilizzare l'API a scopo generale sotto il cofano, non dovrai reindirizzare l'utente alla tua pagina di accesso su chiamate Ajax. La tua applicazione dovrebbe gestire / prevenire questo per l'utente. Un utente non effettuerà chiamate API tramite la barra degli indirizzi del suo browser.

Quindi, affinché la tua applicazione sia in grado di utilizzare la tua API generica, l'API generica dovrebbe solo supportare lo stesso schema di autenticazione (autenticazione del modulo). Oppure la tua applicazione dovrebbe recuperare la chiave API dell'utente o qualcosa da usare dopo che l'utente ha effettuato l'accesso.

È possibile creare facilmente un attributo Authorize in MVC che verificherà più opzioni, prima per una chiave API, quindi per un token cookie basato su autenticazione moduli. Se non trova nulla che l'API per scopi generici debba o debba solo lanciare 401s.

La tua applicazione li preleverebbe da guasti alle chiamate ajax e potrebbe decidere di spostare l'utente sulla pagina di accesso.

score 0 · Answer 2

In genere, questo scenario (stesso sistema lato server, client diversi) viene gestito delegando ai client la responsabilità di utilizzare lo stesso set di servizi offerto dal server in diversi modi (nello schema, è il server che cambia il suo comportamento dipende dalla richiesta del cliente).

In altri termini, di solito hai:

Un singolo programma server Web che espone le API (di solito un servizio web, spesso un servizio web RESTful) che gestisce tutte le richieste.
Un client Web che richiede i dati necessari, crea la propria interfaccia utente e gestisce tutte le sue interazioni con il proprio utente e con il server in modo specifico. Ovviamente, l'interfaccia utente è generata e gestita con Javascript, HTML e CSS (AJAX).
Un client API (senza interfaccia utente) che richiede i dati necessari e li gestisce in modo specifico.

Sul lato server viene normalmente utilizzato un webservice RESTful perché utilizzando diversi verbi HTTP (GET, POST, ecc.) è abbastanza semplice distinguere e soddisfare le richieste provenienti da client diversi.

Messo da parte, di solito è considerata una pessima idea giocare con autenticazione personalizzata e meccanismi / protocolli di sicurezza perché è molto facile trascurare alcune importanti vulnerabilità. Se l'obiettivo principale del tuo sforzo di sviluppo NON è il meccanismo di autenticazione, dovresti probabilmente provare a utilizzare un sistema esistente, come OAuth, CAS o qualcosa del genere.

Naturalmente, se l'obiettivo principale del tuo sforzo di sviluppo è il meccanismo di autenticazione, questo non si applica a te. In questo secondo caso, dovresti inserire nell'intestazione della richiesta del client qualcosa che viene generato sul lato server, viene utilizzato solo per identificare il client e viene modificato molto spesso (ovvero: un ID sessione client, molto probabilmente un hash) e delegato tutti i controlli e la danza per i programmi lato server (che sono sotto il tuo controllo e sono affidabili).

Inserire una stringa facile da copiare e facile da forgiare nell'intestazione della richiesta del client e modificare il comportamento del software sul lato server a seconda di questa stringa, non è un buon modo per gestire un meccanismo correlato alla sicurezza come l'autenticazione .