REST Stratégie de génération de clés API
Je dois fournir une autorisation et une authentification pour mes REST API implémentées à l'aide du standard JAX-RS, destinées à être utilisées à partir de clients mobiles et de certains périphériques. J'ai plusieurs appareils avec une identification unique qui peut POST certaines données. Les clients mobiles utilisent simplement les requêtes GET pour afficher ces données. Je suis plus préoccupé par la partie POST, où je veux authentifier les clients. Aussi, je voudrais garder les choses simples. Je pense utiliser une simple autorisation HTTP de base via HTTPS, avec une clé API. Ma question est la suivante: comment générer cette clé API?
Vous pouvez jeter un coup d'œil à Shiro: http://shiro.Apache.org C'est un cadre très agréable pour "sécuriser" les API (autorisation, authentification et autres choses pour la sécurité). Vous pouvez implémenter une "authentification de base" pour "connecter" vos utilisateurs (via un nom d'utilisateur/mot de passe), puis leur fournir une clé API, que vous pouvez utiliser pour effectuer une "authentification de jeton du support" afin de leur permettre d'accéder aux ressources de votre API. Pour ce faire, vous définiriez ce que shiro appelle des "filtres", qui sont définis sur les ressources de l'API ... ceci est défini dans un "shiro.ini" comme suit:
[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
Vous devez implémenter/étendre certains des filtres par défaut de Shiro pour les faire fonctionner avec votre base de données afin d’obtenir vos données d’authentification des utilisateurs, etc. Ce qui est bien, c’est qu’ils fournissent de nombreux outils pour traiter les problèmes de sécurité, par exemple: pour générer des clés d’API, salez et cryptez, etc. Jetez un coup d’œil sur leurs tutoriels, ils sont en général très bons.
Il existe d'autres cadres, notamment Java EE prend en charge la sécurité et Spring fournit également une prise en charge de la sécurité. Regardez cette très belle présentation de Mat Raible où il présente et démontre ces trois frameworks: http://www.slideshare.net/mraible/Java-web-application-security-denver-jug-2013
Vous pouvez utiliser un UUID pour cela. Un UUID ressemble à ceci:
550e8400-e29b-41d4-a716-446655440000
Il existe des bibliothèques pour générer des UUID disponibles dans tous les langages de programmation.
Je me penche également sur la question. Si je voulais me fier aux normes JAX-RS tout en maintenant l’application «pure», j’utiliserais le système d’authentification par défaut fourni avec le conteneur (qui est généralement l’autorisation BASIC).
Cela signifie que le conteneur devra exécuter l'authentification et l'autorisation au niveau du cours, telles que les applications Java EE qui respectent la norme et ne pas générer de solutions de contournement (à l'aide de Shiro).
Toutefois, si vous souhaitez utiliser le concept de jetons d’API et autres tout en préservant l’application du système d’authentification, vous devez implémenter ce travail ailleurs, à savoir le conteneur.
Malheureusement, l'authentification par conteneur devrait être spécifique à un conteneur. JAAS ne décrit pas une API de conteneur standard permettant d'effectuer des domaines d'authentification. Même leur tutoriel http://docs.Oracle.com/javaee/6/tutorial/doc/bnbxj.html parle de la configuration spécifique de Glassfish.
Si votre organisation est suffisamment grande, DataPower prend également en charge OAuth http://www.ibm.com/developerworks/websphere/library/techarticles/1208_rasmussen/1208_rasmussen.html afin que vous puissiez probablement l'utiliser pour gérer l'authentification et le transfert les informations d'identification appropriées à votre application. Toutefois. vous devez toujours faire quelque chose de spécifique au vendeur.
Ce n’est pas une mauvaise chose cependant, je préférerais faire cette approche plutôt que de polluer l’application avec son propre système d’authentification, rendant ainsi les choses inflexibles si le système d’authentification devait changer. par exemple. SonarQube possède son propre système d'authentification, qui ne prend pas en charge les certificats côté client.