Mécanisme d'authentification des jetons RSA

Le mécanisme d'authentification Rivest Shamir Adleman (RSA) simplifie l'environnement de sécurité de la topologie FMT (Flexible Management Topology). Il permet d'enregistrer de nouveaux serveurs dans la topologie FMT d'une manière simple et sécurisée. La topologie FMT vous permet de soumettre et de gérer des travaux administratifs, localement ou à distance, en utilisant un gestionnaire de travaux qui gère les applications et la maintenance des programmes, modifie les configurations et contrôle les programmes d'exécution des serveurs d'applications. Le mécanisme d'authentification RSA sert uniquement pour l'authentification administrative entre serveurs, par exemple pour les connexions d'administrateur et les demandes de transfert de fichier. Il ne remplace pas LTPA ou Kerberos pour l'utilisation par des applications.

Remarque : Le mécanisme d'authentification de jeton RSA facilite la gestion pour préserver les configurations de profils et les isoler du point de vue de la sécurité. Ce mécanisme permet aux profils de base gérés par un agent administratif d'avoir des clés LTPA (Lightweight Third-Party Authentication), des registres utilisateur et des utilisateurs administratifs différents.
Important : Le jeton RSA n'est pas lié au jeton RSA SecureId. Notez que le serveur d'applications ne prend pas en charge le jeton SecureId.

L'authentification est le processus permettant de déterminer si un client est bien celui qu'il prétend être dans un contexte particulier. Le client peut être un utilisateur final, un système ou une application. En règle générale, le mécanisme d'authentification de WebSphere Application Server fonctionne en relation étroite avec un registre d'utilisateurs. Le registre d'utilisateurs est le référentiel de compte de groupes et d'utilisateurs consulté par le mécanisme d'authentification lors de la procédure. Le mécanisme d'authentification est chargé de créer des justificatifs, qui constituent la représentation interne d'un utilisateur client correctement authentifié. Tous les justificatifs ne sont pas créés de manière identique. Les fonctions du justificatif sont déterminées par le mécanisme d'authentification configuré.

Processus d'authentification

Le mécanisme d'authentification de jeton RSA garantit qu'une fois le certificat de signataire racine RSA (durée de vie : 15 ans) échangé entre deux processus d'administration, la synchronisation des informations de sécurité entre des profils différents pour les demandes administratives est inutile. Le certificat personnel RSA (durée de vie : 1 an) est utilisé pour effectuer les opérations cryptographiques sur les jetons RSA et peut être vérifié par la racine RSA à durée de vie longue. L'authentification du jeton RSA est différente de l'authentification LTPA, dans laquelle les clés sont partagées et, en cas de modification d'un côté, tous les côtés doivent être modifiés. L'authentification de jeton RSA étant basée sur une infrastructure PKI, elle profite de l'évolutivité et de la gérabilité de cette technologie dans une topologie de grande taille.

Un jeton RSA dispose de fonctions de sécurité plus avancées que l'authentification LTPA ; elles incluent une valeur de nonce qui en fait un jeton à utilisation unique, un délai d'expiration court (car il s'agit d'un jeton à utilisation unique), et une relation de confiance établie en se basant sur les certificats dans le magasin de relations de confiance RSA cible.

L'authentification du jeton RSA n'utilise pas les mêmes certificats que ceux utilisé par SSL (Secure Sockets Layer). C'est pourquoi RSA a ses propres magasins de clés. Pour pouvoir isoler la relation de confiance établie pour RSA, le magasin de relations de confiance, le magasin de clés, et le magasin de clés racine doivent être différents de la configuration SSL.
Remarque : Les certificats personnels SSL donnés aux clients purs sont souvent signés par le même certificat racine SSL que celui utilisé par les serveurs, ce qui permet à un client pur d'envoyer un jeton RSA à un serveur et d'agir en tant qu'administrateur. Il convient d'éviter cela pour le mécanisme d'authentification du jeton RSA. Il dispose de son propre certificat racine qui signe les certificats personnels utilisés pour chiffrer et signer des parties du jeton.
Les données stockées dans un jeton RSA sont basées sur l'identité du sujet client. Le sujet client peut être basé sur LTPA ou Kerberos, mais le jeton RSA n'utilise pas cette protection pour les demandes administratives. Le jeton RSA est plus facile à utiliser en conservant un transport sécurisé de l'identité. Les données d'un jeton RSA incluent :
  • Version
  • Nonce
  • Expiration
  • Domaine
  • Principal
  • ID accès
  • Rôles (actuellement inutilisé)
  • Groupes
  • Données personnalisées
Des données personnalisées peuvent être ajoutées à WSCredential du côté émetteur (avant la sortie) en créant un objet de propriétés, en ajoutant des attributs personnalisés puis en les ajoutant à WSCredential de la manière suivante.
import com.ibm.websphere.security.cred.WSCredential;

java.util.Properties props = new java.util.Properties();
props.setProperty("myAttribute", "myValue");
WSCredential.put ("customRSAProperties", props);
Une fois le Sujet créé sur le processus cible, vous pouvez accéder à ces attributs de la manière suivante.
java.util.Properties props = (java.util.Properties) WSCredential.get("customRSAProperties");

Ces données sont placées dans une table de hachage du côté cible, utilisée dans une connexion JAAS (Java™ Authentication and Authorization Service) pour obtenir un sujet sur la cible, contenant les mêmes attributs que ceux du jeton RSA. Avec une cible contenant les mêmes attributs du jeton RSA, vous pouvez avoir un sujet du côté cible qui ne provient pas du même domaine que celui utilisé pas la cible. Pour que cette autorisation réussisse, un mappage interdomaines est requis dans la table d'autorisation d'administration, à moins que l'identité ne soit un ID de serveur de confiance.

La figure dans la section ci-après est un aperçu du mécanisme d'authentification du jeton RSA et décrit le processus exécuté lorsqu'une demande est envoyée d'un serveur-comme-client à un serveur cible. Le serveur-comme-client a un sujet d'administration sur l'unité d'exécution, utilisé comme entrée pour créer le jeton RSA. L'autre information requise est le certificat public RSA du serveur cible. Ce certificat doit être extrait en émettant une requête “d'amorçage” MBean sur le processus cible avant d'envoyer des requêtes réelles. La demande d'amorçage cible extrait le certificat public du processus cible. Lors de la création d'un jeton RSA, l'objectif principal de l'obtention du certificat public de la cible est de chiffrer la clé secrète. Seule la cible peut déchiffrer la clé secrète utilisée pour chiffrer les données utilisateur.

La figure dans la section ci-après illustre le mécanisme d'authentification par jeton RSA et décrit ce qui se produit quand une requête est adressée par un serveur agissant comme un client à un serveur de destination. Le premier serveur insère un sujet administratif dans l'unité d'exécution utilisée en entrée afin de créer le jeton RSA. Les autres informations requises sont le certificat public RSA du serveur cible. Ce certificat doit être extrait au moyen d'une requête de bean géré de type “bootstrap” adressée au processus cible avant toute autre requête réelle. La requête “bootstrap” cible récupère le certificat public auprès du processus cible. Lors de la création du jeton RSA, le certificat public du serveur cible sert à chiffrer la clé secrète. Seul le serveur cible peut déchiffrer la clé secrète, qui sert à chiffrer les données de l'utilisateur.

La clé privée du client est utilisée pour signer la clé secrète et les données utilisateur. La clé publique du client est intégrée dans le jeton RSA et validée sur la cible. Si la clé publique du client n'est pas digne de confiance lors de l'appel des API CertPath sur la cible, la validation du jeton RSA ne peut pas se poursuivre. Si la clé publique du client est digne de confiance, elle peut être utilisée pour vérifier les signatures de la clé secrète et des données utilisateur.

L'objectif principal est de convertir le sujet client en sujet sur la cible en transmettant de manière sécurisée les informations requises. Une fois le sujet généré sur la cible, le processus du mécanisme d'authentification RSA est terminé.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_7rsa_token_auth
Nom du fichier : csec_7rsa_token_auth.html