Strategia di generazione chiavi API REST

Question

Devo fornire l'autorizzazione e l'autenticazione per le mie API REST implementate utilizzando lo standard JAX-RS, che devono essere consumate dai client mobili e da alcuni dispositivi. Dispongo di più dispositivi con un'identificazione univoca del dispositivo che può POSTARE alcuni dati. I client mobili utilizzano semplicemente le richieste GET per visualizzare tali dati. Sono più preoccupato per la parte POST, in cui voglio autenticare i client. Inoltre, mi piacerebbe mantenerlo semplice. Sto pensando di utilizzare una semplice autorizzazione di base HTTP su HTTPS, con una chiave API. La mia domanda è come posso generare questa chiave API?

Answer 1

ha trovato alcuni articoli bello che eliminato il mio dubbio circa la generazione di chiavi API e li utilizzano per l'autenticazione:

http://restcookbook.com/Basics/loggingin/ http://www.smartjava.org/content/protect-rest-service-using-hmac-play-20

Answer 2

Si può dare un'occhiata a Shiro: http://shiro.apache.org È un framework molto bello per le API "sicure" (autorizzazione, autenticazione e altre cose per la sicurezza). È possibile implementare una "autenticazione di base" per "accedere" ai propri utenti (tramite un nome utente/password), quindi fornire loro una chiave API, che è possibile utilizzare per eseguire un'autenticazione del token al portatore per consentire loro di accedere alle risorse di la tua API. Per fare questo si dovrebbe definire che cosa shiro chiamate "filtri", che sono definiti per le risorse API ... questo è definito in un "shiro.ini", come il seguente:

[main] 
authcBasicRealm = com.yourapp.shiro.UserAuthenticatorRealm 
tokenValidatorFilter = com.yourapp.shiro.BearerAuthenticationTokenFilter 
tokenValidatorRealm = com.yourapp.shiro.BearerAuthenticationTokenRealm 

[urls] 
/rest/hello/login/** = ssl[8443], noSessionCreation, authcBasic 
/rest/hello/hello = ssl[8443], noSessionCreation, tokenValidatorFilter 

è necessario implementare/estendere alcune dei filtri predefiniti Shiro per farli funzionare con il DB per ottenere i dati di autenticazione dell'utente, ecc. La cosa bella è che forniscono molti strumenti per gestire i problemi di sicurezza, ad esempio: generare chiavi API, salare e crittografare, ecc. uno sguardo sui loro tutorial, sono in generale molto buoni.

Esistono altri framework, in particolare Java EE che supporta la sicurezza e Spring fornisce anche il supporto per la sicurezza. Date un'occhiata a questa bella presentazione di Mat Raible dove presenta e dimostra questi tre framework: http://www.slideshare.net/mraible/java-web-application-security-denver-jug-2013

Answer 3

Per questo è possibile utilizzare uno UUID. Un UUID è simile al seguente:

550e8400-e29b-41d4-a716-446655440000 

Ci sono librerie per generare UUID disponibili in ogni linguaggio di programmazione.

Answer 4

Sto cercando di questo sul mio fine, come pure, se voglio fare affidamento sugli standard JAX-RS e mantenere l'applicazione "pura", userei il sistema di autenticazione predefinito fornito con il container (che di solito è l'autenticazione BASIC).

Ciò significa che il contenitore deve eseguire l'autenticazione e l'autorizzazione del livello del corso come app Java EE che seguono lo standard e non creare soluzioni alternative (ad esempio utilizzando Shiro).

Tuttavia, se si desidera utilizzare il concetto di token API e così mantenendo la propria applicazione libera dall'implementazione del sistema di autenticazione, è necessario implementarlo altrove, ad esempio nel contenitore.

Sfortunatamente, l'autenticazione basata sul contenitore dovrebbe essere specifica del contenitore. JAAS non descrive un'API contenitore standard per realizzare reami di autenticazione. Anche il loro tutorial http://docs.oracle.com/javaee/6/tutorial/doc/bnbxj.html parla della configurazione specifica di Glassfish.

Se la tua organizzazione è abbastanza grande, DataPower supporterà anche OAuth http://www.ibm.com/developerworks/websphere/library/techarticles/1208_rasmussen/1208_rasmussen.html in modo che tu possa probabilmente usarlo per gestire l'autenticazione e passare le credenziali appropriate alla tua applicazione. Però. hai ancora bisogno di fare qualcosa specifico del venditore.

Tuttavia, non è una cosa negativa, preferirei fare questo approccio piuttosto che inquinare l'applicazione con il proprio sistema di autenticazione, rendendo le cose inflessibili nel caso in cui il sistema di autenticazione dovesse cambiare. per esempio. SonarQube ha il proprio sistema di autenticazione che non supporta i certificati lato client.