Come integrare OpenID nell'API Web MVC4

Question

Sto scrivendo un'API Web utilizzando MVC4 che deve essere utilizzata da più tipi di client. Voglio usare l'OpenID per autenticare.

Ho già scaricato il pacchetto DotNetOpenAuth NuGet, ma finora tutti gli esempi sono per un'app client, piuttosto che un'API.

Il mio problema è semplice. Voglio che i client inviino una richiesta di autenticazione alla mia API. L'API si autentica con un provider OpenID. L'API imposta quindi tutto ciò di cui ha bisogno per utilizzare i tag [Autorizza] in tutte le chiamate API web.

Comprendo che nelle applicazioni .NET è possibile chiamare FormsAuthentication.SetCookie, ma questa è anche una soluzione di facile implementazione per altre lingue?

La domanda in breve. Come integrare OpenID in un API Web MVC4 che consente l'utilizzo del tag Authorize che può essere chiamato e utilizzato da più lingue?

Answer 1

Potrebbe confondere i ruoli di autenticazione e autorizzazione. Sembra che la tua API Web abbia bisogno di sia.

Iniziamo con l'autorizzazione. Ogni API (ovvero un URL Web a cui accede un'app client diversa da un browser) consente l'accesso anonimo o deve essere autorizzato (cioè l'autorizzazione). L'autorizzazione è il dominio OAuth. OAuth (v2, presumibilmente) descrive come un client autorizza una chiamata alla tua WebAPI.

Presumibilmente come parte del processo di autorizzazione, un utente accede al servizio. Questo passaggio per l'accesso dell'utente è l'autenticazione . Ed è ortogonale all'autorizzazione. Se si autentica l'utente tramite OpenID, nome utente/password, cert X.509, ecc., Dovrebbe essere irrilevante il modo in cui le chiamate WebAPI sono autorizzate. In altre parole, i metodi WebAPI non dovrebbero preoccuparsi di come l'utente ha autenticato (leggi: nessun OpenID lega qualsiasi cosa). Quello che avranno è un filtro di autorizzazione applicato a loro che verifica l'autorizzazione su una richiesta in arrivo e lo traduce in alcune informazioni, incluso il nome utente dell'account che ha autorizzato l'accesso, il livello di accesso, l'ID dell'autorizzazione cliente, ecc

Quindi, un passo alla volta, l'intero scenario potrebbe andare qualcosa di simile:

1. un utente che opera un'applicazione 3rd cliente parti (supponiamo per semplicità che questa applicazione client è un 3 ° applicazione web party) desidera utilizzare le funzionalità che richiedono che il client acceda alla WebAPI nel nome dell'utente.
2. Il client deve ottenere l'autorizzazione per la rappresentazione limitata dell'utente mentre il client effettua chiamate alla propria WebAPI. Iniziano con un reindirizzamento OAuth 2 all'endpoint di autorizzazione al tuo servizio. Se viene implementato utilizzando DotNetOpenAuth, è possibile utilizzare la classe WebServerClient.
3. L'endpoint di autorizzazione riempie il ruolo di un server di autorizzazione OAuth 2 e, come tale, utilizza la classe AuthorizationServer di DotNetOpenAuth. La prima cosa che fa è controllare se c'è un cookie di autenticazione dei moduli ASP.NET incluso nella richiesta. Questo cookie è un'indicazione naturale se l'utente ha già effettuato l'accesso al proprio servizio sul proprio browser e, in tal caso, chi è quell'utente. Il controllo di questo cookie è una semplice chiamata a Controller.User. Nota che il tuo endpoint di autorizzazione è MVC piuttosto che WebAPI perché la sua risposta è al browser/utente, non all'app client. Supponiamo che non ci sia un tale cookie e Controller.User è nullo (o User.Identity.IsAuthenticated è false).Fare riferimento all'esempio di OAuthAuthorizationServer per come implementare questo endpoint.
4. L'endpoint di autorizzazione risponde con un reindirizzamento alla pagina di accesso utente, incluso un parametro redirectUrl nella stringa di query che mantiene l'intero URL di richiesta di autorizzazione OAuth 2 in entrata.
5. La pagina di accesso dell'utente è un endpoint MVC che funge da OpenID Relying Party. Questo endpoint utilizza la classe OpenIdRelyingParty di DotNetOpenAuth. Nota che questo endpoint non sa nulla di OAuth 2 o roba di autorizzazione. Semplicemente autentica l'utente. Dopo aver autenticato l'utente, reindirizza nuovamente all'URL nell'argomento redirectUrl. Fare riferimento all'esempio OpenIdRelyingPartyMvc su come eseguire questa operazione.
6. L'endpoint di autorizzazione ripete il suo passaggio precedente, tranne che questa volta è presente un cookie FormsAuthentication in modo che possa visualizzare una pagina all'utente chiedendo se desidera autorizzare il client ad accedere ai dati dell'utente. L'utente fa clic su Sì. (attenzione: implementa le attenuazioni XSRF e clickjacking su questa pagina di autorizzazione utente).
7. L'endpoint di autorizzazione elabora la risposta affermativa dell'utente e chiama AuthorizationServer per creare il record di autorizzazione e restituire la risposta al client. Uno dei risultati di questa chiamata è la formulazione di una risposta di reindirizzamento al client che gli fornisce un codice di autorizzazione.
8. Il browser sta ora recuperando un URL dell'app client che gli passa il codice di autorizzazione. Il client utilizza quindi la classe WebServerClient per scambiare il codice di autorizzazione per un token di accesso (e di solito anche un token di aggiornamento).
9. L'app client effettua chiamate direttamente agli URL WebAPI, incluso il token di accesso ottenuto tramite OAuth 2 nell'intestazione dell'autorizzazione HTTP.
10. Il WebAPI occupa il ruolo del server di risorse OAuth2 e l'attributo del filtro di autorizzazione applicato ai metodi WebAPI per convalidare il token di accesso OAuth 2 in entrata utilizza la classe DotNetOpenAuth ResourceServer per eseguire il proprio lavoro. È possibile fare riferimento all'esempio OAuthResourceServer o, ancora meglio, David Christiansen's WebAPI sample per come procedere.

Questa è l'intera storia. E sì, il ruolo del cliente è facile da scrivere indipendentemente dalla lingua o dalla biblioteca che stanno usando.

BTW, gli esempi di DotNetOpenAuth cui faccio riferimento non sono distribuiti tramite NuGet. È get the samples from SourceForge.