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.
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.
- Version
- Nonce
- Expiration
- Domaine
- Principal
- ID accès
- Rôles (actuellement inutilisé)
- Groupes
- Données personnalisées
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 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é.