Développement de connexions par programmation avec le service JAAS (Java Authentication and Authorization)

Cette rubrique explique comment développer des connexions par programmation avec le service JAAS (Java™ Authentication and Authorization).

Avant de commencer

Le service JAAS (Java Authentication and Authorization Service) représente l'API principale utilisée pour l'authentification.

[AIX Solaris HP-UX Linux Windows][IBM i]JAAS remplace les API de connexion par programmation CORBA (Common Object Request Broker Architecture).

WebSphere Application Server offre des extension à JAAS :
  • Pour plus d'informations sur la configuration d'un environnement doté d'applications de client léger qui accèdent à des ressources éloignées sur un serveur, voir l'article concernant le développement d'applications qui utilisent CosNaming (interface CORBA Naming).
  • Si l'application utilise une configuration de connexion JAAS personnalisée, assurez-vous que cette dernière est correctement définie. Pour plus de détails, voir Configuration de connexions par programmation pour JAAS (Java Authentication and Authorization Service).
  • Certaines API JAAS sont protégées par des droits de sécurité Java 2. Si ces API sont utilisées par le code de l'application, vérifiez que ces droits sont ajoutés au fichier was.policy de l'application.
    Pour plus d'informations, voir les articles suivants : Pour connaître les API protégées par les droits de sécurité Java 2, consultez l'article Sécurité : Ressource d'apprentissage de la documentation sur les API publiques d'IBM® Developer Kit, Java Technology Edition ; JAAS et WebSphere Application Server.
    La liste suivante répertorie certaines API utilisées dans l'exemple de code de ce document, ainsi que les droits d'accès de la sécurité Java 2 requis pour ces API :
    • Les constructeurs javax.security.auth.login.LoginContext sont protégés par l'objet javax.security.auth.AuthPermission "createLoginContext".
    • Les méthodes javax.security.auth.Subject.doAs et com.ibm.websphere.security.auth.WSSubject.doAs sont protégées par l'objet javax.security.auth.AuthPermission "doAs".
    • Les méthodes javax.security.auth.Subject.doAsPrivileged et com.ibm.websphere.security.auth.WSSubject.doAsPrivileged sont protégées par l'objet javax.security.auth.AuthPermission "doAsPrivileged".
  • Modèle amélioré de ressources Java Platform, Enterprise Edition (Java EE) pour les vérifications d'autorisation.

    En raison d'une erreur de conception dans JAAS version 1.0, la méthode javax.security.auth.Subject.getSubject ne renvoie pas le sujet associé à l'unité d'exécution dans un bloc de code java.security.AccessController.doPrivileged. Cette situation peut entraîner un comportement incohérent, qui peut avoir des conséquences non souhaitées. La classe com.ibm.websphere.security.auth.WSSubject offre une solution pour obtenir l'association d'un sujet à une unité d'exécution. La classe com.ibm.websphere.security.auth.WSSubject étend le modèle JAAS aux ressources Java Platform, Enterprise Edition (Java EE) pour les vérifications d'autorisation. Si le sujet est associé à l'unité d'exécution dans la méthode com.ibm.websphere.security.auth.WSSubject.doAs ou si le bloc de code com.ibm.websphere.security.auth.WSSubject.doAsPrivileged contient des justificatifs du produit, le sujet est utilisé pour les vérifications d'autorisation des ressources Java EE.

  • Prise en charge de l'interface graphique pour la définition de la nouvelle configuration de connexion JAAS.
    Vous pouvez créer une configuration de connexion JAAS dans la console d'administration et la stocker dans un référentiel de configurations. Les applications peuvent définir une nouvelle configuration de connexion JAAS dans la console d'administration. Les données sont conservées dans le référentiel de configuration. Toutefois, WebSphere Application Server prend toujours en charge le format de configuration de connexion JAAS par défaut (fichier texte) fourni par l'implémentation JAAS par défaut. Si une configuration de connexion est définie à la fois dans le référentiel de configuration et au format de fichier texte, la configuration du référentiel prévaut. La définition de configuration de connexion dans le référentiel de configuration présente les avantages suivants :
    • Prise en charge de la console d'administration lors de la définition de la configuration de connexion JAAS
    • Gestion centrale de la configuration de connexion JAAS
    • Distribution de la configuration de connexion JAAS
  • Prise en charge de l'application pour l'authentification par programmation.

    WebSphere Application Server fournit des configurations de connexion JAAS afin que les applications effectuent une authentification par programmation auprès du module d'exécution de sécurité WebSphere. Ces configurations effectuent, en fonction des données d'authentification fournies, une authentification via le mécanisme d'authentification configuré par WebSphere Application Server, SWAM (Simple WebSphere Authentication Mechanism), LTPA (Lightweight Third Party Authentication), le registre d'utilisateurs (du système d'exploitation local, LDAP (Lightweight Directory Access Protocol), personnalisé ou référentiel fédéré) et l'authentification Kerberos. Le sujet authentifié à partir des configurations de connexion JAAS contient le principal et les justificatifs requis pouvant être utilisés par l'environnement d'exécution de la sécurité WebSphere pour la vérification des autorisations auprès de ressources protégées basées sur des rôles Java EE.

    Remarque : SWAM est obsolète dans WebSphere Application Server Version 9.0 et sera supprimé dans une version ultérieure.
    Voici les configurations de connexion JAAS fournies par WebSphere Application Server :
    • Configuration de connexion JAAS WSLogin. Une configuration de connexion JAAS générique peut utiliser des clients Java, des applications de conteneur client, des servlets, des fichiers JSP (JavaServer Pages) et des composants EJB (Enterprise JavaBeans) pour effectuer l'authentification sur l'environnement d'exécution de la sécurité WebSphere Application Server en fonction d'un ID utilisateur et d'un mot de passe ou d'un jeton. Toutefois, cette configuration ne prend pas en charge le gestionnaire CallbackHandler spécifié dans le descripteur de déploiement du conteneur du client.
    • Configuration de connexion JAAS WSKRB5Login. Une configuration de connexion JAAS générique peut utiliser des clients Java, des applications de conteneur client, des servlets, des fichiers JSP (JavaServer Pages) et des composants EJB (Enterprise JavaBeans) pour effectuer l'authentification dans l'environnement d'exécution de la sécurité WebSphere Application Server en fonction d'un ID utilisateur et d'un mot de passe ou d'un jeton. Toutefois, cette configuration ne prend pas en charge le gestionnaire CallbackHandler spécifié dans le descripteur de déploiement du conteneur du client.
    • Configuration de connexion JAAS ClientContainer. Cette configuration de connexion JAAS accepte le gestionnaire CallbackHandler indiqué dans le descripteur de déploiement du conteneur client. Le module de connexion de cette configuration de connexion utilise le gestionnaire CallbackHandler dans le descripteur de déploiement du conteneur client, même si le code de l'application a défini un gestionnaire de rappels dans le contexte de connexion. Concerne une application de conteneur client.

      Un sujet authentifié avec les configurations de connexion JAAS précédemment mentionnées contient un principal com.ibm.websphere.security.auth.WSPrincipal et un justificatif com.ibm.websphere.security.cred.WSCredential. Si le sujet authentifié est transmis dans la méthode com.ibm.websphere.security.auth.WSSubject.doAs ou dans les autres méthodes doAs, l'environnement d'exécution de la sécurité du produit peut effectuer des vérifications d'autorisation sur les ressources Java EE en fonction du sujet com.ibm.websphere.security.cred.WSCredential.

  • Configurations de connexion JAAS définies par le client.

    Vous pouvez définir d'autres configurations de connexion JAAS pour effectuer l'authentification par programmation qui crée un sujet personnalisé dans le processus client ou serveur. Certains principaux et justificatifs sont requis dans le sujet pour que l'exécution de sécurité du produit les utilise pour l'envoi d'informations d'authentification à partir du client via un protocole ou pour qu'elle les utilise pour la gestion de l'autorisation sur le serveur. Les justificatifs sont générés à partir des modules de connexion fournis.

    Le module de connexion nécessaire à la connexion du client Java pur est le suivant :
    • com.ibm.ws.security.common.auth.module.WSLoginModuleImpl required;
    Outre l'utilisation de ce module de connexion, le gestionnaire d'appels utilisé doit pouvoir gérer les classes d'appel suivantes.
    • javax.security.auth.callback.NameCallback
    • javax.security.auth.callback.PasswordCallback
    Un nom d'utilisateur et un mot de passe doivent être indiqués dans le gestionnaire d'appels. Les classes personnalisées ajoutées au sujet sur le client doivent être propagées au serveur automatiquement lorsque la propagation d'attribut de sécurité est activée. Vous pouvez définir le mot de passe sur null, si vous souhaitez utiliser la vérification d'identité sans mot de passe.
    Pour plus d'informations sur l'activation de la propagation d'un client Java pur, voir l'étape correspondante dans Propagation des attributs de sécurité parmi les serveurs d'applications.
    Remarque : Les classes ajoutées au sujet doivent être sérialisables et désérialisables sur Java pour s'appliquer correctement.
    Les modules de connexion nécessaires pour une connexion de serveur sont les suivants :
    • com.ibm.ws.security.server.lm.ltpaLoginModule required;
    • com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule required;
    Pour plus d'informations sur les appels utilisés pour une configuration de connexion côté serveur, voir Personnalisation de l'authentification JAAS (Java Authentication and Authorization Service) côté serveur et de la configuration de connexion.
  • Conditions de nommage pour les connexions par programmation sur un client Java pur.

    Lorsqu'une connexion par programmation est établie sur un client Java pur et que la valeur de la propriété com.ibm.CORBA.validateBasicAuth est true, le code de sécurité doit savoir où le serveur de sécurité réside. En général, le contexte initial par défaut suffit lorsque la propriété java.naming.provider.url est définie comme étant une propriété système ou que sa définition figure dans le fichier jndi.properties. Dans d'autres cas, il n'est pas conseillé de définir les mêmes propriétés java.naming.provider.url sur l'ensemble du système. Sinon, il est nécessaire d'indiquer les données d'amorçage spécifiques de la sécurité dans le fichier sas.client.props. La procédure suivante présente l'ordre des opérations à effectuer pour déterminer comment trouver le serveur de sécurité dans un client Java pur :

Remarque : Définissez com.ibm.CORBA.validateBasicAuth=false à chaque connexion à un serveur z/OS. Pour l'instant, cette fonction ne fonctionne pas d'un client réparti vers un serveur z/OS car le serveur de sécurité est recherché à l'aide du principal UNAUTHENTICATED, qui n'est pas accepté sur un système z/OS.

Procédure

  1. Dans le fichier sas.client.props, recherchez les propriétés suivantes :
    com.ibm.CORBA.securityServerHost=myhost.mydomain
    com.ibm.CORBA.securityServerPort=mybootstrap port
    Si vous définissez ces propriétés, le serveur de sécurité (SecurityServer) est recherché dans ce fichier. L'hôte et le port indiqués peuvent représenter tout port d'amorçage et hôte WebSphere valides. Le serveur de sécurité (SecurityServer) figure dans tous les processus serveur. Il n'est donc pas nécessaire de choisir un hôte ou un port précis. Si ces éléments sont indiqués, l'infrastructure de sécurité dans le processus client recherche le serveur de sécurité en fonction des informations se trouvant dans le fichier sas.client.props.
  2. Insérez le code suivant dans l'application client pour obtenir un nouvel InitialContext() :
    ...
       import java.util.Hashtable;
      	import javax.naming.Context;
      	import javax.naming.InitialContext;
      	...
       
    // Perform an InitialContext and default lookup prior to logging 
    // in so that target realm and bootstrap host/port can be 
    // determined for SecurityServer lookup.
       
       			Hashtable env = new Hashtable();
       			env.put(Context.INITIAL_CONTEXT_FACTORY, 			"
                  com.ibm.websphere.naming.WsnInitialContextFactory");
       			env.put(Context.PROVIDER_URL, 			
                  "corbaloc:iiop:myhost.mycompany.com:2809");
       			Context initialContext = new InitialContext(env);
       			Object obj = initialContext.lookup("");
    
    			// programmatic login code goes here.
    Avant d'exécuter une connexion par programmation, effectuez l'opération ci-après. Indiquez dans ce code un fournisseur d'URL pour le contexte d'affectation de nom. Il doit désigner une instance WebSphere Application Server valide dans la cellule auprès de laquelle vous vous authentifiez. Le pointage sur une cellule permet aux connexions par programmation propres aux unités d'exécution d'accéder à différentes cellules et d'avoir un emplacement SecurityServer pour l'ensemble du système.
  3. Utilisez la nouvelle méthode InitialContext() par défaut sur la base des règles de dénomination prioritaires décrites dans l'exemple d'extraction du contexte initial par défaut.

Exemple : Connexions par programmation à l'aide de l'authentification BasicAuth

Cet exemple illustre la manière dont les programmes d'application peuvent effectuer une connexion par programmation à l'aide de l'authentification BasicAuth.

Ajout de connexions par programmation avec le jeton Kerberos :

LoginContext lc = null;
            
 try {
       lc = new LoginContext("WSKRB5Login",         
                  new WSCallbackHandlerImpl("userName", "password"));
 } catch (LoginException le) {
        System.out.println("Cannot create LoginContext. " + le.getMessage());
        // Insert the error processing code 
 } catch(SecurityException se) {
        System.out.println("Cannot create LoginContext." + se.getMessage());
        // Insert the error processing code
  }

  try {
         lc.login(); 
  } catch(LoginException le) {
         System.out.println("Fails to create Subject. " + le.getMessage());
          // Insert the error processing code

Le nouveau contexte de connexion montré dans l'exemple est initialisé avec la configuration de connexion WSKRB5Login et le gestionnaire de rappels WSCallbackHandlerImpl. Utilisez l'instance WSCallbackHandlerImpl de l'application côté serveur lorsque vous ne souhaitez pas recevoir de messages d'invite. Une instance WSCallbackHandlerImpl est initialisée par l'ID utilisateur et le mot de passe indiqués, et par les informations relatives au domaine. La présente implémentation de la classe Krb5LoginModuleWrapperClient qui est spécifiée par la configuration de connexion WSKRB5Login ne peut extraire les informations d'authentification que du gestionnaire de rappels spécifié. Vous pouvez construire un contexte de connexion avec un objet Subject, mais l'objet Subject est ignoré par la présente implémentation Krb5LoginModuleWrapperClient.

Pour un client d'application de type Java pur, le produit comporte deux autres implémentations de gestionnaire de rappels : WSStdinCallbackHandlerImpl et WSGUICallbackHandlerImpl, qui demandent l'ID utilisateur, le mot de passe et les informations de domaine sur la ligne de commande et dans le panneau en incrustation. Vous pouvez choisir l'une des implémentations de gestionnaire de rappels du produit, en fonction de l'environnement d'application spécifique. Vous pouvez développer un nouveau gestionnaire de rappels si aucune de ces implémentations ne convient à votre application.

D'autres rappels peuvent être utilisés avec WSKRB5Login : WSAuthMechOidCallbackImpl et WSCcacheCallBackHandlerImpl. WSAuthMechOidCallbackImpl vous permet d'indiquer l'OID de mécanisme d'authentification. La valeur de l'OID de mécanisme d'authentification Kerberos est "1.2.840.113554.1.2.2". WSCcacheCallBackHandlerImpl vous permet d'indiquer le nom d'utilisateur, le nom de domaine Kerberos et le chemin complet du cache d'informations d'identification Kerberos. Vous pouvez également préciser si vous souhaitez utiliser l'emplacement par défaut du cache d'informations d'identification Kerberos. Si vous choisissez d'utiliser cet emplacement par défaut, le cache d'informations d'identification Kerberos est ignoré. Si vous utilisez Kerberos à des fins d'authentification, vous devez mettre à jour le fichier sas.client.props.

Vous pouvez aussi développer votre propre module de connexion si l'implémentation WSLoginModuleImpl par défaut ne peut pas répondre à tous vos besoins. Ce produit fournit des fonctions utilitaires, décrites dans la section suivante, que le module de connexion personnalisé peut utiliser.

[AIX Solaris HP-UX Linux Windows][z/OS]Dans le cas où la propriété java.naming.provider.url n'a pas été définie comme propriété système ni dans le fichier jndi.properties, un contexte InitialContext par défaut ne fonctionne pas correctement si le serveur ne se trouve pas à l'emplacement localhost:2809. Dans ce cas, générez un contexte InitialContext à l'aide d'un programme, avant la connexion JAAS. En effet, JAAS doit connaître l'emplacement du serveur de sécurité pour vérifier si l'ID utilisateur et le mot de passe entrés sont corrects, avant d'effectuer une méthode commit. Lorsque vous générez un contexte InitialContext suivant la méthode décrite plus loin dans cette rubrique, le code de sécurité dispose des informations nécessaires pour rechercher le serveur de sécurité et le domaine cible.

[IBM i]Dans le cas où la propriété java.naming.provider.url n'a pas été définie comme propriété système ni dans le fichier jndi.properties, un contexte InitialContext par défaut ne fonctionne pas correctement si le serveur ne se trouve pas à l'emplacement nom_serveur:2809. Dans ce cas, générez un contexte InitialContext à l'aide d'un programme, avant la connexion JAAS. En effet, JAAS doit connaître l'emplacement du serveur de sécurité pour vérifier si l'ID utilisateur et le mot de passe entrés sont corrects, avant d'effectuer une méthode commit. Lorsque vous générez un contexte InitialContext suivant la méthode décrite plus loin dans cette rubrique, le code de sécurité dispose des informations nécessaires pour rechercher le serveur de sécurité et le domaine cible.

Avertissement : La première ligne commençant par env.puta été scindée en deux à des fins d'illustration.
import java.util.Hashtable;
   import javax.naming.Context;
   import javax.naming.InitialContext;
   ...
   
// Perform an InitialContext and default lookup prior to logging in so that target realm
// and bootstrap host/port can be determined for SecurityServer lookup.
   
   Hashtable env = new Hashtable();
   env.put(Context.INITIAL_CONTEXT_FACTORY, 
           "com.ibm.websphere.naming.WsnInitialContextFactory");
   env.put(Context.PROVIDER_URL, "corbaloc:iiop:myhost.mycompany.com:2809");
   Context initialContext = new InitialContext(env);
   Object obj = initialContext.lookup("");
   
    LoginContext lc = null;
    try {
       lc = new LoginContext("WSLogin",         
                  new WSCallbackHandlerImpl("userName", "realm", "password"));
    } catch (LoginException le) {
        System.out.println("Cannot create LoginContext. " + le.getMessage());
        // insert error processing code 
    } catch(SecurityException se) {
        System.out.printlin("Cannot create LoginContext." + se.getMessage();
        // Insert error processing 
    }

    try {
         lc.login(); 
    } catch(LoginException le) {
         System.out.printlin("Fails to create Subject. " + le.getMessage());
          // Insert error processing code
    }

Icône indiquant le type de rubrique Rubrique de tâche



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=tsec_pacs
Nom du fichier : tsec_pacs.html