Guide de sécurité
JBoss Enterprise Application Platform 6.1
À utiliser dans JBoss Enterprise Application Platform 6
Édition 1
Résumé
Cet ouvrage est un guide de sécurisation de la plateforme JBoss Enterprise Application Platform 6, et qui inclut des correctifs publiés.
Preface
Partie I. Sécurité dans JBoss Enterprise Application Platform 6
Chapitre 1. Introduction
1.1. Sécurité
La Sécurité informatique est le terme général donné au domaine de technologies informations qui est chargé de sécuriser les environnements virtuels à l'ère du numérique. Cela peut inclure la protection et l'intégrité des données, la sécurité des applications, l'évaluation du risque et de la vulnérabilité, et les protocoles d'authentification et d'autorisation.
Les données informatiques représentent un atout important pour la plupart des organisations. La protection des données est essentielle et constitue le noyau de la plupart des entreprises. JBoss Enterprise Application Platform fournit une approche multicouches de sécurité pour s'occuper des données à tous les niveaux.
Les systèmes vraiment sécurisés sont ceux conçus avec la sécurité comme principale caractéristique de haut en bas. Ces systèmes utilisent le principe de Sécurity by Design. Dans ces systèmes, les infiltrations et les attaques malveillantes sont acceptées comme partie intégrante de l'apparatus de sécurité normal et les systèmes sont conçus pour les contourner.
La sécurité peut être appliquée au niveau système d'exploitation , middleware ou application. Pour plus d'informations sur la sécurité au niveau du système d'exploitation telle qu'elle s'applique à RHEL, reportez-vous au document suivant : https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Security_Guide/index.html
Dans les prochains chapitres, vous lirez des informations sur les différents niveaux et des couches de sécurité au sein de la JBoss Enterprise Application Platform. Ces couches fournissent l'infrastructure pour toutes les fonctionnalités de sécurité de la plate-forme.
1.2. Sécurité pour l'administrateur de systèmes
Les administrateurs de systèmes, qui sont chargés des systèmes informatiques et réseaux, doivent être compétents pour traiter des attaques sur leurs réseaux et doivent également être proactifs pour contrecarrer ces attaques au moyen d'audits et d'exercices de sécurité plannifiés.
Pour un administrateur de systèmes confirmé, la planification de violations de la sécurité est une combinaison d'art et de science. Les menaces, qu'elles soient physiques, sur réseau ou basées données, varient de par leur nature et un administrateur de système de sécurité confirmé peut préparer le système pour les pannes et les redondances.
Un administrateur de systèmes spécialiste, ou un administrateur de sécurité n'est pas responsable du middleware ou de la sécurité des applications, mais uniquement la sécurité au niveau système et réseau.
1.3. Sécurité pour développeur J2EE
La sécurité niveau application tombe dans les mains du développeur J2EE. Même cela peut être divisé en trois rôles séparés :
- Développeur d'applications - responsable sécurité au niveau développement et pour définir les rôles, les règles et les logiques métier dans la logique de l'application.
- Assembleur d'applications - responsable de s'assurer que l'emballage des EAR et des WAR est fait pour que les vulnérabilités d'applications croisées soient réduites au minimum.
- Déployeur d'applications - responsable de sécuriser le déploiement des EAR et d'assigner et maintenir les listes de contrôle d'accès.
Il n'est pas rare que ces trois rôles soient tenus par le même groupe de développeurs.
JBoss Enterprise Application Platform, en tant que plateforme de composants, fournit une sécurité déclarative. Plutôt que d'intégrer la logique de sécurité dans un composant métier, vous décrivez les rôles de sécurité et les autorisations dans un descripteur XML standard. De cette façon, le code métier est isolé à partir du code sécurité. En savoir plus sur la sécurité déclarative dans JBoss Enterprise Application Platform ici .
La sécurité déclarative est renforcée par la sécurité par programmation. Les développeurs J2EE peuvent utiliser des API J2EE dans le code pour déterminer l'autorisation et appliquer une sécurité renforcée.
Partie II. Sécuriser la plate-forme
Chapitre 2. Le sous-système de sécurité
2.1. La sécurité du sous-système
Le sous-système de sécurité fournit l'infrastructure pour la fonctionnalité de sécurité de JBoss Enterprise Application Platform. La plupart des éléments de configuration ne doivent pas souvent utiliser deep-copy-subject-mode. De plus, vous pouvez configurer des propriétés de sécurité dans tout le système. L'ensemble de la configuration se soucie des domaines de sécurité.
Mode Deep Copy
Si le mode Deep Copy est désactivé (par défaut), la copie d'une structure de données de sécurité se réfère l'original uniquement au lieu de copier toute la structure de données. Ce comportement est plus efficace, mais prône à la corruption des données si plusieurs threads possédant la même identité effacent le sujet lors d'un vidage ou d'une déconnexion.
Le mode Deep Copy entraîne la copie totale de la structure des données et de toutes ses données associées, si elles sont marquées comme «clonables». C'est plus sûr niveau thread, mais moins efficace.
Propriétés de sécurité dans tout le système
Vous pouvez définir des propriétés de sécurité dans tout le système, qui sont appliquées à java.security.Security class.
Security Domain
Un domaine de sécurité est un ensemble de configuration de sécurité déclarative Java Authentication and Authorization Service (JAAS) qu'une ou plusieurs applications utilisent pour contrôler l'authentification, l'autorisation, l'auditing de sécurité et le mapping de sécurité. Trois domaines de sécurité sont inclus par défaut: jboss-ejb-policy, jboss-web-policy, et other. Vous pouvez créer autant de domaines de sécurité que vous souhaitez pour accommoder les besoins de vos applications.
2.2. Structure du sous-système de sécurité
Le sous-système de sécurité est configuré dans le domaine géré ou le fichier de configuration autonome. La plupart des éléments de configuration peuvent être configurés à l'aide de la Console de gestion via web ou du Management CLI sur console. Voici le code XML qui représente un exemple de sous-système de sécurité.
Exemple 2.1. Exemple de configuration de sous-système de sécurité
<subsystem xmlns="urn:jboss:domain:security:1.2">
<security-management>
...
</security-management>
<security-domains>
<security-domain name="other" cache-type="default">
<authentication>
<login-module code="Remoting" flag="optional">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
<login-module code="RealmUsersRoles" flag="required">
<module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/>
<module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/>
<module-option name="realm" value="ApplicationRealm"/>
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
</authentication>
</security-domain>
<security-domain name="jboss-web-policy" cache-type="default">
<authorization>
<policy-module code="Delegating" flag="required"/>
</authorization>
</security-domain>
<security-domain name="jboss-ejb-policy" cache-type="default">
<authorization>
<policy-module code="Delegating" flag="required"/>
</authorization>
</security-domain>
</security-domains>
<vault>
...
</vault>
</subsystem>
Les éléments
<security-management>, <subject-factory> et <security-properties> ne font pas partie de la configuration par défaut. Les éléments <subject-factory> et <security-properties> ont été dépréciés à partir de JBoss Enterprise Application Platform 6.1.
2.3. Chiffrement
Le chiffrement désigne le brouillage des informations sensibles en appliquant des algorithmes mathématiques. Le chiffrement est une des fondations de la sécurisation de votre infrastructure pour les violations de données, les pannes de système et autres risques.
Le chiffrement peut être appliqué aux données de chaînes simples, comme les mots de passe. Il peut également être appliqué aux flux de communication de données. Le protocole HTTPS, par exemple, crypte toutes les données en en transférant une partie à une autre. Si vous vous connectez d'un serveur à un autre en utilisant le protocole Secure Shell (SSH), l'ensemble de votre communication sera envoyée vers un tunnel crypté.
2.4. Sécurité déclarative
Sécurité déclarative est une méthode de séparation des problèmes de sécurité du code d'application, en utilisant le conteneur pour gérer la sécurité. Le conteneur procure un système d'autorisation basé soit sur les permissions de fichiers ou basé utilisateur, groupe ou rôle. Cette approche est normalement supérieure à la sécurité programmatique, qui donne à l'application toutes les responsabilités pour la sécurité.
La plate-forme JBoss Enterprise Application Platform fournit une sécurité déclarative par les domaines de sécurité.
2.5. Configurer le sous-système de sécurité
Vous pouvez configurer le sous-système de sécurité par le Management CLI ou par la Console de gestion basée web.
Chaque élément de niveau supérieur du sous-système de sécurité contient des informations sur un aspect différent la la configuration de la sécurité. Voir Section 2.2, « Structure du sous-système de sécurité » pour obtenir un exemple de configuration de sous-système.
- <security-management>
- Cette section remplace les comportemens de haut niveau du sous-système de sécurité. Chaque paramètre est optionnel. Il est rare de modifier ces paramètres sauf pour le mode de sujet Deep Copy.
Option Description deep-copy-subject-mode Indiquez si l'on doit copier ou lier les tokens de sécurité pour la sécurité des threads.authentication-manager-class-name Indiquer un nom de classe d'implémentation AthentificationManager alternatif à utiliser.default-callback-handler-class-name Spécifie un nom de classe global pour l'implémentation de CallbackHandler à utiliser avec les modules de connexion.authorization-manager-class-name Indiquer un nom de classe d'implémentation AthorizationManager alternatif à utiliser.audit-manager-class-name Indiquer un nom de classe d'implémentation Audit Manager alternatif à utiliser.identity-trust-manager-class-name Indiquer un nom de classe d'implémentation IdentityTrustManager alternatif à utiliser.mapping-manager-class-name Indiquer la nom de classe d'implémentation MappingManager à utiliser. - <subject-factory>
- L'usine de sujets contrôle la création d'instances de sujets. Elle utilise sans doute le gestionnaire d'authentification pour vérifier l'appelant. L'utilisation principale du sujet est la création d'un sujet par les composants JCA. Il est rare que l'on ait besoin de modifier l'usine de sujets.
- <security-domains>
- Un élément de conteneur qui contient plusieurs domaines de sécurité. Un domaine de sécurité peut contenir des informations sur des modules d'authentification, d'autorisation, de mappage, et d'auditing, ainsi qu'une autorisation JASPI et une configuration JSSE. Votre application indique ainsi un domaine de sécurité pour gérer ses informations de sécurité.
- <security-properties>
- Contient des noms et valeurs définis dans la classe java.security.Security
Chapitre 3. Management Interface Security
3.1. Sécuriser les interfaces de gestion
Résumé
Dans un environnement de test, il est de pratique courante de faire fonctionner JBoss Enterprise Application Platform 6 sans couche de sécurité sur les interfaces de gestion, composées de la Console de gestion, du Management CLI ou autre implémentation de l'API. Cela permet des changements rapides de développement et de configuration.
De plus, un mode silencieux d'authentification est présent par défaut, permettant à un client local sur une machine hôte de se connecter au Management CLI sans exiger un nom d'utilisateur ou un mot de passe. Ce comportement est pratique pour les utilisateurs locaux et les scripts de Management CLI, mais peut être désactivé si nécessaire. La procédure est décrite dans la rubrique .
Quand vous commencez à tester ou à préparer votre environnement pour aller en production, il est vitalement important de sécuriser les interfaces de gestion par l'une des méthodes suivantes au moins:
3.2. Configuration Sécurité Utilisateur par défaut
Introduction
Toutes les interfaces de gestion de JBoss Enterprise Application Platform 6 sont sécurisées par défaut. Cette sécurité existe sous deux formes :
- Les interfaces locales sont sécurisées par un contrat SASL entre des clients locaux et le serveur auquel ils se connectent. Ce mécanisme de sécurité repose sur la capacité du client à accéder au système de fichiers local. C'est parce que l'accès au système de fichiers local permettrait au client d'ajouter un utilisateur ou encore de modifier la configuration pour déjouer les autres mécanismes de sécurité. Cela est conforme au principe selon lequel si l'accès physique au système de fichiers est réussi, les autres mécanismes de sécurité sont superflus. Le mécanisme passe par quatre étapes :
Note
L'accès HTTP est considéré comme éloigné, même si vous vous connectez à l'hôte local par HTTP.- Le client envoie un message au serveur incluant une requête pour authentifier le mécanisme SASL local.
- Le serveur génère un token unique, qu'il écrit dans un fichier unique, et envoie un message au client avec le chemin d'accès fichier complet.
- Le client lit le token dans le fichier et l'envoie au serveur, pour vérifier qu'il a l'accès local au système de fichiers.
- Le serveur vérifie le token et efface le fichier.
- Les clients distants, y compris HTTP, utilisent une sécurité basée domaine. Le domaine par défaut qui comprend les autorisations pour configurer la plate-forme JBoss EAP 6 à distance en utilisant les interfaces de gestion est
ManagementRealm. Un script est fourni pour vous permettre d'ajouter des utilisateurs à ce domaine (ou à des domaines que vous créez). Pour plus d'informations sur la façon d'ajouter des utilisateurs, voir le chapitre Getting Started (Guide de démarrage) de la plateforme JBoss EAP 6. Pour chaque utilisateur, le nom d'utilisateur, un mot de passe haché et le domaine sont stockés dans un fichier.- Serveur autonome
JPP_HOME/standalone/configuration/mgmt-users.properties
Même si les contenus demgmt-users.propertiessont masqués, le fichier doit toujours être considéré comme un fichier sensible. Il est recommandé qu'il soit défini sur le mode de fichier600, qui ne donne aucun accès autre que l'accès en lecture et écriture au propriétaire du fichier.
3.3. Aperçu Général de la Configuration de l'Interface de Gestion avancée
La configuration de l'interface de Gestion
EAP_HOME/domain/configuration/host.xml or EAP_HOME/standalone/configuration/standalone.xml contrôle laquelle de vos interfaces réseau lie le processus contrôleur hôte, les types d'interfaces de gestion qui sont disponibles à tous, et quel type de système d'authentification est utilisé pour authentifier les utilisateurs sur chaque interface. Cette rubrique explique comment configurer les interfaces de gestion en fonction de votre environnement.
Le sous-système de Gestion est formé d'un élément
<management> avec plusieurs attributs configurables, et les trois éléments enfants configurables suivants. Les domaines de sécurité et les connexions sortantes sont tout d'abord définis, puis appliqués aux interfaces de gestion en tant qu'attributs.
<security-realms><outbound-connections><management-interfaces>
Domaines de sécurité
Le domaine de sécurité est chargé de l'authentification et de permettre aux utilisateurs autorisés d'administrer JBoss Enterprise Application Platform via l'API de gestion, le Management CLI ou la Console de gestion basée-web.
Il existe deux domaines de sécurité basés fichier différents qui existent dans l'installation par défaut :
ManagementRealm et ApplicationRealm. Chacun de ces domaines de sécurité utilise un fichier -users.properties pour stocker les utilisateurs et les mots de passe de hachage, et -roles.properties pour stocker les correspondances entre les utilisateurs et les rôles. Un support est également inclus pour le domaine de sécurité activé-LDAP.
Note
Les domaines de sécurité peuvent également être utilisés pour vos propres applications. Les domaines de sécurité dont il s'agit sont particuliers aux interfaces de gestion.
Les connexions de sortie
Certains domaines de sécurité se connectent à des interfaces externes, comme un serveur LDAP. Une connexion sortante définit la manière d'établir cette connexion. Un type de connexion prédéfinie, la connexion ldap-connection, définit tous les attributs obligatoires et facultatifs pour se connecter au serveur LDAP et vérifier les informations d'identification.
Interfaces de gestion
Une interface de gestion comprend des propriétés sur la façon de connecter et configurer JBoss Enterprise Application Platform. Ces informations comprennent l'interface réseau nommée, le port, le domaine de sécurité et autres informations configurables sur l'interface. Deux interfaces sont incluses dans une installation par défaut :
http-interfaceest la configuration de la console de gestion basée-web.native-interfaceest la configuration pour la Management CLi en ligne de commande et l'API de gestion Rest-like.
Chacun des trois principaux éléments configurables du sous-système de gestion de l'hôte sont étroitement liés. Un domaine de sécurité fait référence à une connexion sortante et une interface de gestion à un domaine de sécurité.
3.4. Disable the HTTP Management Interface
Dans un domaine géré, vous avez seulement besoin d'un accès à l'interface HTTP sur le contrôleur de domaine, plutôt que sur des serveurs membres de domaine. En outre, sur un serveur de production, vous pouvez finalement décider de désactiver la Console de gestion basée-web.
Note
Les autres clients, tels que JBoss Operations Network, opèrent également par l'interface HTTP. Si vous souhaitez utiliser ces services ou tout simplement désactiver la gestion de la Console elle-même, vous pouvez définir l'attribut
console-enabled-attribute de l'interface HTTP à false, au lieu de désactiver l'interface complètement.
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
Pour désactiver l'interface HTTP, ce qui désactive également l'accès à la Console de gestion basée-web, vous pouvez finalement supprimer l'interface HTTP.
La commande JBoss CLI suivante vous permettra de lire le contenu actuel de votre interface HTTP, si vous décidez de l'ajouter à nouveau.
Exemple 3.1. Lire la configuration de l'interface HTTP
/host=master/core-service=management/management-interface=http-interface/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
"outcome" => "success",
"result" => {
"console-enabled" => true,
"interface" => "management",
"port" => expression "${jboss.management.http.port:9990}",
"secure-port" => undefined,
"security-realm" => "ManagementRealm"
}
}
Pour supprimer l'interface HTTP, lancer la commande suivante :
Exemple 3.2. Supprimer l'interface HTTP
/host=master/core-service=management/management-interface=http-interface/:remove
Pour activer l'accès à nouveau, lancer la commande suivante pour recréer l'Interface HTTP avec les valeurs par défaut.
Exemple 3.3. Recréer l'Interface HTTP
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=true)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=interface,value=management)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=port,value=${jboss.management.http.port:9990})/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealm)
3.5. Supprimer l'Authentification silencieuse du Domaine de sécurité par défaut.
Résumé
L'installation par défaut de JBoss Enterprise Application Platform 6 contient une méthode d'authentification silencieuse pour un utilisateur de Management LCI locaI. Cela donne à l'utilisateur local la possibilité d'accéder au Management CLI sans authentification du nom d'utilisateur ou du mot de passe. Cette fonctionnalité est activée dans un but pratique et pour faciliter l'exécution des scripts de Management CLI sans exiger l'authentification des utilisateurs locaux.Cette méthode est considérée comme une caractéristique utile étant donné que l'accès à la configuration locale donne généralement aussi à l'utilisateur la possibilité d'ajouter ses propres détails utilisateur ou sinon la possibilité de désactiver les contrôles de sécurité
La commodité de l'authentification silencieuse des utilisateurs locaux peut être désactivée quand un plus grand contrôle de sécurité est requis. Ceci peut être réalisé en supprimant l'élément
local au sein de la section security-realm du fichier de configuration. S'applique à la fois pour standalone.xml pour une instance de serveur autonome, ou pour host.xml pour un domaine géré. Vous ne devriez envisager de supprimer que l'élément local si vous comprenez l'impact que ceci pourrait avoir sur la configuration de votre serveur particulier.
La meilleure méthode pour désactiver l'authentification silencieuse est d'utiliser le Management CLI, qui retire l'élément
local visible dans l'exemple suivant.
Exemple 3.4. Exemple d'élément local dans security-realm
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<local default-user="$local"/>
<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
</security-realm>
<security-realm name="ApplicationRealm">
<authentication>
<local default-user="$local" allowed-users="*"/>
<properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
</security-realms>
Procédure 3.1. Supprimer l'Authentification silencieuse du Domaine de sécurité par défaut.
Supprimer l'authentification silencieuse par le Management CLI
Supprimer l'élémentlocaldu Domaine de gestion et du Domaine d'applications comme requis.- Supprimer l'élément
localdu Domaine de gestion.Pour les serveurs autonomes
/core-service=management/security-realm=ManagementRealm/authentication=local:remove
Pour les domaines gérés
/host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove
- Supprimer l'élément
localdu Domaine d'applications.Pour les serveurs autonomes
/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
Pour les domaines gérés
/host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
Résultat
L'authentification silencieuse est retirée du ManagementRealm et de l' ApplicationRealm.
3.6. Désactiver l'accès à distance du Sous-système JMX
Une connectivité à distance JMX vous permet de déclencher JDK et les opérations de gestion d'applications. Afin de garantir une installation, désactivez cette fonction. Vous pouvez faire cela soit en enlevant la configuration de la connexion à distance, ou en enlevant le sous-système JMX entièrement. Les commandes du JBoss CLI référencent le profil par défaut dans une configuration de domaine géré. Pour modifier un profil différent, modifiez la partie de la commande
/profil=default. Pour un serveur autonome, retirez complètement cette partie de la commande.
Note
Dans un domaine géré, le connecteur distant est retiré du sous-système JMX par défaut. Cette commande est fournie pour votre information, au cas où vous souhaiteriez l'ajouter en cours de développement.
Exemple 3.5. Supprimer le Connecteur distant du Sous-système JMX
/profile=default/subsystem=jmx/remoting-connector=jmx/:remove
Exemple 3.6. Supprimer le Sous-système JMX
Exécuter cette commande pour chaque profil que vous utilisez, si vous utilisez un domaine géré.
/profile=default/subsystem=jmx/:remove
3.7. Configurer les Domaines de sécurité pour les Interfaces de gestion
Les interfaces de gestion utilisent des domaines de sécurité pour contrôler l'authentification et l'accès aux mécanismes de configuration de JBoss Enterprise Application Platform. Cette section vous montre comment lire et configurer les domaines de sécurité. Ces commandes utilisent le Management CLI.
Lire une configuration de domaine de sécurité
Cet exemple montre la configuration par défaut du domaine de sécurité du ManagementRealm. Utilise un fichier mgmt-users.properties qui contient ses informations de configuration.
Exemple 3.7. ManagementRealm par défaut
/host=master/core-service=management/security-realm=ManagementRealm/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
"outcome" => "success",
"result" => {
"authorization" => undefined,
"server-identity" => undefined,
"authentication" => {"properties" => {
"path" => "mgmt-users.properties",
"plain-text" => false,
"relative-to" => "jboss.domain.config.dir"
}}
}
}
Rédiger un domaine de sécurité
Les commandes suivantes créent un nouveau domaine de sécurité nommé TestRealm et définissent le nom et le répertoire du fichier de propriétés qui conviennent.
Exemple 3.8. Rédaction d'un domaine de sécurité
/host=master/core-service=management/security-realm=TestRealm/:add/host=master/core-service=management/security-realm=TestRealm/authentication=properties/:add(path=TestUsers.properties, relative-to=jboss.domain.config.dir)
Ajouter le Domaine de sécurité à l'interface de gestion
Après avoir ajouté un domaine de sécurité, donner son nom comme référence à l'interface de gestion.
Exemple 3.9. Ajouter un Domaine de sécurité à une interface de gestion
host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
3.8. L'archivage sécurités des mots de passe pour les strings délicats
3.8.1. Sécurisation des chaînes sensibles des fichiers en texte clair
Les applications web et autres déploiements incluent souvent des fichiers en texte clair, comme des descripteurs de déploiement XML, qui comprennent des informations sensibles telles que les mots de passe et autres chaînes sensibles. JBoss Enterprise Application Platform inclut un mécanisme d'archivage sécurisé de mots de passe qui vous permet de crypter les chaînes sensibles et de les stocker dans un keystore chiffré. Le mécanisme d'archivage sécurisé parvient à décrypter les chaînes à utiliser dans les domaines de sécurité, ou autres systèmes de vérification. Ceci fournit une couche supplémentaire de sécurité. Le mécanisme s'appuie sur les outils qui sont inclus dans toutes les implémentations de Java Development Kit (JDK) prises en charge.
3.8.2. Créer un Keystore Java pour stocker des strings sensibles
Prérequis
- La commande
keytooldoit être disponible. Elle est fournie par le Java Runtime Environment (JRE). Chercher le chemin du fichier. Se trouve à l'emplacement suivant/usr/bin/keytooldans Red Hat Enterprise Linux.
Procédure 3.2. Installation du Java Keystore
Créer un répertoire pour stocker votre keystore et autres informations cryptées.
Créer un répertoire qui contiendra votre keystore et autres informations pertinentes. Le reste de cette procédure assume que le répertoire est/home/USER/vault/.Déterminer les paramètres à utiliser avec
keytool.Déterminer les paramètres suivants :- alias
- L'alias est un identificateur unique pour l'archivage sécurisé ou autres données stockées dans le keystore. L'alias dans l'exemple de commande à la fin de cette procédure est
vault(archivage sécurisé). Les alias sont insensibles à la casse. - keyalg
- L'algorithme à utiliser pour le cryptage. La valeur par défaut est
DSA. Dans cette procédure, l'exemple utiliseRSA. Consultez la documentation de votre JRE et de votre système d'exploitation pour étudier vos possibilités. - keysize
- La taille d'une clé de cryptage impacte sur la difficulté de décrypter au seul moyen de la force brutale. La taille par défaut des clés est de 1024. Doit être entre 512 et 1024 et un multiple de 64. Dans cette procédure, l'exemple utilise
1024. - keystore
- Le keystore est une base de données qui contient des informations chiffrées et des informations sur la façon de déchiffrer. Si vous ne spécifiez pas de keystore, le keystore par défaut à utiliser est un fichier appelé
.keystoredans votre répertoire personnel. La première fois que vous ajoutez des données dans un keystore, il sera créé. L'exemple de cette procédure utilise le keystorevault.keystore.
La commande dukeystorea plusieurs options. Consulter la documentation de votre JRE ou de votre système d'exploitation pour obtenir plus d'informations.Détermine les réponses aux questions que la commande
keystorevous demandera.Lekeystorea besoin des informations suivantes pour remplir le keytore :- Mot de passe du keystore
- Lorsque vous créez un keystore, vous devez définir un mot de passe. Pour pouvoir travailler dans keystore dans le futur, vous devez fournir le mot de passe. Créer un mot de passe dont vous vous souviendrez. Le keystore est sécurisé par son mot de passe et par la sécurité du système d'exploitation et du système de fichiers où il se trouve.
- Mot de passe Clé (en option)
- En plus du mot de passe du keystore, vous pouvez indiquer un mot de passe pour chaque clé contenue. Pour utiliser une clé, le mot de passe doit être donné à chaque utilisation. Normalement, cette fonction n'est pas utilisée.
- Prénom et nom de famille
- Cela et le reste de l'information dans la liste aide à identifier la clé de façon unique et à la placer dans une hiérarchie par rapport aux autres clés. N'a pas nécessairement besoin d'être un nom dutout, mais doit être composé de deux mots et doit être unique à une clé. L'exemple dans cette procédure utilise
Accounting Administrator. En termes de répertoires, cela devient le common name (nom commmun) du certificat. - Unité organisationnelle
- Il s'agit d'un mot unique d'identification qui utilise le certificat. Il se peut que ce soit l'application ou l'unité commerciale. L'exemple de cette procédure utilise
enterprise_application_platform. Normalement, tous les keystores utilisés par un groupe ou une application utilisent la même unité organisationnelle. - Organisation
- Il s'agit normalement d'une représentation de votre nom d'organisation en un seul mot. Demeure constant à travers tous les certificats qui sont utilisés par une organisation. Cet exemple utilise
MyOrganization. - Ville ou municipalité
- Votre ville.
- État ou province
- Votre état ou province, ou l'équivalent pour votre localité.
- Pays
- Le code pays en deux lettres.
Ces informations vont créer ensemble une hiérarchie de vos keystores et certificats, qui garantira qu'ils utilisent une structure de nommage consistante, et unique.Exécuter la commande
keytool, fournissant les informations que vous avez collectées.Exemple 3.10. Exemple d'entrée et de sortie de la commande
keystore$ keytool -genkey -alias vault -keyalg RSA -keysize 1024 -keystore /home/USER/vault/vault.keystore Enter keystore password: vault22 Re-enter new password:vault22 What is your first and last name? [Unknown]:
Accounting AdministratorWhat is the name of your organizational unit? [Unknown]:AccountingServicesWhat is the name of your organization? [Unknown]:MyOrganizationWhat is the name of your City or Locality? [Unknown]:RaleighWhat is the name of your State or Province? [Unknown]:NCWhat is the two-letter country code for this unit? [Unknown]:USIs CN=Accounting Administrator, OU=AccountingServices, O=MyOrganization, L=Raleigh, ST=NC, C=US correct? [no]:yesEnter key password for <vault> (RETURN if same as keystore password):
Résultat
Un fichier nommé vault.keystore est créé dans le répertoire /home/USER/vault/. Il stocke une clé simple, nommée vault, qui sera utilisée pour stocker des strings cryptés, comme des mots de passe, pour la plateforme JBoss Enterprise Application Platform.
3.8.3. Masquer le mot de passe du keystore et Initialiser le mot de passe de l'archivage de sécurité
Prérequis
- L'application
EAP_HOME/bin/vault.shdoit pouvoir être accessible via l'interface de ligne de commande.
Exécuter la commande
vault.sh.ExécuterEAP_HOME/bin/vault.sh. Démarrer une nouvelle session interactive en tapant0.Saisir le nom du répertoire où les fichiers cryptés seront stockés.
Ce répertoire doit être raisonnablement sécurisé, mais JBoss Enterprise Application Platform doit pouvoir y accéder. Si vous suivez Section 3.8.2, « Créer un Keystore Java pour stocker des strings sensibles », votre keystore sera dans un répertoire nommévault/dans votre répertoire de base (home). Cet exemple utilise le répertoire/home/USER/vault/.Note
N'oubliez pas d'inclure la barre oblique finale dans le nom du répertoire. Soit/ou\, selon votre système d'exploitation.Saisir le nom de votre keystore.
Saisir le nom complet vers le fichier de keystore. Cet exemple utilise/home/USER/vault/vault.keystore.Crypter le mot de passe du keystore.
Les étapes suivantes vous servent à crypter le mot de passe du keystore, afin que vous puissiez l'utiliser dans les applications et les fichiers de configuration en toute sécuritéSaisir le mot de passe du keystore.
Quand vous y serez invité, saisir le mot de passe du keystore.Saisir une valeur salt.
Entrez une valeur salt de 8 caractères. La valeur salt, ainsi que le nombre d'itérations (ci-dessous), sont utilisés pour créer la valeur de hachageSaisir le nombre d'itérations.
Saisir un nombre pour le nombre d'itérations.Notez les informations de mot de passe masqué.
Le mot de passe masqué, salt et le nombre d'itérations sont imprimés en sortie standard. Prenez en note dans un endroit sûr. Un attaquant pourrait les utiliser pour déchiffrer le mot de passe.Saisir un alias pour l'archivage de sécurité.
Quand on vous y invite, saisir un alias pour l'archivage de sécurité. Si vous suivez Section 3.8.2, « Créer un Keystore Java pour stocker des strings sensibles » pour créer votre archivage de sécurité, l'alias seravault.
Sortir de la console interactive.
Saisir le motexitpour sortir de la console interactive.
Résultat
Votre mot de passe de keystore est masqué afin de pouvoir être utilisé dans les fichiers de configuration et déploiement. De plus, votre archivage de sécurité est complètement configuré et prêt à l'utilisation.
3.8.4. Configurer JBoss Enterprise Application Platform pour qu'il utilise l'archivage sécurisé des mots de passe
Aperçu
Avant de masquer les mots de passe et d'autres attributs sensibles dans les fichiers de configuration, vous devez sensibiliser JBoss Enterprise Application Platform à l'archivage sécurisé des mots de passe qui les stocke et les déchiffre. Actuellement, cela vous oblige à arrêter Enterprise Application Platform et à modifier la configuration directement.
Prérequis
Procédure 3.3. Assigner un mot de passe d'archivage sécurisé.
Déterminer les valeurs qui conviennent pour la commande.
Déterminer les valeurs pour les paramètres suivants, qui sont déterminés par les commandes utilisées pour créer le keystore lui-même. Pour obtenir des informations sur la façon de créer un keystore, voir les sujets suivants : Section 3.8.2, « Créer un Keystore Java pour stocker des strings sensibles » et Section 3.8.3, « Masquer le mot de passe du keystore et Initialiser le mot de passe de l'archivage de sécurité ».Paramètre Description KEYSTORE_URL Le chemin d'accès ou URI du fichier keystore, qui s'appelle normalementvault.keystoreKEYSTORE_PASSWORD Le mot de passe utilisé pour accéder au keystore. Cette valeur devrait être masquée.KEYSTORE_ALIAS Le nom du keystore.SALT Le salt utilisé pour crypter et décrypter les valeurs de keystore.ITERATION_COUNT Le nombre de fois que l'algorithme de chiffrement est exécuté.ENC_FILE_DIR Le chemin d'accès au répertoire à partir duquel les commandes de keystore sont exécutées. Normalement, le répertoire contient les mots de passe sécurisés.hôte (domaine géré uniquement) Le nom de l'hôte que vous configurezUtiliser le Management CLI pour activer les mots de passe sécurisés.
Exécutez une des commandes suivantes, selon que vous utilisiez un domaine géré ou une configuration de serveur autonome. Substituez les valeurs de la commande par celles de la première étape de cette procédure.Domaine géré
/host=YOUR_HOST/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])Serveur autonome
/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])
Ce qui suit est un exemple de la commande avec des valeurs hypothétiques :/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "/home/user/vault/vault.keystore"), ("KEYSTORE_PASSWORD" => "MASK-3y28rCZlcKR"), ("KEYSTORE_ALIAS" => "vault"), ("SALT" => "12438567"),("ITERATION_COUNT" => "50"), ("ENC_FILE_DIR" => "/home/user/vault/")])
Résultat
JBoss Enterprise Application Platform est configurée pour décrypter les strings masqués par l'intermédiaire de l'archivage sécurisé de mots de passe. Pour ajouter des strings à l'archivage sécurisé, et les utiliser dans votre configuration, voir la section suivante : Section 3.8.5, « Stocker et Résoudre des strings sensibles cryptés du Keystore Java. ».
3.8.5. Stocker et Résoudre des strings sensibles cryptés du Keystore Java.
Résumé
En comptant les mots de passe et les autres strings sensibles, les fichiers de configuration en texte brut ne sont pas sécurisés. JBoss Enterprise Application Platform inclut la capacité à stocker et à utiliser les valeurs masquées dans les fichiers de configuration, et d'utiliser ces valeurs masquées dans les fichiers de configuration.
Prérequis
- L'application
EAP_HOME/bin/vault.shdoit pouvoir être accessible via l'interface de ligne de commande.
Procédure 3.4. Installation du Java Keystore
Exécuter la commande
vault.sh.ExécuterEAP_HOME/bin/vault.sh. Démarrer une nouvelle session interactive en tapant0.Saisir le nom du répertoire où les fichiers cryptés seront stockés.
Si vous suivez Section 3.8.2, « Créer un Keystore Java pour stocker des strings sensibles », votre keystore sera dans un répertoire nommévault/de votre répertoire de base. Dans la plupart des cas, il est logique de stocker toutes vos informations cryptées au même endroit dans le keystore. Cet exemple utilise le répertoire/home/USER/vault/.Note
N'oubliez pas d'inclure la barre oblique finale dans le nom du répertoire. Soit/ou\, selon votre système d'exploitation.Saisir le nom de votre keystore.
Saisir le nom complet vers le fichier de keystore. Cet exemple utilise/home/USER/vault/vault.keystore.Saisir le mot de passe du keystore, le nom de l'archivage sécurisé, salt et le nombre d'itérations.
Quand vous y êtes invité, saisir le mot de passe du keystore, le nom de l'archivage sécurisé, salt et le nombre d'itérations.Sélectionner l'option de stockage d'un mot de passe.
Sélectionner l'option0de stockage d'un mot de passe ou autre string sensible.Saisir la valeur.
Une fois que vous y êtes invité, saisir la valeur deux fois. Si les valeurs ne correspondent pas, vous serez invité à essayer à nouveau.Saisir le bloc d'archivage sécurisé.
Saisir le bloc d'archivage sécurisé, qui est un conteneur pour les attributs qui ont trait à la même ressource. Un exemple de nom d'attribut seraitds_ExampleDS. Cela fera partie de la référence à la chaîne cryptée, dans votre source de données ou autre définition de service.Saisir le nom de l'attribut.
Saisir le nom de l'attribut que vous stockez. Exemple de nom d'attributpassword.RésultatUn message comme celui qui suit montre que l'attribut a été sauvegardé.
Valeur de l'attribut pour (ds_ExampleDS, password) sauvegardé
Notez les informations pour ce string crypté.
Un message s'affiche sur la sortie standard, montrant le bloc d'archivage sécurisé, le nom de l'attribut, la clé partagée et des conseils sur l'utilisation du string dans votre configuration. Prendre note de ces informations dans un emplacement sécurisé. Voici un exemple de sortie.******************************************** Vault Block:ds_ExampleDS Attribute Name:password Shared Key:N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0 Configuration should be done as follows: VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0 ********************************************
Utiliser le string crypté dans votre configuration.
Utiliser le string de l'étape de configuration précédente, à la place du string en texte brut. Une source de données utilisant le mot de passe crypté ci-dessus, est montrée ci-dessous.... <subsystem xmlns="urn:jboss:domain:datasources:1.0"> <datasources> <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS"> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url> <driver>h2</driver> <pool></pool> <security> <user-name>sa</user-name> <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password> </security> </datasource> <drivers> <driver name="h2" module="com.h2database.h2"> <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class> </driver> </drivers> </datasources> </subsystem> ...Vous pouvez utiliser un string crypté n'importe où dans votre fichier de configuration autonome ou de domaine pour lequel les expressions sont autorisées.Note
Pour vérifier si les expressions sont utilisées dans un sous-système particulier, exécuter la commande CLI suivante sur ce sous-système :/host=master/core-service=management/security-realm=TestRealm:read-resource-description(recursive=true)
À partir du résultat de cette commande, chercher la valeur du paramètreexpressions-allowed. Si 'true', vous pourrez utiliser des expressions dans la configuration de ce sous-système particulier.Une fois que vous aurez mis votre string dans le keystore, utiliser la syntaxe suivante pour remplacer tout string en texte claire par un texte crypté.${VAULT::<replaceable>VAULT_BLOCK</replaceable>::<replaceable>ATTRIBUTE_NAME</replaceable>::<replaceable>ENCRYPTED_VALUE</replaceable>}Voici un exemple de valeur réelle, où le bloc d'archivage sécurisé estds_ExampleDSet l'attribut estpassword.<password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
3.8.6. Stocker et Résoudre des strings sensibles de vos Applications
Aperçu
Les éléments de configuration de la plate-forme JBoss Application Enterprise prennent en charge la capacité de régler les chaînes cryptés par rapport aux valeurs stockées dans Java Keystore, via le mécanisme Security Vault. Vous pouvez ajouter le support pour cette fonctionnalité à vos propres applications.
Tout d'abord, ajoutez le mot de passe dans votre Security Vault. En second lieu, remplacer le mot de passe de texte clair par celui qui est stocké dans le Security Vault. Vous pouvez utiliser cette méthode pour obscurcir les strings sensibles de votre application.
Prérequis
Avant d'effectuer cette procédure, assurez-vous que le répertoire pour stocker vos fichiers dans le Security Vault existe bien. Qu'importe où vous les placez, tant que l'utilisateur qui exécute JBoss Enterprise Application Platform dispose de l'autorisation de lire et écrire des fichiers. Cet exemple situe le répertoire vault/ dans le répertoire /home/USER/vault/. Le Security Vault lui-même correspond à un fichier nommé vault.keystore qui se trouve dans le répertoire vault/.
Exemple 3.11. Ajout du String Mot de passe au Security Vault
Ajouter le string au Security Vault par la commande
EAP_HOME/bin/vault.sh. La série de commandes et réponses est incluse dans la session suivante. Les valeurs saisies par l'utilisateur apparaîtront clairement. Certaines sorties seront supprimées pour le formatage. Dans Microsoft Windows, le nom de la commande est vault.bat. Notez que dans Microsoft Windows, le chemins d'acccès au fichier utilisent le caractère \ comme séparateur de répertoire, et non pas le caractère /.
[user@host bin]$ ./vault.sh ********************************** **** JBoss Vault ******** ********************************** Please enter a Digit:: 0: Start Interactive Session 1: Remove Interactive Session 2: Exit0Starting an interactive session Enter directory to store encrypted files:/home/user/vault/Enter Keystore URL:/home/user/vault/vault.keystoreEnter Keystore password:...Enter Keystore password again:...Values match Enter 8 character salt:12345678Enter iteration count as a number (Eg: 44):25Enter Keystore Alias:vaultVault is initialized and ready for use Handshake with Vault complete Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit0Task: Store a password Please enter attribute value:saPlease enter attribute value again:saValues match Enter Vault Block:DSEnter Attribute Name:thePassAttribute Value for (DS, thePass) saved Please make note of the following: ******************************************** Vault Block:DS Attribute Name:thePass Shared Key:OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0 Configuration should be done as follows: VAULT::DS::thePass::OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0 ******************************************** Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit2
La chaîne qui sera ajoutée au code Java est la dernière valeur des sortie, la ligne commençant par
VAULT.
Le servlet suivant utilise la chaîne voûtée au lieu d'un mot de passe de texte clair. La version en texte clair est commentée afin que vous puissiez voir la différence.
Exemple 3.12. Servlet qui utilise un mot de passe Vaulted
package vaulterror.web;
import java.io.IOException;
import java.io.Writer;
import javax.annotation.Resource;
import javax.annotation.sql.DataSourceDefinition;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.sql.DataSource;
/*@DataSourceDefinition(
name = "java:jboss/datasources/LoginDS",
user = "sa",
password = "sa",
className = "org.h2.jdbcx.JdbcDataSource",
url = "jdbc:h2:tcp://localhost/mem:test"
)*/
@DataSourceDefinition(
name = "java:jboss/datasources/LoginDS",
user = "sa",
password = "VAULT::DS::thePass::OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0",
className = "org.h2.jdbcx.JdbcDataSource",
url = "jdbc:h2:tcp://localhost/mem:test"
)
@WebServlet(name = "MyTestServlet", urlPatterns = { "/my/" }, loadOnStartup = 1)
public class MyTestServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Resource(lookup = "java:jboss/datasources/LoginDS")
private DataSource ds;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
Writer writer = resp.getWriter();
writer.write((ds != null) + "");
}
}
Votre servlet est maintenant capable de résoudre le string Vaulted.
3.9. LDAP
3.9.1. LDAP
Lightweight Directory Access Protocol (LDAP) est un protocole pour le stockage et la distribution d'informations en provenance de répertoires à travers un réseau. Ces informations de répertoires incluent des informations sur les utilisateurs, les périphériques physiques, les rôles d'accès et de restrictions et autres informations.
Certaines de implémentations communes de LDAP incluent OpenLDAP, Microsoft Active Directory, IBM Tivoli Directory Server, Oracle Internet Directory, et autres.
La plateforme JBoss Enterprise Application Platform comprend plusieurs modules d'authentification et d'autorisation qui vous permettent d'utiliser un serveur LDAP comme autorité d'authentification et d'autorisation pour vos applications Web et EJB.
3.9.2. Utiliser LDAP pour vous authentifier auprès des interfaces de Gestion
Pour utiliser un serveur de répertoire LDAP comme source d'authentification pour la Console de gestion, le Management CLI ou l'API de gestion, vous devez effectuer les procédures suivantes :
- Créer une connexion sortante au serveur LDAP.
- Créer un domaine de sécurité activé-LDAP.
- Référencer le nouveau domaine de sécurité dans l'interface de Gestion.
Créer une Connexion sortante au serveur LDAP
La connexion sortante LDAP autorise les attributs suivants :
Tableau 3.1. Attributs d'une Connexion sortante LDAP
| Attribut | Requis | Description |
|---|---|---|
| Le nom | oui |
Le nom qui sert à identifier cette connexion. Ce nom est utilisé dans la définition du domaine de sécurité.
|
| url | oui |
Ĺ'adresse URL du serveur de répertoires.
|
| search-dn | oui |
Le nom unique (DN) de l'utilisateur autorisé à effectuer des recherches.
|
| search-credentials | oui |
Le mot de passe de l'utilisateur autorisé à effectuer des recherches.
|
| initial-context-factory | non |
L'usine de contexte initiale à utiliser quand on établit une connexion. Valeur par défaut
com.sun.jndi.ldap.LdapCtxFactory.
|
Exemple 3.13. Ajouter une connexion sortante LDAP
Cette exemple ajoute une connexion sortante par le jeu de propriétés suivant :
- Search DN:
cn=search,dc=acme,dc=com - Search Credential:
myPass - URL:
ldap://127.0.0.1:389
/host=master/core-service=management/ldap-connection=ldap_connection/:add(search-credential=myPass,url=ldap://127.0.0.1:389,search-dn="cn=search,dc=acme,dc=com")
Exemple 3.14. XML représentant un connexion sortante LDAP
<outbound-connections> <ldap name="ldap_connection" url="ldap://127.0.0.1:389" search-dn="cn=search,dc=acme,dc=com" search-credential="myPass" /> </outboundconnections>
Créer un domaine de sécurité activé-LDAP
Les Interfaces de gestion peuvent authentifier sur le serveur LDAP au lieu des domaines de sécurité basés propriété-fichier et configurés par défaut. L'authentificateur LDAP fonctionne en établissant tout d'abord une connexion au serveur de répertoires distant. Il effectue ensuite une recherche en utilisant le nom d'utilisateur que l'utilisateur a transmis au système d'authentification, afin de trouver le nom unique complet (DN) du dossier LDAP. Une nouvelle connexion est alors établie, utilisant le DN de l'utilisateur comme informations d'identification et mot de passe fournis par l'utilisateur. Si cette authentification au serveur LDAP réussit, le DN est considéré comme valide.
Le domaine de sécurité LDAP utilise les éléments et attributs de configuration suivants pour pouvoir effectuer ses fonctions.
- connection
- Le nom de la connexion définie dans
<outbound-connections>à utiliser pour se connecter au répertoire LDAP. - base-dn
- Le nom unique (DN) du contexte pour commencer à chercher l'utilisateur.
- recursive
- Indique si la recherche doit être récursive dans toute l'arborescence de répertoires LDAP, ou si l'on doit rechercher uniquement le contexte spécifié. La valeur par défaut est
false. - user-dn
- Attribut de l'utilisateur qui détient le nom unique (DN). Utilisé par la suite pour tester l'authentification. Valeur par défaut
dn. - Soit
username-filterouadvanced-filter, comme élément enfant. - Le
username-filterutilise un attribut unique nomméattribute, dont la valeur correspond au nom de l'attribut LDAP qui contient le nom d'utilisateur, commeuserNameousambaAccountName.Leadvanced-filterprend un attribut unique nomméfilter, qui contient une recherche de filtre en syntaxe LDAP standard. Veillez à bien échapper les caractères&en commutant à& amp;. Un exemple de filtre est :(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))Après avoir échappé un caractère esperluette, le filtre apparaîtra ainsi :(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))
Exemple 3.15. XML représentant un Domaine de sécurité activé-LDAP
Cet exemple utilise les paramètres suivants :
- connection -
ldap_connection - base-dn -
cn=users,dc=acme,dc=com. - username-filter -
attribute="sambaAccountName"
<security-realm name="TestRealm">
<authentication>
<ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com">
<username-filter attribute="sambaAccountName" />
</ldap>
</authentication>
</security-realm>
Avertissement
Il est important de veiller à ne pas autoriser les mots de passe LDAP. À moins que vous désiriez particulièrement les avoir dans votre environnement, ils représentent un problème de sécurité sérieux.
EAP 6.1 inclut un correctif pour CVE-2012-5629, qui définit l'option allowEmptyPasswords des modules de connexion LDAP à false si l'option n'est pas déjà configurée. Pour les versions plus anciennes, cette option devra être configurée manuellement.
Exemple 3.16. Ajout d'un Domaine de sécurité LDAP
La commande ci-dessous ajoute un domaine de sécurité et définit ses attributs pour un serveur autonome.
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap:add(base-dn="DC=mycompany,DC=org", recursive=true, username-attribute="MyAccountName", connection="ldap_connection")
Appliquer le Nouveau domaine de sécurité à l'Interface de gestion
Après avoir créé un domaine de sécurité, vous devez le référencer dans la configuration de votre interface de gestion. L'interface de gestion utilisera le domaine de sécurité pour l'authentification HTTP digest.
Exemple 3.17. Ajouter le Domaine de sécurité à l'interface HTTP
Une fois que la configuration est en place, et que vous aurez démarré à nouveau le contrôleur d'hôtes, la Console de gestion basée-web utilisera LDAP pour authentifier ses utilisateurs.
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
Chapitre 4. Java Security Manager
4.1. Java Security Manager
Java Security Manager
Le gestionnaire de sécurité Java est une classe qui gère la limite extérieure de la sandbox Java Virtual Machine (JVM), contrôlant ainsi comment le code qui est exécuté dans la JVM peut interagir avec les ressources à l'extérieur de la machine virtuelle Java. Lorsque le gestionnaire de sécurité Java est activé, l'API Java vérifie avec le gestionnaire de sécurité pour approbation avant d'exécuter une vaste gamme d'opérations potentiellement dangereuses.
Le Java Security Manager utilise une police de sécurité pour déterminer si une action est permise ou refusée.
4.2. About Java Security Manager Policies
Security Policy
Un jeu d'autorisations définies pour les différentes classes du code. Le gestionnaire de sécurité Java examine les requêtes en provenance des applications en fonction de la politique de sécurité. Si une action est autorisée par la politique, le gestionnaire de sécurité permettra que l'action ait lieu. Si l'action n'est pas autorisée par la police, le gestionnaire de sécurité refusera cette action. La stratégie de sécurité peut définir des autorisations basées sur l'emplacement du code ou sur la signature du code.
Le Java Security Manager et la police de sécurité utilisés sont configurés à l'aide des options Java Virtual Machine
java.security.manager et java.security.policy.
4.3. Exécuter JBoss Enterprise Application Platform dans le Java Security Manager (gestionnaire de sécurité Java)
Pour spécifier une police de gestionnaire de sécurité Java, vous devez modifier les options Java transmises à l'instance de serveur ou de domaine lors du processus d'amorçage. Pour cette raison, vous ne pouvez passer les paramètres en option aux scripts
domain.sh or standalone.sh. La procédure suivante va vous guider à travers les étapes de configuration de votre instance pour exécuter avec la police du gestionnaire de sécurité Java.
Prérequis
- Avant de suivre cette procédure, vous devrez rédiger une politique de sécurité, en utilisant la commande
policytoolcomprise dans votre Java Development Kit (JDK). Cette procédure assume que votre police se trouve àEAP_HOME/bin/server.policy. - Le domaine ou le serveur autonome doivent être tout à fait arrêtés avant d'éditer un fichier de configuration quelconque.
Procéder à la procédure suivante pour chaque hôte physique ou instance de votre domaine, si vous avez des membres de domaine éparpillés dans des systèmes multiples.
Procédure 4.1. Modifier les Fichiers de configuration
Ouvrir le fichier de configuration.
Ouvrir le fichier de configuration pour le modifier. Ce fichier se trouve dans un de ces emplacements, suivant que vous utilisiez un domaine géré ou un serveur autonome. Il ne s'agit pas du fichier exécutable utilisé pour démarrer le serveur ou le domaine.Domaine géré
EAP_HOME/bin/domain.confServeur autonome
EAP_HOME/bin/standalone.conf
Ajouter les options Java en fin de fichier.
Ajouter la ligne suivante sous forme de nouvelle ligne en fin de fichier. Vous pourrez modifier la valeur de-Djava.security.policypour spécifier l'emplacement exact de votre police de sécurité. Doit être contenu sur une ligne seulement, sans interruption. Vous pouvez modifier-Djava.security.debugpour journaliser des information, en indiquant leur niveau de débogage. La plus verbeuse estfailure,access,policy.JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djboss.home.dir=$PWD/.. -Djava.security.policy==$PWD/server.policy -Djava.security.debug=failure"
Démarrer le domaine ou le serveur.
Démarrer le domaine ou le serveur en tant que normal.
4.4. Écrire une police pour le Java Security Manager
Introduction
Il y a une application nommée policytool dans la plupart des distributions JDK et JRE, ayant pour but la modification ou la création de polices de sécurité pour le Java Security Manager. Vous trouverez des informations sur policytool dans http://docs.oracle.com/javase/6/docs/technotes/tools/.
Informations de base
Une police de sécurité consiste en les éléments de configuration suivants :
- CodeBase
- L'emplacement de l'URL (à l'exclusion des informations sur l'hôte ou le domaine) d'où viennent les codes. Ce paramètre est en option.
- SignedBy
- L'alias est utilisé dans le fichier de clés pour référencer le signataire dont la clé privée a été utilisée pour signer le code. Cela peut être une valeur unique ou une liste séparée par des virgules. Ce paramètre est facultatif. Si omis, la présence ou l'absence de signature n'a aucun impact sur le gestionnaire de sécurité Java.
- Principaux
- Une liste de paires de principal_type/principal_name, qui doivent se trouver dans l'ensemble Principal du thread en cours d'exécution. L'entrée Principal est facultative. S'il est omis, il signifie « n'importe quel principal »
- Permissions
- Une permission est l'accès qui est accordé au code. De nombreuses autorisations sont fournies dans le cadre de la spécification Java Enterprise Edition 6 (Java EE 6). Ce document couvre uniquement les autorisations supplémentaires qui sont fournies par JBoss Enterprise Application Platform.
Procédure 4.2. Définir une police pour le Java Security Manager
Démarrer
policytool.Démarrer l'outilpolicytoold'une des façons suivantes.Red Hat Enterprise Linux
À partir de votre GUI ou invite de commande, exécuter/usr/bin/policytool.Microsoft Windows Server
Exécuterpolicytool.exeà partir du menu de Démarrage (Start) ou à partir debin\de votre installation Java. L'emplacement peut varier.
Créer une nouvelle police.
Pour créer une nouvelle police, sélectionner . Ajouter les paramètres dont vous aurez besoin, et cliquer sur .Modifier une police existante
Sélectionner la police à partir d'une liste de polices existantes, et sélectionner le bouton . Modifier les paramètres suivant les besoins.Supprimer une police existante.
Sélectionner la police à partir d'une liste de polices existantes, et sélectionner le bouton .
Permission spécifique à JBoss Enterprise Application Platform
- org.jboss.security.SecurityAssociation.getPrincipalInfo
- Donne accès aux méthodes
org.jboss.security.SecurityAssociationgetPrincipal()etgetCredential(). Le risque encouru avec cette permission est que l'on peut voir le thread de l'appelant et ses détails d'authentification. - org.jboss.security.SecurityAssociation.getSubject
- Donne accès à la méthode
org.jboss.security.SecurityAssociationgetSubject(). - org.jboss.security.SecurityAssociation.setPrincipalInfo
- Donne accès aux méthodes
org.jboss.security.SecurityAssociationsetPrincipal(),setCredential(),setSubject(),pushSubjectContext(), etpopSubjectContext(). Le risque encouru avec cette permission est que l'on peut voir le thread de l'appelant et ses détails d'authentification. - org.jboss.security.SecurityAssociation.setServer
- Donne accès aux méthodes
org.jboss.security.SecurityAssociationsetPrincipal(). Le risque encouru avec cette permission est que l'on peut activer ou désactiver le stockage multi-thread de l'appelant principal et ses détails d'authentification. - org.jboss.security.SecurityAssociation.setRunAsRole
- Donne accès aux méthodes
org.jboss.security.SecurityAssociationpushRunAsRole,popRunAsRole,pushRunAsIdentity, etpopRunAsIdentity. Le risque encouru avec cette permission est que l'on peut voir le thread de l'appelant et ses détails d'authentification. - org.jboss.security.SecurityAssociation.accessContextInfo
- Donne accès aux méthodes
org.jboss.security.SecurityAssociationaccessContextInfo, etaccessContextInfo. Cela vous permet les actions set et get pour définir et obtenir les informations de sécurité. - org.jboss.naming.JndiPermission
- Fournit des permissions spéciales pour les fichiers et répertoires d'un chemin d'accès JNDI spécifié, ou bien de façon récursive pour tous les fichiers et sous-répertoires. Une JndiPermission consiste en un nom de chemin et un ensemble de permissions valides liées au fichier ou répertoire.Les permissions disponibles sont les suivantes :
- bind
- rebind
- unbind
- lookup
- list
- listBindings
- createSubcontext
- all
Les noms de chemin d'accès se terminant par/*indiquent que les permissions indiquées s'appliquent à tous les fichiers et répertoires de nom du chemin. Les noms de chemin se terminant par/-indiquent des permissions récursives vers tous les fichiers et sous-directoires du nom du chemin. Les noms de chemins consistants avec le token <<ALL BINDINGS>> correspondent à n'importe quel fichier du répertoire. - org.jboss.security.srp.SRPPermission
- Une classe de permissions personnalisées pour protéger l'accès à des informations sensibles SRP comme la clé de session privée et la clé privée. Cette autorisation n'a pas toutes les actions définies. La cible de
getSessionKeydonne accès à la clé de session privée qui résulte de la négociation SRP. L'accès à cette clé permet de chiffrer et de déchiffrer les messages qui ont été chiffrés avec la clé de session. - org.hibernate.secure.HibernatePermission
- Cette classe de permissions fournit des permissions de base pour sécuriser les sessions Hibernate. La cible de cette propriété est le nom de l'entité. Les actions disponibles sont les suivantes :
- insérer
- supprimer
- update
- lecture
- * (all)
- org.jboss.metadata.spi.stack.MetaDataStackPermission
- Fournit une classe de permission personnalisée pour contrôler la façon dont les appelants interagissent avec la pile de métadonnées. Les permissions disponibles sont les suivantes :
- modifer
- push (vers la pile)
- pop (de la pile)
- peek (dans la pile)
- * (all)
- org.jboss.config.spi.ConfigurationPermission
- Sécurise la mise en place des propriétés de configuration. Définit uniquement les noms des cibles, mais aucune action. Les cibles pour cette propriété incluent :
- <property name> (la propriété que ce code a la permission de définir)
- * (all properties)
- org.jboss.kernel.KernelPermission
- Sécurise l'accès à la configuration du noyau. Définit uniquement les noms des cibles, mais aucune action. Les cibles pour cette propriété incluent :
- access (à la configuration du noyau)
- configure (implique accès)
- * (all)
- org.jboss.kernel.plugins.util.KernelLocatorPermission
- Sécurise l'accès au noyau. Définit uniquement les noms des cibles, mais aucune action. Les cibles pour cette propriété incluent :
- noyau
- * (all)
4.5. Débogage des polices du gestionnaire de sécurité
Vous pouvez activer les informations de débogage pour vous aider à résoudre les problèmes liés aux polices de sécurité. L'option
java.security.debug configure le niveau des informations liées à la sécurité qui ont été reportées. La commande java -Djava.security.debug=help vous produira l'assistance avec l'ensemble complet des options de débogage. Définir le niveau de débogage à all est utile quand on résout un échec lié à la sécurité dont la cause est inconnue, mais en général, cela produit trop d'informations. Une valeur par défaut utile et raisonnable est access:failure.
Procédure 4.3. Activer le débogage général
Cette procédure permettra un bon niveau de sécurité général pour les informations de débogage liées à la sécurité.
Ajouter la ligne suivante au fichier de configuration du serveur.- Si l'instance de JBoss Enterprise Application Platform exécute sur une domaine géré, la ligne sera ajoutée au fichier
bin/domain.confde Linux ou au fichierbin/domain.conf.batde Windows. - Si l'instance de JBoss Enterprise Application Platform exécute sur une domaine autonome, la ligne sera ajoutée au fichier
bin/standalone.confde Linux ou au fichierbin/standalone.conf.batde Windows.
Linux
JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
Windows
JAVA_OPTS="%JAVA_OPTS% -Djava.security.debug=access:failure"
Résultat
Un niveau général d'informations de débogage lié à la sécurité a été activé.
Chapitre 5. Installation de correctif
5.1. Mécanismes de correction
Les correctifs de bogues et de sécurité JBoss sont disponibles sous deux formes.
- Mises à jour planifiées: faisant partie d'une mise à jour micro, mineure, ou majeure d'un produit existant.
- Mises à jour non synchronisées: correctif exceptionnel délivré en dehors du cycle de mise à jour normal d'un produit existant.
La décision de savoir si un patch doit sortir dans le cadre d'une mise à jour planifiée ou un s'il doit s'agir d'un One-Off hors cycle dépend de la sévérité de la faille. Les défauts de faible impact sont généralement reportés, et sont résolus dans la prochaine version mineure des produits concernés. Les défauts d'impact modéré ou supérieur sont généralement traités par ordre d'importance sous forme de mise à jour de produit lors d'une sortie asynchrone et contiennent seulement une résolution du problème particulier.
La sévérité d'un défaut de sécurité est basée sur l'évaluation du bogue par l'équipe Security Response Team de Red hat, en combinaison à un certain nombre de facteurs consistants :
- Est-ce que le défaut peut être exploité facilement ?
- Quel sorte de dégât peut avoir lieu en cas d'exploitation du défaut ?
- Y a t-il d'autres facteurs typiques impliqués qui pourraient diminuer la force de l'impact du défaut (comme les pare-feux, Security-Enhanced Linux, des directives de compilateurs, etc)?
Red Hat maintient une liste de distribution pour notifier les abonnés à propos des défauts liés à la sécurité. Voir Section 5.2, « Abonnez-vous aux Listes de diffusion de correctifs (Patch Mailing Lists) »
Pour obtenir plus d'informations sur la façon dont Red Hat évalue les défauts de JBoss Security, veuillez cliquer sur le lien suivant : http://securityblog.redhat.com/2012/09/19/how-red-hat-rates-jboss-security-flaws/
5.2. Abonnez-vous aux Listes de diffusion de correctifs (Patch Mailing Lists)
Résumé
L'équipe JBoss de Red Hat maintient une liste de diffusion pour les annonces de sécurité pour les produits Red Hat JBoss Enterprise Middleware. Cette section couvre ce que vous devez faire pour vous abonner à cette liste.
Prérequis
- Aucun
Procédure 5.1. Abonnez-vous à JBoss Watch List
- Cliquer sur le lien suivant pour vous rendre sur la page de la liste de diffusion JBoss Watch: JBoss Watch Mailing List.
- Saisir votre adresse email dans la section Subscribing to Jboss-watch-list.
- [Vous pourrez également saisir votre nom et sélectionner un mot de passe. Ceci est tout à fait optionnel, mais conseillé.]
- Cliquer sur le bouton pour démarrer le processus d'abonnement.
- Vous pouvez naviguer les archives de la liste de diffusion en vous rendant à: JBoss Watch Mailing List Archives.
Résultat
Une fois que votre compte email aura été confirmé, vous pourrez recevoir des communiqués liés à la sécurité de la liste de diffusion JBoss patch (Correctifs JBoss).
5.3. Installer des correctifs en Zip
Résumé
Les correctifs de sécurité JBoss sont distribués de deux façons: zip (pour tous les produits) et RPM (pour un sous ensemble de produits). JBoss bug traite les correctifs distribués en format zip uniquement. Cette tâche décrit les étapes à prendre pour installer les correctifs (sécurité ou bogues) via zip.
Prérequis
- Accès valide et abonnement au Portail Clients de Red Hat.
- Un abonnement en cours à un produit JBoss installé en format zip.
Procédure 5.2. Appliquer un correctif à un produit JBoss via la méthode zip
Les mises à jour de sécurité pour les produits de JBoss sont fournis par un erratum (pour les zip et les méthodes RPM). L'erratum comprend une liste de défauts résolus, leurs indices de gravité, les produits concernés, une description textuelle des défauts et une référence de correctifs. Les mises à jour de correction de bogues sont annoncées par un erratum.
Pour les distributions de produits JBoss zip, l'errata inclut un lien vers un URL sur le Portail clients où le zip de correctifs peut être téléchargé. Ce téléchargement contient des versions de produits existants de JBoss corrigées et inclut uniquement les fichiers qui ont été modifiés par rapport à l'installation précédente.
Avertissement
Avant d'installer un correctif, vous devrez sauvegarder votre produit JBoss avec tous les fichiers de configuration personnalisés.
- Recevez vos notifications de correctifs de sécurité soit en tant qu'abonné de la liste de diffusion JBoss watch ou en parcourant les archives de la liste de diffusion de JBoss watch.
Note
Seuls les correctifs de sécurité sont annoncés sur la liste de diffusion JBoss watch. - Lire l'errata du correctif de sécurité et confirmer qu'elle s'applique bien à un produit JBoss de votre environnement.
- Si le correctif de sécurité s'applique à un produit JBoss de votre environnement, alors suivez le lien pour télécharger le correctif du Portail Clients de Red Hat.
- Le fichier zip téléchargeable à partir du Portail Clients contiendra tous les fichiers requis pour résoudre le problème de sécurité ou un bogue. Télécharger ce fichier zip de correctifs dans le même emplacement que votre produit JBoss.
- Décompresser le fichier de correctifs dans le même emplacement où le produit JBoss est installé. Les versions corrigées remplacent les fichiers existants.
Résultat
Le produit JBoss est corrigé par la dernière mise à jour en format zip.
5.4. Installer des correctifs en RPM
Résumé
Les correctifs de sécurité JBoss sont distribués de deux façons: zip (pour tous les produits) et RPM (pour un sous ensemble de produits). Cette tâche décrit les étapes nécessaires pour installer les correctifs en format RPM. La méthode de mise à jour RPM est utilisée pour diffuser des correctifs de sécurité asynchrones et des mises à jour macro/mineur/majeur de produits uniquement.
Prérequis
- Un abonnement RHN valide.
- Un abonnement en cours à un produit JBoss installé via un package RPM.
Procédure 5.3. Appliquer un patch à un produit JBoss via méthode RPM
Les mises à jour de sécurité pour les produits de JBoss sont fournis par un erratum (pour les zip et les méthodes RPM). L'erratum comprend une liste de défauts résolus, leurs indices de gravité, les produits concernés, une description textuelle des défauts et une référence de correctifs.
Pour les distributions RPM de produits JBoss, l'errata inclut des références aux packages RPM mis à jour. Le correctif peut être installé par yum ou autre outil RPM afin de mettre à jour les packages qui conviennent.
Avertissement
Avant d'installer un correctif, vous devrez sauvegarder votre produit JBoss avec tous les fichiers de configuration personnalisés.
- Recevez vos notifications de correctifs de sécurité soit en tant qu'abonné de la liste de diffusion JBoss watch ou en parcourant les archives de la liste de diffusion de JBoss watch.
- Lire l'errata du correctif de sécurité et confirmer qu'elle s'applique bien à un produit JBoss de votre environnement.
- Si le correctif de sécurité s'applique à un produit JBoss de votre environnement, alors suivez le lien pour télécharger le package RPM mis à jour qui contient l'errata.
- Utilisation
ou commande similaire pour installer le correctif.yum update
Résultat
Le produit JBoss est corrigé par la dernière mise à jour en format RPM.
5.5. Évaluation de la gravité et de l'impact des correctifs JBoss Security
Pour communiquer le risque de chaque faille de sécurité de JBoss, Red Hat utilise une échelle de gravité à quatre niveaux: faible, modéré, important et critique, en plus les scores de base de vulnérabilité CVSS version 2, qui peuvent être utilisés pour identifier l'impact de la faille.
Tableau 5.1. Système d'évaluation de gravité de JBoss Security Patches (Correctifs de sécurité JBoss)
| Gravité | Description |
|---|---|
| Critique |
Ce score est donné aux failles pouvant être facilement exploitées par un attaquant non authentifié à distance et conduire à des compromis de système (exécution de code arbitraire) sans intervention de la part de l'utilisateur. Ce sont les types de vulnérabilités pouvant être exploitées par des vers informatiques. Il s'agit de failles nécessitant un utilisateur distant authentifié, un utilisateur local ou une configuration peu probable ne sont pas classées comme impact critique.
|
| Important |
Ce score est donné aux failles qui peuvent facilement compromettre la confidentialité, l'intégrité ou la disponibilité des ressources. Ce sont les types de vulnérabilités qui permettent à des utilisateurs locaux d'obtenir des privilèges, qui permettent à des utilisateurs distants non authentifiés d'afficher des ressources qui devraient normalement être protégées par une authentification, qui permettent à des utilisateurs authentifiés distants d'exécuter du code arbitraire, ou d'autoriser des utilisateurs locaux ou distants de causer un déni de service.
|
| Modéré |
Ce score est donné aux failles qui risquent d'être plus difficiles à exploiter mais qui peuvent toujours résulter en compromis de confidentialité, d'intégrité, et disponibilité de ressources, sous certaines circonstances. Ce sont les types de vulnérabilités qui auraient pu avoir un impact critique ou un impact important, mais pouvant être moins facilement exploités selon une évaluation technique de la faille, ou qui risquent moins d'affecter les configurations.
|
| Moindre |
Ce score est donné à toutes les autres questions qui ont un impact de sécurité. Ce sont les types de vulnérabilités qui semblent liées à des circonstances improbables pour pouvoir être exploitées, ou dans les cas ou l'exploitation de la faille aurait des conséquences minimes.
|
Le composant de l'impact d'un score CVSS v2 repose sur une évaluation combinée des trois impacts potentiels : confidentialité (C), intégrité (I) et disponibilité (A). Chacun d'entre eux peut être évalué comme aucun (N), partiel (P) ou total (C).
Comme le process de serveur JBoss exécute en tant qu'utilisateur non privilégié et est isolé du système d'exploitation hôte, les failles de sécurité de JBoss ne peuvent avoir comme score d'impact que N (aucun), P (partiel).
Exemple 5.1. CVSS v2 Impact Score
L'exemple ci-dessous vous montre un score d'impact CVSS v2, quand l'exploitation d'une faille n'a aucun impact sur la confidentialité du système, un impact partiel sur l'intégrité, et un impact total sur la disponibilité du système (c-a-d que le système est rendu indisponible, par exemple, suite à un crash de noyau).
C:N/I:P/A:C
Grâce à l'indice de gravité du score et du score CVSS, les organisations peuvent prendre des décisions informées sur le risque que chaque problème pose à leur environnement et à leur programmation de mises à jours respectives.
Pour davantage d'informations sur CVSS2, veuillez consulter : CVSS2 Guide.
Chapitre 6. Domaines de sécurité
6.1. Les domaines de sécurité
Les domaines de sécurité font partie du sous-système de sécurité JBoss Enterprise Application Platform. La configuration de la sécurité est désormais gérée de façon centralisée, ou par le contrôleur de domaine d'un domaine géré ou par le serveur autonome.
Un domaine de sécurité se compose de configurations d'authentification, d'autorisation, de mappage de sécurité et d'audit. Il met en place la sécurité déclarative Java Authentication and Authorization Service (JAAS).
L'authentification est impliquée dans la vérification de l'identité d'un utilisateur. Dans la terminologie de la sécurité, cet utilisateur est appelé un principal. Bien que l'authentification et l'autorisation soient différentes, de nombreux modules d'authentification intégrés gèrent également l'autorisation.
Une authorization est une police de sécurité, qui contient des informations sur les actions qui sont autorisées ou interdites. Dans la teminologie de sécurité, on parle de «rôle».
Security mapping se rapporte à la possibilité d'ajouter, de modifier ou de supprimer des informations d'un principal, rôle ou attribut avant de passer les informations à votre application.
L'Auditing Manager vous permet de configurer les provider modules pour contrôler la façon dont les événements de sécurité sont rapportés.
Si vous utilisez des domaines de sécurité, vous pouvez supprimer toutes les configurations de sécurité spécifiques de votre application proprement dite. Cela permet de modifier les paramètres de sécurité de façon centralisée. Un scénario courant qui bénéficie de ce type de structure de configuration est le processus de déplacement des applications entre les environnements de test et de production.
6.2. Picketbox
Picketbox est le cadre de sécurité de base qui fournit l'authentification, l'autorisation, la vérification et des fonctions de mappage à des applications Java exécutant dans JBoss Enterprise Application Platform. Il fournit les fonctions suivantes, dans un cadre unique avec une configuration simple :
- Section 6.5, « L'autorisation » et contrôle d'accès
- Section 6.9, « Security Mapping » des principaux, rôles et attributs
6.3. Authentification
L'authentification consiste à identifier un sujet et à vérifier l'authenticité de l'identification. Le mécanisme d'authentification le plus commun est une combinaison de nom d'utilisateur et de mot de passe. D'autres mécanismes d'authentification communs utilisent des clés partagées, des smart cards (cartes à puce) ou des empreintes digitales. Le résultat d'une authentification à succès s'appelle un Principal, en termes de sécurité déclarative Java Enterprise Edition.
JBoss Enterprise Application Platform utilise un système pouvant se connecter à des modules d'authentification en vue de flexibilité et d'intégration avec les systèmes d'authentification que vous utilisez dans votre organisation. Chaque domaine de sécurité contient un ou plusieurs modules d'authentification configurés. Chaque module comprend des paramètres de configuration supplémentaires pour personnaliser son comportement. Le plus simple consiste à configurer le sous-système d'authentification dans la console de gestion web.
L'authentification n'est pas le même chose que l'autorisation, même si elles sont souvent liées. Bon nombre des modules d'authentification intégrés peuvent également gérer des autorisations.
6.4. Configurer l'authentification dans un Domane de sécurité
Pour configurer les paramètres d'authentification d'un domaine de sécurité, connectez-vous dans la console de gestion et suivre la procédure suivante :
Procédure 6.1. Configurer l'authentification dans un Domane de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité
Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine géré, sélectionner le profile à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichge du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.Naviguer dans la configuration du sous-système d'authentification.
Cliquer sur l'étiquette Authentification en haut de l'affichage s'il n'a pas déjà été sélectionné.La zone de configuration est divisée en deux : Login Modules et Details. Le module de connexion est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices d'autorisation, et chacune peut inclure plusieurs attributs et options.Ajouter un module de connexion
Cliquer sur le bouton Add pour ajouter un module de police d'authentification JAAS. Remplir les informations pour votre module. Le Code est le nom de classe de votre module. Les Flags contrôlent la façon dont le module est lié à d'autres modules de polices d'authentification du même domaine de sécurité.Explication des indicateursLa spécification Java Enterprise Edition 6 fournit l'explication suivante sur les marqueurs des modules de sécurité. La liste suivante provient de http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Consulter ce document pour obtenir des informations plus détaillées.
Marqueur Détails Requis Le LoginModule est requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.Pré-requis Le LoginModule est requis pour la réussite. En cas de succès, l'authentification continue vers le bas de la liste LoginModule. En cas d'échec, le contrôle est renvoyé immédiatement à l'application (l'authentification ne continue pas son chemin le long de la liste LoginModule).Suffisant Le LoginModule n'est pas nécessaire pour aboutir. S'il ne réussit pas, le contrôle retourne immédiatement à l'application (l'authentification ne se déroule pas vers le bas de la liste LoginModule). S'il échoue, l'authentification se poursuit vers le bas de la liste LoginModule.Option Le LoginModule n'est pas requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Flags (indicateurs) en cliquant sur le bouton dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Option: ajouter, éditer, ou supprimer un module
Si vous avez besoin d'ajouter des options à votre module, cliquer sur leurs entrées dans la liste Login Modules, et sélectionner l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquer sur le bouton , et fournir la clé et la valeur de l'option. Pour la modifier, cliquer sur la clé et modifier. Utiliser le bouton pour supprimer l'option.
Résultat
Votre module d'authentification est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.
L'option de module
jboss.security.security_domain
Par défaut, chaque module de connexion défini dans un domaine de sécurité a l'option de module jboss.security.security_domain ajoutée automatiquement. Cette option cause des problèmes avec les modules de connexion, qui vérifient que seules les options connues soient définies. Le module de connexion Kerberos d'IBM com.ibm.security.auth.module.Krb5LoginModule est l'une d'entre elles.
Vous pouvez désactiver le comportement d'ajout de cette option de module, en définissant la propriété de système à
true en démarrant la plate-forme JBoss Enterprise Application Platform. Ajouter ce qui suit pour démarrer les paramètres.
-Djboss.security.disable.secdomain.option=true
Vous pourrez également définir cette propriété par la Console de gestion. Dans un serveur autonome, vous pouvez définir les propriétés de système dans la section Profile de configuration. Dans un domaine géré, vous pouvez définir les propriétés du système pour chaque groupe de serveur.
6.5. L'autorisation
L'autorisation est un mécanisme d'octroi ou de refus de permission d'accéder à une ressource, basé sur l'identité. Ce mécanisme est implémenté sous forme de rôles de sécurité déclarative, qui peuvent être donnés à des principaux.
JBoss Enterprise Application Platform utilise un système modulaire pour configurer l'autorisation. Chaque domaine de sécurité peut contenir une ou plusieurs stratégies d'autorisation. Chaque stratégie possède un module de base qui définit son comportement. Il est configuré via les attributs et indicateurs spécifiques. La façon la plus simple consiste à configurer le sous-système de l'autorisation à l'aide de la console de gestion basée web.
L'authentification est différente de l'autorisation, et a lieu, en général, après l'authentification. La plupart des modules d'authentification gèrent également l'autorisation.
6.6. Configurer l'autorisation pour un domaine de sécurité
Pour configurer les paramètres d'un domaine de sécurité, connectez-vous à la console de gestion et suivre la procédure suivante :
Procédure 6.2. Configurer l'autorisation pour un domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité
Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine géré, sélectionner le profil à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.Naviguer dans la configuration du sous-système d'autorisation.
Cliquer sur l'étiquette Authorization en haut de l'affichage sil elle n'a pas déjà été sélectionnée.La zone de configuration est divisée en deux : Policies et Details. Le module de connexion est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices d'autorisation, et chacune d'elle peut inclure plusieurs attributs ou options.Ajouter une police.
Cliquer sur le bouton Add pour ajouter un module de police d'autorisation JAAS. Remplir les informations pour votre module. Le Code est le nom de classe de votre module. Les Flags contrôlent la façon dont le module est lié à d'autres modules de polices d'autorisation du même domaine de sécurité.Explication des indicateursLa spécification Java Enterprise Edition 6 fournit l'explication suivante sur les marqueurs des modules de sécurité. La liste suivante provient de http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Consulter ce document pour obtenir des informations plus détaillées.
Marqueur Détails Requis Le LoginModule est requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.Pré-requis Le LoginModule est requis pour la réussite. En cas de succès, l'autorisation continue vers le bas de la liste LoginModule. En cas d'échec, le contrôle est renvoyé immédiatement à l'application (l'autorisation ne continue pas son chemin le long de la liste LoginModule).Suffisant Le LoginModule n'est pas nécessaire pour aboutir. S'il ne réussit pas, le contrôle retourne immédiatement à l'application (l'autorisation ne se déroule pas vers le bas de la liste LoginModule). S'il échoue, l'authentification se poursuit vers le bas de la liste LoginModule.Option Le LoginModule n'est pas requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Flags (indicateurs) en cliquant sur le bouton dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Option: ajouter, éditer, ou supprimer un module
Si vous avez besoin d'ajouter des options à votre module, cliquer sur leurs entrées dans la liste Login Modules, et sélectionner l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquer sur le bouton , et fournir la clé et la valeur de l'option. Pour la modifier, cliquer sur la clé et modifier. Utiliser le bouton pour supprimer l'option.
Résultat
Votre module de police de sécurité est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.
6.7. Security Auditing
Security Auditing se réfère au déclenchement d'événements, comme écrire un blog en réponse à un événement qui a lieu dans le sous-système de sécurité. Les mécanismes de sécurité sont configurés dans le cadre du domaine de sécurité, avec les informations d'authentification, d'autorisation ou de mappage de sécurité.
Auditing utilise des modules de fournisseur. Vous pouvez en utiliser un existant ou bien créer le vôtre.
6.8. Configurer Security Auditing
Pour configurer les paramètres de Security Auditing, connectez-vous à la console de gestion et suivre la procédure suivante :
Procédure 6.3. Configurer Security Auditing pour un domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité
Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine autonome, l'onglet est intitulé Profile. Dans un domaine géré, sélectionner le profil à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.Naviguer dans la configuration du sous-système Auditing.
Cliquer sur l'étiquette Audit en haut de l'affichage si elle n'a pas déjà été sélectionnée.La zone de configuration est divisée en deux : Provider Modules et Details. Le module de fournisseur est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices d'autorisation, et chacune peut inclure plusieurs attributs et options.Ajouter un module de fournisseur.
Cliquer sur le bouton Add pour ajouter un module de fournisseur. Remplir la section Code avec le nom de classe du module du fournisseur.Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code en cliquant sur le bouton dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Vérifier que le module fonctionne
Le but d'un module d'auditing est d'offrir un moyen de surveiller les événements dans le sous-système de sécurité. Ce monitoring peut être réalisé sous la forme d'écriture dans un fichier de journalisation, des notifications email ou autre mécanisme d'audit mesurable.Par exemple, JBoss Enterprise Application Server inclut le moduleLogAuditProviderpar défaut. S'il est activé par les étapes décrites ci-dessus, ce module d'audit écrira des notifications de sécurité dans un fichieraudit.logqui se situe dans le sous-dossierlogdu répertoireEAP_HOME.Pour vérifier si les étapes ci-dessus fonctionnent dans le contexteLogAuditProvider, procédez à une action qui risque de déclencher une notification, puis vérifier le fichier de journalisation de l'audit.Pour obtenir une liste complète des Modules Security Auditing Provider, voir : Section A.4, « Modules de fournisseurs d'auditing de sécurité inclus »Option: ajouter, éditer, ou supprimer un module
Si vous avez besoin d'ajouter des options à votre module, cliquer sur leurs entrées dans la liste Modules, et sélectionner Module Options, dans la section Details qui se trouve en bas de la page. Cliquer sur le bouton , et fournir la clé et la valeur de l'option. Pour modifier une option existante, supprimez-là en cliquant sur l'étiquette , et ajoutez-la à nouveau grâce aux options qui conviennent en cliquant le bouton .
Résultat
Votre module d'auditing de sécurité est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.
6.9. Security Mapping
Le mappage de sécurité vous permet de combiner l'authentification et l'autorisation d'informations après que l'authentification ou l'autorisation aient eu lieu, mais avant que l'information ait été passée à votre application. Un exemple qui l'illustre est l'utilisation d'un certificat X509 pour l'authentification, puis la conversion du principal du certificat en nom logique que votre application puisse afficher.
Vous pouvez mapper vos principaux (authentification), rôles (autorisation), ou identifiants (attributs qui ne sont ni principaux, ni rôles).
Le mappage de rôles est utilisé pour ajouter, remplacer ou supprimer des rôles du sujet après l'authentification.
Le mappage du principal est utilisé pour modifier un principal après l'authentification.
Le mappage d'attributs est utilisé pour convertir des attributs d'un système externe à utiliser par votre application, et vice versa.
6.10. Configurer le Security Mapping dans un domaine de sécurité
Pour configurer les paramétres de Sécurity Mapping, connectez-vous à la console de gestion et suivre la procédure suivante :
Procédure 6.4. Configurer le Mappage de sécurité pour un Domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité.
Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine autonome, l'onglet est intitulé Profile. Dans un domaine géré, sélectionner le profile à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.Naviguer dans la configuration du sous-système de Mapping
Cliquer sur l'étiquette Mapping en haut de l'affichage si elle n'a pas déjà été sélectionnée.La zone de configuration est divisée en deux : Modules et Details. Le module de connexion est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices de mapping, et chacune peut inclure plusieurs attributs et options.Ajouter un module.
Cliquer sur le bouton Add pour ajouter un module de police de mapping. Remplir les informations pour votre module. Le Code est le nom de classe du module. Le champ Type se rapporte au type de mapping effectué par ce module. Les valeurs autorisées sont les suivantes : principal, rôle, attribut ou identifiant.Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Type en cliquant sur le bouton dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Option: ajouter, éditer, ou supprimer un module
Si vous avez besoin d'ajouter des options à votre module, cliquer sur leurs entrées dans la liste Modules, et sélectionner l'onglet Module Options dans la section Details. Cliquer sur le bouton , et fournir la clé et la valeur de l'option. Pour modifier une option existante, supprimez-là en cliquant sur l'étiquette Remove, et ajouter la nouvelle valeur. Utiliser le bouton pour supprimer une option.
Résultat
Votre module de mappage de sécurité est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.
Chapitre 7. Cryptage SSL
7.1. Cryptage SSL
SSL (Secure Sockets Layer) crypte le trafic réseau entre deux systèmes. Le trafic entre les deux systèmes est crypté à l'aide d'une clé bidirectionnelle, générée au cours de la phase de connexion de protocole de transfert,
qui n'est connu que par ces deux systèmes.
Pour établir un échange sécurisé de la clé de cryptage bidirectionnelle, SSL utilise PKI (Public Key Infrastructure), une méthode de cryptage qui utilise une paire de clés.
Une paire de clés est composée de deux clés cryptographiques distinctes, mais correspondantes - une clé publique et une clé privée. La clé publique est partagée avec les autres et est utilisée pour crypter les données et la clé privée est tenue secrète et est utilisée pour déchiffrer des données qui ont été chiffrées à l'aide de la clé publique.
Lorsqu'un client demande une connexion sécurisée, une phase de protocole de transfert a lieu avant que la communication sécurisée puisse commencer. Pendant la négociation SSL, le serveur transmet sa clé publique au client sous la forme d'un certificat. Le certificat contient l'identité du serveur (son URL), la clé publique du serveur et une signature numérique valide le certificat. Ensuite, le client valide le certificat et prend une décision quant à savoir si le certificat doit être approuvé ou non. Si le certificat est approuvé, le client génère la clé de cryptage bidirectionnelle pour la connexion SSL, la chiffre à l'aide de la clé publique du serveur et la renvoie sur le serveur. Le serveur décrypte la clé de cryptage bidirectionnelle à l'aide de sa clé privée, et ensuite, la communication entre les deux machines est cryptée via cette connexion par la clé de cryptage bidirectionnelle.
7.2. Implémentation du cryptage SSL pour le serveur de JBoss Enterprise Application Platform.
Introduction
De nombreuses applications web requièrent une connexion cryptée-SSL entre les clients et le serveur, connue sous le nom de connexion HTTPS. Vous pouvez utiliser cette procédure pour activer HTTPS sur votre serveur ou groupe de serveurs.
Prérequis
- Vous aurez besoin d'un ensemble de clés de cryptage SSL et d'un certificat de cryptage SSL. Vous pourrez vous les procurer par l'intermédiaire d'une autorité de signature de certificats. Pour générer les clés de cryptage par les utilitaires de Red Hat Enterprise Linux, voir Section 7.3, « Générer une clé de cryptage SSL et un certificat ».
- Vous devrez connaitre les informations suivantes sur votre environnement et sur votre installation :
- Le nom complet du répertoire et le chemin d'accès à vos fichiers de certificats
- Le mot de passe de cryptage pour vos clés de cryptage.
- Vous devrez exécuter le Management CLI et le connecter à votre contrôleur de domaine ou à votre serveur autonome.
Note
Cette procédure utilise des commandes appropriées à la configuration de JBoss Enterprise Application Platform, qui utilise un domaine géré. Si vous utilisez un domaine autonome, modifier les commandes de Management CLI en supprimant
/profile=default du début d'une commande de Management CLI.
Procédure 7.1. Configurer le JBoss Web Server pour qu'il puisse utiliser HTTPS
Ajouter un nouveau connecteur HTTPS.
Exécuter la commande de Management CLI suivante, en changeant le profil comme il se doit. Cela va créer un nouveau connecteur sécurisé, nomméHTTPS, qui utilise le protocolehttps, la liaison de sockethttps(ayant comme valeur par défaut8443), et qui est définie pour être sécurisée.Exemple 7.1. Commande de Management CLI
/profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
Configurer le certificat de cryptage SSL et les clés.
Exécutez les commandes CLI suivantes pour configurer votre certificat SSL, en remplaçant vos propres valeurs par celles de l'exemple. Cet exemple suppose que le keystore est copié dans le répertoire de configuration du serveur, qui estEAP_HOME/domain/configuration/pour un domaine géré.Exemple 7.2. Commande de Management CLI
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration:add(name=https,certificate-key-file=${jboss.server.config.dir}/keystore.jks,password=SECRET, key-alias=KEY_ALIAS)Pour obtenir une liste complète des paramètres que vous pouvez définir pour les propriétés SSL du connecteur, voir Section 7.4, « Référence de connecteur SSL ».Déployer une application.
Déployer une application dans un groupe de serveurs qui utilise le profil que vous avez configuré. Si vous utilisez un serveur autonome, déployer une application sur votre serveur. Les demandes HTTP en sa direction utilisent la nouvelle connexion cryptée-SSL.
7.3. Générer une clé de cryptage SSL et un certificat
Pour utiliser une connexion chiffrée SSL HTTP (HTTPS), ainsi que d'autres types de communication cryptée-SSL, vous avez besoin d'un certificat de chiffrement signé. Vous pouvez acheter un certificat d'une autorité de certification (AC), ou vous pouvez utiliser un certificat auto-signé. Les certificats auto-signés ne sont pas considérés dignes de confiance par de nombreux tiers, mais conviennent à des fins de test internes.
Cette procédure vous permet de créer un certificat auto-signé lié à des utilitaires disponibles dans Red Hat Enterprise Linux.
Prérequis
- La commande
keytooldoit être disponible. Elle est fournie par le Java Development Kit. Chercher le chemin du fichier. Dans Red Hat Enterprise Linux, OpenJDK installe cette commande à l'emplacement suivant/usr/bin/keytool. - Comprendre la syntaxe et les paramètres de la commande
keytool. Cette procédure utilise des instructions extrêmement génériques, car des discussions plus sophistiquées sur les spécificités des certificats SSL ou sur la commandekeytoolsont hors de portée de cette documentation.
Procédure 7.2. Générer une clé de cryptage SSL et un certificat
Générer un keystore avec des clés privées et des clés publiques.
Exécuter la commande suivante pour générer un keystore nomméserver.keystoreayant comme aliasjbossdans votre répertoire actuel.keytool -genkey -alias jboss -keyalg RSA -keystore server.keystore -storepass mykeystorepass --dname "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,S=NC,C=US"
Le tableau suivant décrit les paramètres utilisés avec la commande «keytool».Paramètre Description -genkeyLa commande keytoolqui génére une paire de clés contenant une clé publique et une clé privée.-aliasL'alias est pour le keystore. Cette valeur est arbitraire, mais l'alias jbossest la valeur par défaut utilisée par le serveur JBoss Web.-keyalgL'algorithme de création de paires de clés. Dans ce cas, c'est RSA.-keystoreLe nom et l'emplacement du fichier keystore. L'emplacement par défaut est le répertoire en cours. Le nom que vous choisissez est arbitraire. Dans ce cas, il s'agit du fichier nommé server.keystore.-storepassCe mot de passe est utilisé pour authentifier le keystore, et pour que la clé puisse être lue. Le mot de passe doit contenir au moins 6 caractères de long et doit être fourni quand on accède au keystore. Dans un tel cas, on utilise mykeystorepass. Si vous omettez ce paramètre, on vous demandera de le saisir quand vous exécuterez la commande.-keypassIl s'agit du mot de passe pour la clé.Note
À cause d'une limitation d'implémentation, il doit correspondre à celui du mot de passe du store.--dnameUne chaîne avec des guillemets qui décrit le nom distinct de la clé, comme par exemple : "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,C=US". Cette chaîne est une compilation des composants suivants : CN- Le nom commun ou le nom d'hôte. Si le nom d'hôte est "jsmith.mycompany.com", leCNsera "jsmith".OU- L'unité organisationnelle, par exemple "Engineering"O- Le nom de l'organisation, par exemple "mycompany.com".L- La localité, par exemple "Raleigh" ou "London"S- L'état ou la province, par exemple "NC". Ce paramètres est optionnel.C- Les 2 lettres d'un code pays, par exemple "US" ou "UK",
Quand vous exécuterez la commande ci-dessus, on vous demandera les informations suivantes :- Si vous n'utilisiez pas le paramètre
-storepasssur la ligne de commande, on vous demandera de saisir le mot de passe du keystore. Saisir le nouveau mot de passe à la seconde invite. - Si vous n'utilisiez pas le paramètre
-keypasssur la ligne de commande, on vous demandera de saisir le mot de passe de la clé. Appuyez sur Enter pour le définir à la même valeur que celle du mot de passe du keystore.
Quand la commande s'achèvera, le fichierserver.keystorecontiendra la clé unique avec l'aliasjboss.Vérifier la clé.
Vérifier que la clé fonctionne correctement en utilisant la commande suivante.keytool -list -keystore server.keystore
On vous demande le mot de passe du keystore. Les contenus du keystore sont affichés (dans ce cas, il s'agit d'une simple clé nomméejboss). Notez le type de la cléjboss, qui estkeyEntry. Cela indique que le keystore contient à la fois une entrée publique et une entrée privée pour cette clé.Créer une demande de signature de certificat.
Exécutez la commande suivante pour générer une demande de signature de certificat en utilisant la clé publique du keystore que vous avez créée dans la 1ère étape.keytool -certreq -keyalg RSA -alias jboss -keystore server.keystore -file certreq.csr
On vous demandera le mot de passe pour pouvoir authentifier le keystore. La commandekeytoolcrée alors une nouvelle demande de signature de certificat nomméecertreq.csrdans le répertoire en cours d'utilisation.Tester le certificat nouvellement généré.
Tester les contenus du certificat avec la commande suivante :openssl req -in certreq.csr -noout -text
Les détails du certificat apparaissent.En option: soumettre votre certificat à une autorité de certification (AC).
Une Autorité de Certification (AC) athentifie votre certificat pour qu'il soit considéré de confiance par des clients de tierce partie. L'AC vous a produit un certificat signé, et en option, vous a peut être fourni un ou plusieurs certificats intermédiaires.Option: exporter un certificat auto-signé du keystore.
Si vous n'en avez besoin que dans un but de test ou en interne, vous pourrez utiliser un certificat auto-signé. Vous pourrez en exporter un, créé dans la première étape, en provenance du keystore, comme suit :keytool -export -alias jboss -keystore server.keystore -file server.crt
On vous demande un mot de passe pour pouvoir s'authentifier au keystore. Un certificat auto-signé, intituléserver.crt, a été créé dans le répertoire en cours d'utilisation.Importer le certificat signé avec tout certificat intermédiaire.
Importer chaque certificat, dans l'ordre dans lequel l'AC vous le demande. Pour chaque AC que vous importez, remplacerintermediate.caouserver.crtpar le nom du fichier. Si vos certificats ne sont pas fournis dans des fichiers séparés, créer un fichier séparé pour chaque certificat, et coller leur contenu dans le fichier.Note
Votre certificat signé et les clés de ce certificat sont des ressources de valeur. Soyez vigilant sur la façon donc vous les transportez entre les serveurs.keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.ca
keytool -import -alias jboss -keystore server.keystore -file server.crt
Testez que vos certificats soient bien importés avec succès.
Exécuter la commande suivante, et saisir le mot de passe de keystore quand on vous le demandera. Les contenus de votre keystore sont affichés, et les certificats font partie de la liste.keytool -list -keystore server.keystore
Résultat
Votre certificat signé est maintenant inclus dans votre keystore et est prêt à l'utilisation pour crypter les connexions SSL, y compris les communications au serveur web HTTPS.
7.4. Référence de connecteur SSL
Les connecteurs JBoss Web peuvent inclure les attributs de configuration SSL suivants. Les commandes CLI fournies sont conçues pour un domaine géré à l'aide du profil
par défaut. Changer le nom du profil à celui que vous souhaitez configurer, pour un domaine géré, ou omettre la portion /profile=default de la commande, pour un serveur autonome.
Tableau 7.1. Attributs de connecteurs SSL
| Attribut | Description | Commande CLI |
|---|---|---|
| Nom |
Le nom d'affichage du connecteur SSL
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=name,value=https) |
| verify-client |
Définir à
true pour obtenir une chaîne de certificat valide de la part d'un client avant d'accepter une connexion. Définir à want si vous voulez que la pile SSL demande un certificat de client, mais ne pas l'échouer si celui-ci n'est pas présenté. Définir à false (la valeur par défaut) si vous ne souhaitez pas demander de chaîne de certificat, à moins que le client ne demande une ressource protégée par une contrainte de sécurité qui utilise l'authentification de CLIENT-CERT.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-client,value=want) |
| verify-depth |
Le nombre maximal d'émetteurs de certificats intermédiaires vérifiés avant de décider que les clients n'ont pas de certificat valide. La valeur par défaut est
10.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-depth,value=10) |
| certificate-key-file |
Le chemin d'accès complet et nom de fichier du keystore où le certificat de serveur signé est stocké. Avec le cryptage JSSE, ce fichier de certificat sera le seul, tandis que OpenSSL utilise plusieurs fichiers. La valeur par défaut est le fichier
.keystore dans le répertoire home de l'utilisateur exécutant JBoss Enterprise Application Platform. Si votre keystoreType n'utilise pas de fichier, définissez le paramètre en chaîne vide
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-key-file,value=../domain/configuration/server.keystore) |
| certificate-file |
Si vous utilisez un cryptage OpenSSL, définir la valeur de ce paramètre au chemin d'accès du fichier qui contient le certificat de serveur.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=server.crt) |
| mot de passe |
Le mot de passe pour le trustore et le keystore à la fois. La valeur par défaut est
changeit, donc vous devrez le changer pour qu'il corresponde au mot de passe de votre keystore si vous souhaitez que votre configuration fonctionne.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=password,value=changeit) |
| protocol |
La version de protocole SSL à utiliser. Les valeurs prises en charge comprennent
SLv2, SSLv3, TLSv1, SSLv2+SSLv3, et ALL. La valeur par défaut est ALL.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=ALL) |
| cipher-suite |
Une liste séparée par des virgules des algorithmes de cryptage autorisés. La valeur par défaut JVM pour JSSE contient des algorithmes de chiffrement faibles, qui ne doivent pas être utilisés. L'exemple répertorie uniquement les deux algorithmes de chiffrement possibles, mais des exemples concrets en utiliseront probablement plus.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=cipher-suite, value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA") |
| key-alias |
L'alias utilisé pour le certificat de serveur dans le keystore. La valeur par défaut est
jboss.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=key-alias,value=jboss) |
| truststore-type |
Le type de truststore. Il existe différents types de keystores, dont
PKCS12 et le JKS standard de Java.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=truststore-type,value=jks) |
| keystore-type |
Le type de keystore. Il existe différents types de keystores, dont
PKCS12 et le JKS standard de Java.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=keystore-type,value=jks) |
| ca-certificate-file |
Le fichier contenant les certificats CA. Il s'agit du
truststoreFile, dans le cas de JSSE, et il utilise le même mot de passe que le keystore. Le fichier ca-certificate-file est utilisé pour valider les certificats de clients.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=ca.crt) |
| ca-certificate-password |
Le mot de passe de certificat est
ca-certificate-file. Dans l'exemple ci-dessous, remplacer le mot de passe par votre propre mot de passe masqué.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-certificate-password,value=MASKED_PASSWORD) |
| ca-revocation-url |
Un fichier ou URL qui contient la liste de révocations. Se réfère au
crlFile pour JSSE ou au SSLCARevocationFile pour SSL.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-revocation-url,value=ca.crl) |
| session-cache-size |
La taille du cache SSLSession. La valeur par défaut est
0, qui désactive la session cache.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-cache-size,value=100) |
| session-timeout |
Le nombre de secondes avant qu'une SSLSession n'expire. La valeur par défaut est
86400 secondes, ce qui correspond à 24 heures.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-timeout,value=43200) |
Chapitre 8. Domaines de sécurité
8.1. Domaines de sécurité
Un domaine de sécurité est une série de mappages entre les utilisateurs et les mots de passe, les utilisateurs et les rôles. Les domaines de sécurité représentent un mécanisme permettant d'ajouter l'authentification et l'autorisation à vos applications Web et EJB. JBoss Enterprise Application Platform 6 fournit deux domaines de sécurité par défaut :
ManagementRealmstocke l'utilisateur, le mot de passe et les informations de rôle pour l'API de gestion, qui fournit les fonctionnalités pour le Management CLI et la Console de gestion sur le web. Il fournit un système d'authentification pour gérer JBoss Enterprise Application Platform elle-même. Vous pouvez également utiliser leManagementRealmsi votre application a besoin des mêmes règles commerciales que vous utilisez pour l'API de gestion, lors de son authentification.ApplicationRealmstocke l'utilisateur, le mot de passe et les informations de rôle pour les applications Web et les EJB.
Chaque domaine est stocké dans deux fichiers du système de fichiers :
REALM-users.propertiesstocke les mots de passe et les mots de passe hachés.REALM-users.rolesstocke les mappages user-to-role.
Les fichiers de propriété sont stockés dans les répertoires
domain/configuration/ et standalone/configuration/. Les fichiers sont inscrits simultanément par la commande add-user.sh ou add-user.bat. Quand vous exécutez la commande, la première décision est de décider dans quel domaine ajouter votre premier utilisateur.
8.2. Ajout d'un Domaine de sécurité
Éxécuter le Management CLI.
Démarrer par la commandejboss-cli.shoujboss-cli.batet connectez-vous au serveur.Créer le nouveau domaine de sécurité lui-même.
Exécutez la commande suivante pour créer un nouveau domaine de sécurité nomméMyDomainsur un contrôleur de domaine ou sur un serveur autonome./host=master/core-service=management/security-realm=MyDomainRealm:add()
Créer les références du fichier de propriétés qui stocke les informations sur le nouveau rôle.
Exécuter la commande suivante pour créer un pointeur au fichier nommémyfile.properties, qui contiendra les propriétés attachées au nouveau rôle.Note
Le fichier de propriétés nouvellement créées n'est pas géré par les scriptsadd-user.shetadd-user.batinclus. Il devra être administré en externe./host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
Résultat
Votre nouveau domaine de sécurité est créé. Lorsque vous ajoutez des utilisateurs et des rôles à ce nouveau domaine, l'information va être stockée dans un fichier séparé des domaines de sécurité par défaut. Vous pouvez gérer ce nouveau fichier à l'aide de vos propres applications ou procédures.
8.3. Ajout d'un utilisateur à un Domaine de sécurité
Éxécuter la commande
add-user.shouadd-user.bat.Ouvrez un shell d'interface en ligne de commande (CLI). Changez de répertoireEAP_HOME/bin/. Si vous exécutez Red Hat Enterprise Linux ou un autre système d'exploitation style UNIX, exécutezadd-user.sh. Si vous exécutez sur un serveur Microsoft Windows, exécutezadd-user.bat.Choisissez d'ajouter un Utilisateur de gestion ou un Utilisateur d'application.
Pour cette procédure, saisirbpour ajouter un Utilisateur d'application.Choisir le domaine dans lequel l'utilisateur sera ajouté.
Par défaut, le seul domaine disponible estApplicationRealm. Si vous avez ajouté un domaine personnalisé, vous pouvez saisir son nom à la place.Saisir le nom d'utilisateur, le mot de passe et les rôles lorsque vous y serez invité.
Saisir le nom d'utilisateur, le mot de passe et les rôles lorsque vous y serez invité. Vérifiez votre choix en tapantyes, ounopour annuler les changements. Les changements sont inscrits dans les fichiers de propriétés du domaine de sécurité.
Chapitre 9. Configuration de sous-système
9.1. Configuration de sous-système de transaction
9.1.1. Configurer l'ORB pour les transactions JTS
Dans une installation JBoss Enterprise Application Platform par défaut, l'ORB est désactivé. Vous pouvez activer l'ORB en utilisant le Management CLI de ligne de commande.
Note
Dans un domaine géré, le sous-système JacORB est disponible dans les profils
full et full-ha uniquement. Dans un serveur autonome, il est disponible uniquement quand vous utilisez les configurations standalone-full.xml ou standalone-full-ha.xml.
Procédure 9.1. Configurer l'ORB par la Console de gestion
Voir les paramètres de configuration du profil.
Sélectionner Profiles (domaine géré) ou Profile (serveur autonome) dans la partie supérieure droite de la console de gestion. Si vous utilisez un domaine géré, sélectionner soit le profil full ou full-ha à partir de la boîte de dialogue de sélection en haut à gauche.Modifier les paramètres d' Initializers
Étendre le menu Subsystems (sous-systèmes) sur la gauche, si nécessaire. Étendre le sous-menu Container et cliquer sur JacORB.Sur le formulaire qui apparaît sur l'écran principal, sélectionner l'onglet Initializers, et cliquer sur le bouton Edit (modifier).Activer les intercepteurs de sécurité en configurant la valeur de Security àon.Pour activer ORB sur JTS, définir la valeur des Transaction Interceptors àon, au lieu de la valeur par défautspec.Voir le lien Need Help? sur le formulaire pour accéder à des explications sur ces valeurs. Cliquer sur Save quand vous aurez fini de modifier les valeurs.Configuration ORB avancée
Voir les autres sections du formulaire pour les options de configuration avancées. Chaque section inclut un lien Need Help? avec des informations détaillées sur les paramètres.
Configurer l'ORB par le Management CLI
Vous pouvez configurer chaque aspect de l'ORB à l'aide du Management CLI. Les commandes suivantes configurent les initialiseurs aux mêmes valeurs que celles de la procédure ci-dessus, pour la Console de gestion. Il s'agit de la configuration minimale pour l'ORB, si utilisé avec JTS.
Ces commandes sont configurées pour un domaine de sécurité utilisant le profil full. Si nécessaire, modifier le profil pour qu'il convienne mieux à celui que vous aurez besoin de configurer. Si vous utilisez un serveur autonome, n'utilisez pas la portion
/profile=full des commandes.
Exemple 9.1. Activer les intercepteurs de sécurité
/profile=full/subsystem=jacorb/:write-attribute(name=security,value=on)
Exemple 9.2. Activer l'ORB pour JTS
/profile=full/subsystem=jacorb/:write-attribute(name=transactions,value=on)
9.2. Configuration JMS
9.2.1. Référence pour les attributs de configuration d'HornetQ
L'implémentation d'HornetQ de JBoss Enterprise Application Platform 6 expose les attributs de configuration suivants. Vous pouvez utiliser le Management CLI pour exposer plus particulièrement les attributs configurables ou affichables par l'opération
read-resource.
Exemple 9.3. Exemple
[standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default:read-resource
Tableau 9.1. Attributs HornetQ
| Attribut | Exemple de valeur | Type |
|---|---|---|
allow-failback | true | BOOLÉEN |
async-connection-execution-enabled | true | BOOLÉEN |
backup | false | BOOLÉEN |
cluster-password | somethingsecure | STRING |
cluster-user | HORNETQ.CLUSTER.ADMIN.USER | STRING |
clustered | false | BOOLÉEN |
connection-ttl-override | -1 | LONG |
create-bindings-dir | true | BOOLÉEN |
create-journal-dir | true | BOOLÉEN |
failback-delay | 5000 | LONG |
failover-on-shutdown | false | BOOLÉEN |
id-cache-size | 2000 | INT |
jmx-domain | org.hornetq | STRING |
jmx-management-enabled | false | BOOLÉEN |
journal-buffer-size | 100 | LONG |
journal-buffer-timeout | 100 | LONG |
journal-compact-min-files | 10 | INT |
journal-compact-percentage | 30 | INT |
journal-file-size | 102400 | LONG |
journal-max-io | 1 | INT |
journal-min-files | 2 | INT |
journal-sync-non-transactional | true | BOOLÉEN |
journal-sync-transactional | true | BOOLÉEN |
journal-type | ASYNCIO | STRING |
live-connector-ref | référence | STRING |
log-journal-write-rate | false | BOOLÉEN |
management-address | jms.queue.hornetq.management | STRING |
management-notification-address | hornetq.notifications | STRING |
memory-measure-interval | -1 | LONG |
memory-warning-threshold | 25 | INT |
message-counter-enabled | false | BOOLÉEN |
message-counter-max-day-history | 10 | INT |
message-counter-sample-period | 10000 | LONG |
message-expiry-scan-period | 30000 | LONG |
message-expiry-thread-priority | 3 | INT |
page-max-concurrent-io | 5 | INT |
perf-blast-pages | -1 | INT |
persist-delivery-count-before-delivery | false | BOOLÉEN |
persist-id-cache | true | BOOLÉEN |
persistence-enabled | true | BOOLÉEN |
remoting-interceptors | Non défini | LIST |
run-sync-speed-test | false | BOOLÉEN |
scheduled-thread-pool-max-size | 5 | INT |
security-domain | autre | STRING |
security-enabled | true | BOOLÉEN |
security-invalidation-interval | 10000 | LONG |
server-dump-interval | -1 | LONG |
shared-store | true | BOOLÉEN |
started | true | BOOLÉEN |
thread-pool-max-size | 30 | INT |
transaction-timeout | 300000 | LONG |
transaction-timeout-scan-period | 1000 | LONG |
version | 2.2.16.Final (HQ_2_2_16_FINAL, 122) | STRING |
wild-card-routing-enabled | true | BOOLÉEN |
Avertissement
La valeur de
journal-file-size doit être plus élevée que celle de la taille du message envoyé au serveur, ou bien le serveur ne pourra pas stocker le message.
Chapitre 10. Web, Connecteurs HTTP, et HTTP Clustering
10.1. jboss jboss Configurer un noeud de worker en mod_cluster
Le maître n'est configuré qu'une fois, par l'intermédiaire du sous-système de
mod_cluster. Pour configurer le sous-système mod_cluster, reportez-vous à Configure the mod_cluster Subsystem dans Administration and Configuration Guide. Chaque nœud du travailleur est configurée séparément, alors répétez cette procédure pour chaque nœud que vous souhaitez ajouter au cluster.
Si vous utilisez un domaine géré, chaque serveur de groupe de serveur est un nœud de worker qui partage une configuration identique. Par conséquent, la configuration s'effectue sur un groupe de serveurs. Dans un serveur autonome, la configuration s'effectue sur une seule instance de JBoss Enterprise Application Platform. Les étapes de configuration sont sinon identiques.
Configuration d'un noeud de worker
- Si vous utilisez un serveur autonome, il devra être démarré par le profile
standalone-ha. - Si vous utilisez un domaine géré, votre groupe de serveurs devra utiliser le profil
haoufull-ha, et le groupe de liaisons de socketsha-socketsoufull-ha-sockets. JBoss Enterprise Application Platform est fournie avec un groupe de serveurs à clusterisation activée, nomméother-server-groupqui remplit ces prérequis.
Note
Quand vous avez des commandes de Mangement CLI, celles-ci assument que vous utilisez un domaine géré. Si vous utilisez un serveur autonome, supprimer la portion
/profile=full-ha des commandes.
Procédure 10.1. Configurer un noeud de worker
Configurer les interfaces de réseau
Les interfaces de réseau ont toutes la valeur127.0.0.1par défaut. Chaque hôte physique, qui accueille un serveur autonome ou bien un ou plusieurs serveurs au sein d'un groupe de serveurs, a besoin de ses interfaces configurées pour utiliser son adresse IP, que les autres serveurs peuvent apercevoir.Pour changer l'adresse IP d'un hôte de JBoss Enterprise Application Platform, vous devrez le fermer et modifier son fichier de configuration directement. C'est parce que l'API de gestion qui actionne la Console de gestion et le Management CLI se fie à une adresse de gestion stable.Suivez ces étapes pour changer l'adresse IP sur chaque serveur de votre cluster en votre adresse IP publique de master.- Fermer le serveur complètement.
- Modifier soit
host.xml, qui se trouve dansEAP_HOME/domain/configuration/pour un domaine géré, ou bien le fichierstandalone-ha.xml, qui se trouve dansEAP_HOME/standalone/configuration/pour un serveur autonome. - Chercher l'élément
<interfaces>. Il y a trois interfaces configurées. Ces interfaces sontmanagement,public, etunsecured. Pour chacune d'entre elles, changer la valeur127.0.0.1à l'adresse IP externe de l'hôte. - Pour les hôtes qui participent à un domaine géré, mais qui ne sont pas master, localiser l'élément
<host. Notez qu'il n'a pas de symbole de fermeture>, car il contient des attributs. Modifiez la valeur de son nom d'attributmasterpar un nom unique, avec un nom différent par esclave. Ce nom servira aussi à l'esclave pour identifier au cluster, donc notez bien ceci. - Pour les hôtes nouvellement configurés qui ont besoin de rejoindre un domaine géré, chercher l'élément
<domain-controller>. Dé-commenter ou supprimer l'élément<local />, et ajouter la ligne suivante, en changeant l'adresse IP (X.X.X.X) par l'adresse du contrôleur de domaine. Cette étape ne s'applique pas à un serveur autonome.<remote host="X.X.X.X" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> - Sauvegarder le fichier et sortir.
Configurer l'authentification pour chaque serveur esclave.
Chaque serveur esclave a besoin d'un nom d'utilisateur et d'un mot de passe créé dans leManagementRealmdu contrôleur de domaine ou du master autonome. Sur le contrôleur de domaine ou sur le master autonome, exécutez la commandeEAP_HOME/add-user.sh. Ajouter un utilisateur avec le même nom d'utilisateur comme esclave, auManagementRealm. Quand on vous demandera si cet utilisateur doit s'authentifier auprès d'une instance de JBoss AS externe, répondezOui. Vous trouverez un exemple de l'entrée et de la sortie de la commande ci-dessous, pour un esclave appeléslave1, et un mot de passechangeme.user:bin user$ ./add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a):
aEnter the details of the new user to add. Realm (ManagementRealm) : Username :slave1Password :changemeRe-enter Password :changemeAbout to add user 'slave1' for realm 'ManagementRealm' Is this correct yes/no?yesAdded user 'slave1' to file '/home/user/jboss-eap-6.0/standalone/configuration/mgmt-users.properties' Added user 'slave1' to file '/home/user/jboss-eap-6.0/domain/configuration/mgmt-users.properties' Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller? yes/no? yes To represent the user add the following to the server-identities definition <secret value="Y2hhbmdlbWU=" />Copier l'élément codé-Base64
<secret>à partir de la sortieadd-user.sh.Si vous prévoyez de spécifier un mot de passe codé-Base64 pour l'authentification, copier l'élément<secret>à partir de la dernière ligne de la sortieadd-user.shcar vous en aurez besoin à l'étape suivante.Modifier le domaine de sécurité de l'hôte esclave pour la nouvelle authentification.
- Réouvrir le fichier
host.xmloustandalone-ha.xmlde l'hôte esclave. - Chercher l'élément
<security-realms>. C'est là où vous configurez le domaine de sécurité. - Vous pourrez spécifier la valeur secrète d'une des manières suivantes :
Spécifier le mot de passe codé-Base64 dans le fichier de configuration.
- Ajouter le bloc suivant de code XML sous la ligne
<security-realm name="ManagementRealm">,<server-identities> <secret value="Y2hhbmdlbWU="/> </server-identities> - Remplacer "Y2hhbmdlbWU=" par la valeur secrète retournée de la sortie
add-user.shlors de l'étape précédente.
Configurer l'hôte pour obtenir un mot de passe de l'archivage sécurisé.
- Utiliser le script
vault.shpour générer un mot de passe masqué. Cela va créer un string qui ressemblera à ceci :VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0.Vous pourrez trouver plus d'informations sur l'archivage sécurisé dans Password Vaults de la section Sensitive Strings de ce guide, ici : Section 3.8.1, « Sécurisation des chaînes sensibles des fichiers en texte clair ». - Ajouter le bloc de code XML suivant directement sous la ligne
<security-realm name="ManagementRealm">.<server-identities> <secret value="${VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0}"/> </server-identities>Veillez à remplacer la valeur secrète par le mot de passe masqué généré lors de l'étape précédente.Note
Quand vous créez un mot de passe dans l'archivage sécurisé, celui-ci devra être spécifié en texte brut, et non pas codé-Base64.
Spécifier le mot de passe en tant que propriété système.
- Ajouter le bloc de code XML suivant sous la ligne
<security-realm name="ManagementRealm"><server-identities> <secret value=${server.identity.password}/> </server-identities> - Quand vous spécifiez le mot de passe en tant que propriété système, vous pouvez configurer l'hôte d'une des manières suivantes :
- Démarrer le serveur en saisissant le mot de passe en texte brut comme argument de ligne de commande, comme par exemple :
-Dserver.identity.password=changeme
Note
Le mot de passe doit être saisi en texte brut et sera visible par quiconque lance la commandeps -ef. - Mettez le mot de passe dans un fichier de propriétés et passer l'URL du fichier de propriétés sous forme d'argument de ligne de commande.
- Ajouter la paire clé/valeur à un fichier de propriétés. Par exemple :
server.identity.password=changeme
- Démarrer le serveur par les arguments de ligne de commande
--properties=URL_TO_PROPERTIES_FILE
.
- Sauvegarder et sortir du fichier.
Redémarrer le serveur.
L'esclave va maintenant authentifier le master en utilisant son nom d'hôte comme nom d'utilisateur et le string codifié comme son mot de passe.
Chapitre 11. Sécurité de réseau
11.1. Sécuriser les interfaces de gestion
Résumé
Dans un environnement de test, il est de pratique courante de faire fonctionner JBoss Enterprise Application Platform 6 sans couche de sécurité sur les interfaces de gestion, composées de la Console de gestion, du Management CLI ou autre implémentation de l'API. Cela permet des changements rapides de développement et de configuration.
De plus, un mode silencieux d'authentification est présent par défaut, permettant à un client local sur une machine hôte de se connecter au Management CLI sans exiger un nom d'utilisateur ou un mot de passe. Ce comportement est pratique pour les utilisateurs locaux et les scripts de Management CLI, mais peut être désactivé si nécessaire. La procédure est décrite dans la rubrique .
Quand vous commencez à tester ou à préparer votre environnement pour aller en production, il est vitalement important de sécuriser les interfaces de gestion par l'une des méthodes suivantes au moins:
11.2. Indiquer les interfaces réseau que la plateforme JBoss EAP utilise
Aperçu
Isoler les services afin qu'ils soient accessibles uniquement aux clients qui en ont besoin augmente la sécurité de votre réseau. JBoss Enterprise Application Platform inclut deux interfaces dans sa configuration par défaut, qui se lient toutes les deux à l'adresse IP 127.0.0.1 ou localhost, par défaut. Une des interfaces est appelée management et est utilisée par les consoles de CLI et API de gestion. L'autre est appelée public et est utilisée pour déployer des applications. Ces interfaces ne sont pas spéciales, ni importantes, mais sont fournies comme point de départ.
L'interface
management utilise les ports 9990 et 9999 par défaut, et l'interface public utilise le port 8080, ou le port 8443 avec HTTPS.
Vous pouvez changer l'adresse IP de l'interface de gestion, de l'interface publique ou bien les deux à la fois.
Avertissement
Si vous exposez les interfaces de gestion à d'autres interfaces de réseau non accessibles par les hôtes distants, vérifiez les implications au niveau de la sécurité. Le plus souvent, il n'est pas conseillé de donner un accès à distance aux interfaces de gestion.
Stopper JBoss Enterprise Application Platform.
Arrêter JBoss Enterprise Application Platform en interrompant votre système d'exploitation de manière appropriée. Si vous exécutez Enterprise Application Platform comme une application de premier plan, vous devrez appuyer sur Ctrl+C .Démarrer à nouveau JBoss Enterprise Application Platform, en indiquant l'adresse de liaison.
Utilisez la ligne de commande-bpour démarrer JBoss Enterprise Application Platform sur une interface particulière.Exemple 11.1. Indiquer l'interface publique.
EAP_HOME/bin/domain.sh -b 10.1.1.1
Exemple 11.2. Indiquer l'interface de gestion.
EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1
Exemple 11.3. Indiquer des adresses différentes pour chaque interface.
EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1
Exemple 11.4. Lier l'interface publique à toutes les interfaces de réseau.
EAP_HOME/bin/domain.sh -b 0.0.0.0
Il est possible de modifier votre fichier de configuration XML directement, pour changer les adresses de liaison par défaut. Toutefois, si vous faites cela, vous ne serez plus en mesure d'utiliser la commande
-b pour spécifier une adresse IP en cours d'exécution, donc ce n'est pas recommandé. Si vous décidiez de le faire, n'oubliez pas d'arrêter JBoss Enterprise Application Platform complètement avant d'éditer le fichier XML.
11.3. Configurer les pare-feux de réseau pour qu'ils soient opérationnels dans JBoss Enterprise Application Platform 6
Résumé
La plupart des environnements de production utilisent des pare-feux pour la stratégie globale de sécurité réseau. Si vous avez besoin de plusieurs instances de serveurs pour communiquer les uns avec les autres ou avec des services externes tels que des serveurs web ou des bases de données, votre pare-feu doit en tenir compte. Un pare-feu bien géré ouvre seulement les ports qui sont utiles à l'opération et limite l'accès aux ports à des adresses IP spécifiques, des sous-réseaux et des protocoles réseau.
Une discussion plus complète sur les pare-feux est au delà du dessein de cette documentation.
Prérequis
- Détermine les ports que vous avez besoin d'ouvrir. Voir Section 11.4, « Ports de réseau utilisés par la plateforme JBoss EAP 6 » pour déterminer la liste des ports pour votre situation.
- Vous devez avoir une bonne compréhension de vos logiciels de pare-feux. Cette procédure utilise la commande
system-config-firewallde Red Hat Enterprise Linux 6. Microsoft Windows Server inclut un pare-feu intégré, et plusieurs solutions de pare-feux de tierce partie existent pour chaque plate-forme.
Hypothèses
Cette procédure configure un pare-feu dans un environnement qui comprend les hypothèses suivantes :
- Le système d'exploitation est Red Hat Enterprise Linux 6
- La plate-forme JBoss EAP 6 exécute sur l'hôte
10.1.1.2. En option, le serveur peut posséder son propre pare-feu. - Le serveur du pare-feu de réseau exécute sur l'hôte
10.1.1.1sur l'interfaceeth0, et possède une interface externeeth1. - Le traffic de réseau devra être redirigé vers le port 5445 (port utilisé par JMS) renvoyé sur EAP. Le traffic ne doit pas pouvoir transiter par le pare-feu du réseau.
Procédure 11.1. Gérer les pare-feux de réseau pour qu'ils soient opérationnels dans JBoss Enterprise Application Platform 6
Connectez-vous à la Console de gestion.
Connectez-vous à la Console de gestion. Par défaut, exécute sur http://localhost:9990/console/.Déterminer les liaisons de socket utilisées par le groupe de liaisons de socket.
Cliquer sur l'étiquette Profiles qui se trouve en haut et à droite de la Console de gestion. Sur la gauche de l'écran, vous verrez une série de menus. Le titre en bas du menu est General Configuration (Configuration générale). Cliquer sur Socket Binding Groups sous ce titre. L'écran Socket Binding Declarations apparaîtra. Pour commencer, vous verrez le groupestandard-sockets. Vous pourrez choisir un autre groupe en le sélectionnant de la case mixte à droite.Note
Si vous utilisez un serveur autonome, il ne possédera qu'un seul groupe de liaisons de socket.La liste de noms de sockets et des ports apparaît, avec six valeurs par page. Vous pourrez naviguer entre les pages grâce à la flèche de navigation en dessous du tableau.Déterminer les ports que vous souhaitez ouvrir.
Suivant la fonction d'un port particulier, et suivant les besoins de votre environnement, certains ports devront sans doute être disponibles en dépit du pare-feu. Si vous n'êtes pas certain du but de la liaison de socket, voir Section 11.4, « Ports de réseau utilisés par la plateforme JBoss EAP 6 » pour obtenir une liste des liaisons de socket par défaut, et leur but.Configurer votre pare-feu pour rediriger le trafic réseau vers la plateforme JBoss EAP 6.
Procédez à ces étapes de configuration de votre pare-feu de réseau pour permettre au trafic de se diriger vers le port désiré.- Connectez-vous au pare-feu de votre machine, et accéder à cette commande, en tant qu'utilisateur root.
- Saisir la commande
system-config-firewallpour lancer l'utilitaire de configuration du pare-feu. Un GUI ou Utilitaire de ligne de commande opérera, selon la façon dont vous êtes connecté au système de pare-feu. Cette tâche assume que vous êtes connecté via SSH et que vous utilisez l'interface de ligne de commande. - Utiliser la clé TAB de votre clavier pour naviguer vers le bouton , puis appuyer sur la clé ENTER. L'écranTrusted Services apparaîtra.
- Ne changez aucune valeur, mais utilisez la clé TAB pour naviguer vers le bouton , puis, appuyer sur ENTER pour aller vers le prochain écran. L'écran Other Ports apparaîtra.
- Utiliser la clé TAB pour naviguer vers le bouton <Add>, puis appuyer sur la clé ENTER. L'écran Port and Protocol apparaîtra.
- Saisissez
5445dans le champ Port / Port Range, puis utilisez la clé TAB pour vous rendre dans le champ Protocol, puis saisisseztcp. Utilisez la clé TAB pour naviguer vers le bouton , puis appuyez sur ENTER. - Utilisez la clé TAB pour naviguer vers le bouton jusqu'à ce que vous atteigniez Port Forwarding.
- Utiliser la clé TAB pour naviguer vers le bouton <Add>, puis appuyer sur la clé ENTER.
- Remplir les valeurs suivantes pour définir la redirection de port vers port 5445.
- Interface source: eth1
- Protocol: tcp
- Port / Port Range: 5445
- Destination IP address: 10.1.1.2
- Port / Port Range: 5445
Utiliser la clé TAB pour naviguer vers le bouton , puis appuyer sur la clé ENTER. - Utiliser la clé TAB pour naviguer vers le bouton , puis appuyer sur la clé ENTER.
- Utiliser la clé TAB pour naviguer vers le bouton , puis appuyer sur ENTER. Pour appliquer les changements, lire la notice d'avertissement, puis appuyer sur .
Configurer un pare-feu sur votre hôte de plateforme JBoss EAP 6.
Certaines organisations choisissent de configurer un pare-feu sur le serveur JBoss EAP 6 lui-même et de fermer tous les ports qui ne sont pas utiles à son fonctionnement. Consulter Section 11.4, « Ports de réseau utilisés par la plateforme JBoss EAP 6 » pour déterminer quels ports ouvrir, puis fermer le reste. La configuration par défaut de Red Hat Enterprise Linux 6 ferme tous les ports sauf 22 (utilisé pour Secure Shell (SSH) et 5353 (utilisé pour la multi-diffusion DNS). Si vous configurez les ports, assurez-vous que vous avez un accès physique à votre serveur pour ne pas, par inadvertance, vous verrouiller vous-même.
Résultat
Votre pare-feu est configuré pour renvoyer le trafic vers votre serveur JBoss EAP 6 interne, de la façon dont vous avez spécifié dans la configuration de votre pare-feu. Si vous avez choisi d'activer un pare-feu sur votre serveur JBoss Enterprise Application Platform 6, tous les ports seront fermés sauf ceux nécessaires à l'exécution de vos applications.
11.4. Ports de réseau utilisés par la plateforme JBoss EAP 6
Les ports de réseau utilisés par la configuration par défaut de la plateforme JBoss EAP 6 dépendent de plusieurs facteurs:
- Le fait que vos groupes de serveurs utilisent le groupe de liaisons de sockets par défaut , ou un groupe de liaisons de sockets personnalisé.
- Des exigences de vos déploiements individuels.
Note
Un décalage de port numérique peut être configuré pour atténuer les conflits de ports lorsque vous exécutez plusieurs serveurs sur un même serveur physique. Si votre serveur utilise un décalage de port numérique, ajouter le décalage au numéro de port par défaut pour le groupe de liaisons de socket de son groupe de serveurs. Par exemple, si le port HTTP du groupe de liaisons de socket est 8080 et si votre serveur utilise un décalage de port de 100, son port HTTP sera 8180.
À moins d'instruction particulière, les ports utilisent le protocole TCP.
Groupes de liaison de socket par défaut
full-ha-socketsfull-socketsha-socketsstandard-sockets
Tableau 11.1. Référence aux Groupes de liaison de socket par défaut
| Nom | Port | Port Multidiffusion | Description | full-ha-sockets | full-sockets | ha-socket | standard-socket |
|---|---|---|---|---|---|---|---|
ajp | 8009 | Protocole Apache JServ. Utilisé pour le clustering HTTP et pour l'équilibrage des charges. | Oui | Oui | Oui | Oui | |
http | 8080 | Le port par défaut des applications déployées. | Oui | Oui | Oui | Oui | |
https | 8443 | Connexion cryptée-SSL entre les applications déployées et les clients. | Oui | Oui | Oui | Oui | |
jacorb | 3528 | Services CORBA pour les transactions JTS et autres services dépendants-ORB. | Oui | Oui | Non | Non | |
jacorb-ssl | 3529 | Services CORBA cryptés-SSL. | Oui | Oui | Non | Non | |
jgroups-diagnostics | 7500 | Multicast. Utilisé pour la découverte de paires dans les groupements HA. | Oui | Non | Oui | Non | |
jgroups-mping | 45700 | Multicast. Utilisé pour découvrir l'appartenance de groupe d'orgine dans un cluster HA. | Oui | Non | Oui | Non | |
jgroups-tcp | 7600 | Découverte de paires unicast dans les groupements HA avec TCP. | Oui | Non | Oui | Non | |
jgroups-tcp-fd | 57600 | Utilisé pour la détection des échecs en TCP. | Oui | Non | Oui | Non | |
jgroups-udp | 55200 | 45688 | Découverte de paires unicast dans les groupements HA avec TCP. | Oui | Non | Oui | Non |
jgroups-udp-fd | 54200 | Utilisé pour la détection des échecs par UDP. | Oui | Non | Oui | Non | |
messaging | 5445 | Service JMS. | Oui | Oui | Non | Non | |
messaging-group | Référencé par la difffusion HornetQ JMS et les groupes Discovery | Oui | Oui | Non | Non | ||
messaging-throughput | 5455 | Utilisé par JMS à distance. | Oui | Oui | Non | Non | |
mod_cluster | 23364 | Port multicast de communication entre l'équilibreur de charge HTTP et JBoss Enterprise Application Platform. | Oui | Non | Oui | Non | |
osgi-http | 8090 | Utilisé par les composants internes qui utilisent le sous-système OSGi. | Oui | Oui | Oui | Oui | |
remoting | 4447 | Utilisé pour l'invocation EJB. | Oui | Oui | Oui | Oui | |
txn-recovery-environment | 4712 | Gestionnaire de recouvrement des transactions JTA. | Oui | Oui | Oui | Oui | |
txn-status-manager | 4713 | Gestionnaire des transactions JTA / JTS. | Oui | Oui | Oui | Oui |
Ports de gestion
En plus des groupes de liaisons de socket, chaque contrôleur d'hôte ouvre deux ports supplémentaires pour la gestion:
- 9990 - Le port de Console de gestion
- 9999 - Le port utilisé par la Console de gestion et par le Management API
Partie III. Sécuriser des applications
Chapitre 12. Sécurité des applications
12.1. Activer/Désactiver un remplacement de propriété basé descripteur
Avertissement
Topic 9089, Revision 431229 failed validation and is not included in this build.
12.2. Sécurité des bases de données
12.2.1. Sécurité des bases de données
La meilleure solution de sécuriser les bases de données est soit l'utilisation des domaines de sécurité, soit les mots de passe. Vous trouverez un exemple de chacun ci-dessous. Pour plus d'informations, consulter :
- Domaines de sécurité : Section 6.1, « Les domaines de sécurité ».
Exemple 12.1. Exemple de domaine de sécurité
<security> <security-domain>mySecurityDomain</security-domain> </security>
Exemple 12.2. Exemple de mots de passe
<security>
<user-name>admin</user-name>
<password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>
12.3. Sécurité des applications EJB
12.3.1. Identité Sécurité
12.3.1.1. L'identité de sécurité EJB
L'identité de sécurité, connue également sous le nom identité d'invocation, se réfère à la balise
<security-identity> qui se trouve dans la configuration de la sécurité. Il s'agit d'une référence à l'identité qu'un autre EJB doit utiliser quand il invoque des méthodes ou des composants.
L'identité d'invocation peut soit correspondre à l'appelant actuel, ou correspondre à un rôle spécifique. Dans le premier cas, la balise
<use-caller-identity> sera présente, et dans le second cas, la balise <run-as> sera utilisée.
Pour plus d'information sur la configuration de l'identité de sécurité sur un EJB, voir .
12.3.1.2. Définir l'identité de sécurité d'un EJB
Exemple 12.3. Définir l'identité de sécurité d'un EJB pour qu'il soit le même que celui de l'appelant
Cet exemple définit l'identité de sécurité pour les invocations de méthode faîtes par un EJB de façon à ce qu'elle soit la même identité que celle de l'appelant actuel. Ce comportement correspond au comportement par défaut si vous ne spécifiez pas une déclaration d'élément
<security-identity>.
<ejb-jar> <enterprise-beans> <session> <ejb-name>ASessionBean</ejb-name> <!-- ... --> <security-identity> <use-caller-identity/> </security-identity> </session> <!-- ... --> </enterprise-beans> </ejb-jar>
Exemple 12.4. Définir l'idendité de sécurité d'un EJB à un rôle spécifique
Pour définir une identité de sécurité à un rôle spécifique, utiliser les balises
<run-as> ou <role> à l'intérieur de la balise <security-identity>.
<ejb-jar> <enterprise-beans> <session> <ejb-name>RunAsBean</ejb-name> <!-- ... --> <security-identity> <run-as> <description>A private internal role</description> <role-name>InternalRole</role-name> </run-as> </security-identity> </session> </enterprise-beans> <!-- ... --> </ejb-jar>
Par défaut, quand vous utilisez
<run-as>, un principal nommé anonymous est assigné aux appels sortant. Pour assigner un autre principal, utiliser <run-as-principal>.
<session>
<ejb-name>RunAsBean</ejb-name>
<security-identity>
<run-as-principal>internal</run-as-principal>
</security-identity>
</session>
Note
Vous pouvez utiliser les éléments
<run-as> et <run-as-principal> à l'intérieur d'un élément de servlet.
Voir également :
12.3.2. Permissions de méthodes EJB
12.3.2.1. Permissions de méthodes EJB
EJB fournit une déclaration d'élément
<method-permisison>. Cette déclaration définit les rôles qui sont autorisés à appeler des méthodes de l'interface EJB. Vous pouvez définir des permissions pour les combinaisons suivantes :
- Toutes les méthodes d'interface de composant ou d'accueil de l'EJB nommé
- Une méthode spécifiée d'interface de composant ou d'accueil de l'EJB nommé
- Une méthode spécifiée à l'intérieur d'un ensemble de méthodes avec un nom surchargé
Pour obtenir des exemples, voir Section 12.3.2.2, « Utilisation des Permissions de méthodes EJB ».
12.3.2.2. Utilisation des Permissions de méthodes EJB
Aperçu
L'élément <method-permission> définit les roles logiques qui peuvent accéder aux méthodes EJB définies par les éléments <method>. Un certain nombre d'exemples expliquent la syntaxe XML. Plusieurs énoncés de method-permission peuvent être présents, et avoir un effet cumulatif. L'élément <method-permission> est un dépendant de l'élément <assembly-descriptor> du descripteur <ejb-jar>.
La syntaxe XML est une alternative aux annotations pour les permissions de méthode EJB.
Exemple 12.5. Permet aux rôles d'accéder à toutes les méthodes d'un EJB
<method-permission>
<description>The employee and temp-employee roles may access any method
of the EmployeeService bean </description>
<role-name>employee</role-name>
<role-name>temp-employee</role-name>
<method>
<ejb-name>EmployeeService</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
Exemple 12.6. Permet aux rôles d'accéder uniquement à des méthodes spécifiques d'un EJB, et de déterminer quels paramètres de méthode peuvent être passés.
<method-permission> <description>The employee role may access the findByPrimaryKey, getEmployeeInfo, and the updateEmployeeInfo(String) method of the AcmekPayroll bean </description> <role-name>employee</role-name> <method> <ejb-name>AcmekPayroll</ejb-name> <method-name>findByPrimaryKey</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>getEmployeeInfo</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>updateEmployeeInfo</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> </method-permission>
Exemple 12.7. Permet à n'importe quel utilisateur authentifié d'accéder aux méthodes des EJB
Utiliser l'élément
<unchecked/> permet à un utilisateur authentifié d'utiliser les méthodes spécifiées.
<method-permission> <description>Any authenticated user may access any method of the EmployeeServiceHelp bean</description> <unchecked/> <method> <ejb-name>EmployeeServiceHelp</ejb-name> <method-name>*</method-name> </method> </method-permission>
Exemple 12.8. Exclut totalement certaines méthodes EJB à l'utilisation
<exclude-list> <description>No fireTheCTO methods of the EmployeeFiring bean may be used in this deployment</description> <method> <ejb-name>EmployeeFiring</ejb-name> <method-name>fireTheCTO</method-name> </method> </exclude-list>
Exemple 12.9. Un <assembly-descriptor> complet contenant plusieurs blocs de <method-permission>
<ejb-jar>
<assembly-descriptor>
<method-permission>
<description>The employee and temp-employee roles may access any
method of the EmployeeService bean </description>
<role-name>employee</role-name>
<role-name>temp-employee</role-name>
<method>
<ejb-name>EmployeeService</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
<method-permission>
<description>The employee role may access the findByPrimaryKey,
getEmployeeInfo, and the updateEmployeeInfo(String) method of
the AcmePayroll bean </description>
<role-name>employee</role-name>
<method>
<ejb-name>AcmePayroll</ejb-name>
<method-name>findByPrimaryKey</method-name>
</method>
<method>
<ejb-name>AcmePayroll</ejb-name>
<method-name>getEmployeeInfo</method-name>
</method>
<method>
<ejb-name>AcmePayroll</ejb-name>
<method-name>updateEmployeeInfo</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
</method-permission>
<method-permission>
<description>The admin role may access any method of the
EmployeeServiceAdmin bean </description>
<role-name>admin</role-name>
<method>
<ejb-name>EmployeeServiceAdmin</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
<method-permission>
<description>Any authenticated user may access any method of the
EmployeeServiceHelp bean</description>
<unchecked/>
<method>
<ejb-name>EmployeeServiceHelp</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
<exclude-list>
<description>No fireTheCTO methods of the EmployeeFiring bean may be
used in this deployment</description>
<method>
<ejb-name>EmployeeFiring</ejb-name>
<method-name>fireTheCTO</method-name>
</method>
</exclude-list>
</assembly-descriptor>
</ejb-jar>
12.3.3. Annotations de sécurité EJB
12.3.3.1. Les annotations de sécurité EJB
Les EJB utilisent des annotations de sécurité pour faire passer des informations de sécurité au déployeur. Celles-ci comprennent :
- @DeclareRoles
- Déclare quels rôles sont disponibles.
- @SecurityDomain
- Indique le domaine de sécurité à utiliser pour l'EJB. Si l'EJB est annoté pour autorisation avec
@RolesAllowed, l'autorisation ne s'appliquera que si l'EJB est annoté par un domaine de sécurité. - @RolesAllowed, @PermitAll, @DenyAll
- Indique quelles permissions de méthodes sont autorisées. Pour obtenir des informations sur les permissions de méthode, voir Section 12.3.2.1, « Permissions de méthodes EJB ».
- @RolesAllowed, @PermitAll, @DenyAll
- Indique quelles permissions de méthodes sont autorisées. Pour obtenir des informations sur les permissions de méthode, voir Section 12.3.2.1, « Permissions de méthodes EJB ».
- @RunAs
- Configure l'identification de sécurité propagée d'un composant.
Pour plus d'information, voir Section 12.3.3.2, « Utilisation des annotations de sécurité EJB ».
12.3.3.2. Utilisation des annotations de sécurité EJB
Aperçu
Vous pouvez utiliser deux descripteurs XML ou des annotations pour contrôler quels rôles de sécurité sont en mesure d'appeler des méthodes dans votre Enterprise JavaBeans (EJB). Pour plus d'informations sur l'utilisation des descripteurs XML, reportez-vous à Section 12.3.2.2, « Utilisation des Permissions de méthodes EJB ».
Annotations pour contrôler les permissions de sécurité des EJB
- @DeclareRoles
- Utiliser @DeclareRoles pour déterminer sur quels roles de sécurité vérifier les permissions. Si aucun @DeclareRoles n'est présent, la liste sera édifié automatiquement à partir de l'annotation @RolesAllowed.
- @SecurityDomain
- Indique le domaine de sécurité à utiliser pour l'EJB. Si l'EJB est annoté pour autorisation avec
@RolesAllowed, l'autorisation ne s'appliquera que si l'EJB est annoté par un domaine de sécurité. - @RolesAllowed, @PermitAll, @DenyAll
- Utiliser @RolesAllowed pour lister les roles autorisés pour accéder à une méthode ou à des méthodes. Utiliser @PermitAll ou @DenyAll pour permettre ou refuser à tous les roles d'utiliser une méthode ou des méthodes.
- @RunAs
- Utiliser @RunAs pour spécifier un role permanent pour une méthode.
Exemple 12.10. Exemple d'annotations de sécurité
@Stateless
@RolesAllowed({"admin"})
@SecurityDomain("other")
public class WelcomeEJB implements Welcome {
@PermitAll
public String WelcomeEveryone(String msg) {
return "Welcome to " + msg;
}
@RunAs("tempemployee")
public String GoodBye(String msg) {
return "Goodbye, " + msg;
}
public String
public String GoodbyeAdmin(String msg) {
return "See you later, " + msg;
}
}
Avec ce code, tous les roles peuvent accéder à la méthode
WelcomeEveryone. La méthode GoodBye exécute sous la forme du rôle tempemployee. Seul le role admin peut accéder à la méthode GoodbyeAdmin, ou à toute autre méthode sans annotation de sécurité.
12.3.4. Accès à distance aux EJB
12.3.4.1. Remote Method Access
JBoss Remoting est le framework qui fournit un accès à distance aux EJBs, JMX MBeans, et autres services similaires. Fonctionne avec les types de transport suivants, avec ou sans SSL :
Types de services pris en charge
- Socket / Secure Socket
- RMI / RMI sur SSL
- HTTP / HTTPS
- Servlet / Secure Servlet
- Bisocket / Secure Bisocket
JBoss Remoting fournit aussi automatic discovery via Multicast ou JNDI.
Il est utilisé par bon nombre des sous-systèmes au sein de la plateforme JBoss Enterprise Application Platform et permet également de concevoir, d'implémenter et de déployer des services pouvant être appelés à distance par les clients sur plusieurs mécanismes de transport différents. Il vous permet également d'accéder aux services existants dans JBoss Enterprise Application Platform.
Data Marshalling
Le système Remoting d'accès distant fournit également des services de marshalling et unmarshalling de données. Le marshaling de données désigne la capacité de déplacer en toute sécurité des données au-delà des limites de réseau et de la plate-forme, afin qu'un système séparé puisse effectuer des tâches dessus. Le travail est ensuite renvoyé vers le système d'origine et se comporte comme s'il avait eu lieu localement.
Aperçu de l'architecture
Lorsque vous créez une application cliente qui utilise l'accès distant Remoting, vous dirigez votre application pour qu'elle communique avec le serveur en la configurant pour qu'elle utilise un type spécial de localisateur de ressources appelé un InvokerLocator, qui est une chaîne simple avec un format de type URL. Le serveur écoute les requêtes des ressources distantes sur un connecteur, qui est configuré comme faisant partie du sous-système remoting. Le connecteur transmet la demande à un ServerInvocationHandler configuré. Chaque ServerInvocationHandler implémente une méthode invoke(InvocationRequest), qui sait comment gérer la demande.
Le framework JBoss Remoting contient trois couches qui se miroîtent les unes par rapport aux autres côté client et côté serveur.
Couches de framework JBoss Remoting
- L'utilisateur interagit avec la couche externe. Côté client, la couche externe est la classe
Client, qui envoie des requêtes d'invocation. Côté serveur, c'est InvocationHandler, mis en œuvre par l'utilisateur, qui reçoit des demandes d'invocation. - Le transport est contrôlé par la couche d'invocateur.
- La couche inférieure contient le marshaller et le unmarshaller, qui convertit les formats de données en formats de transmission.
12.3.4.2. Remoting Callbacks
Lorsqu'un client Remoting (à distance) demande des informations du serveur, il peut y avoir un blocage et il faut alors attendre que le serveur réponde, mais ce n'est pas un comportement idéal. Pour permettre au client d'être à l'écoute des événements asynchrones sur le serveur et pour pouvoir continuer à faire d'autre tâches en attendant que le serveur complète la requête, votre application peut demander au serveur d'envoyer une notification quand il aura fini. C'est ce que l'on appelle un callback. Un client peut s'ajouter comme un écouteur d'événements asynchrones générés au nom d'un autre client, aussi bien. Il y a deux choix différents pour recevoir des callbacks : «pull callbacks» ou «push callbacks». Les clients vérifient les «pull callbacks» de façon synchrone, mais écoutent passivement les «push callbacks».
En substance, un callback fonctionne de cette façon: le serveur envoie une
InvocationRequest au client. Votre code côté serveur fonctionne de la même façon que le rappel soit synchrone ou asynchrone. Seul le client a besoin de connaître la différence. InvocationRequest du serveur envoie un responseObject au client. Il s'agit de la charge utile que le client a demandé. C'est peut-être une réponse directe à une demande ou à une notification d'événement.
Votre serveur suit aussi les listeners à l'aide d'un objet
m_listeners. Il contient une liste de tous les listeners qui ont été ajoutés à votre server handler. L'interface du ServerInvocationHandler inclut des méthodes qui vous permettent de gérer cette liste.
Le client gère les «pull callbacks» et les «push callbacks» de différentes manières. Dans les deux cas, il doit implémenter un callback hanler. Un callback handler est une implémentation de l'interface
org.jboss.remoting.InvokerCallbackHandler, qui traite les données de callback. Après l'implémentation du callback handler, soit vous vous ajoutez vous-même, en tant que listener de «pull callback», ou bien, vous installez un serveur de callbacks pour un «push callback».
Pull Callbacks
Pour un «pull callback», votre client s'ajoute à la liste du serveur des listeners à l'aide de la méthode Client.addListener(). Ensuite, il interroge le serveur périodiquement au sujet de l'exécution synchrone des données de callback. Ce sondage est effectué à l'aide de Client.getCallbacks().
Push Callback
Un «push callback» requiert que votre application cliente exécute elle-même son propre InvocationHandler. Pour ce faire, vous devez exécuter un service Remoting sur le client lui-même. Ceci s'appelle un callback server. Le callback server accepte les requêtes entrantes de façon asynchrone et les traite pour l'auteur de la demande (dans ce cas, le serveur). Pour inscrire le callback server de votre client avec le serveur principal, passez l'argument InvokerLocator du callback server comme deuxième argument à la méthode addListener.
12.3.4.3. Remoting Server Detection
Les clients et les serveurs d'accès distant peuvent se détecter les uns les autres automatiquement à l'aide de JNDI ou Multicast. Un détecteur Remoting Detector est ajouté aux client et serveur, et un NetworkRegistry est ajoutée au client.
Le détecteur côté serveur scanne périodiquement InvokerRegistry et extrait tous les invocateurs de serveur qu'il a créés. Il utilise ces informations pour publier un message de détection, qui contient le localisateur et les sous-systèmes pris en charge par chaque invocateur de serveur. Il publie ce message via une multidiffusion ou une liaison vers un serveur JNDI.
Côté client, le détecteur reçoit le message de multidiffusion ou interroge périodiquement le serveur JNDI pour récupérer les messages de détection. Si le détecteur remarque qu'un message de détection est pour un serveur d'accès distant nouvellement détecté, il l'inscrit dans NetworkRegistry. Le détecteur met également à jour NetworkRegistry s'il détecte qu'un serveur n'est plus disponible
12.3.4.4. Configurer le sous-système de Remoting
Aperçu
JBoss Remoting a trois éléments configurables de niveau supérieur : le pool de worker threads, un ou plusieurs connecteurs et une série de lien URI locaux et distants. Cette rubrique propose une explication pour chaque élément configurable, des exemples de commandes CLI pour savoir comment configurer chaque élément et un exemple XML d'un sous-système entièrement configuré. Cette configuration s'applique uniquement au serveur. La plupart des gens n'auront pas à configurer le sous-système de communication à distance, sauf s'ils utilisent des connecteurs personnalisés pour leurs propres applications. Les applications qui agissent comme des clients Remoting, comme les EJB, nécessitent une configuration distincte pour se connecter à un connecteur spécifique.
Note
La configuration du sous-système Remoting n'est pas exposée à la Console de gestion sur web, mais est entièrement configurable du Management CLI en ligne de commande. Il n'est pas recommandé de modifier le code XML à la main.
Adaptation des commandes CLI
Les commandes CLI sont formulées pour un domaine géré, lorsque vous configurez le profil par défaut. Pour configurer un profil différent, changez-en le nom. Pour un serveur autonome, omettre la section /profile=default de la commande.
Configuration en dehors du sous-système Remoting
Il y a un certain nombre d'aspects de configuration qui sont en dehors du sous-système remoting :
- Network Interface
- L'interface de réseau qui est utilisée par le sous-système
remotingest l'interfaceunsecuredéfinie dansdomain/configuration/domain.xmlou dansstandalone/configuration/standalone.xml.<interfaces> <interface name="management"/> <interface name="public"/> <interface name="unsecure"/> </interfaces>La définition par-hôte de l'interfaceunsecureest définie danshost.xmldans le même répertoire quedomain.xmloustandalone.xml. Cette interface est également utilisée par plusieurs autres sous-systèmes. Soyez vigilants quand vous la modifierez.<interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address:127.0.0.1}"/> </interface> <interface name="unsecure"> <!-- Used for IIOP sockets in the standard configuration. To secure JacORB you need to setup SSL --> <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/> </interface> </interfaces> - socket-binding
- La liaison-socket par défaut utilisée par le sous-système
remotingse lie au port TCP 4777. Reportez-vous à la documentation sur les liaisons de socket et de groupes de liaison du socket pour plus d'informations si vous avez besoin de procéder à une modification. - Remoting Connector Reference pour EJB
- Le sous-système EJB contient une référence vers le connecteur à distance pour les invocations de méthodes à distance. Voici la configuration par défaut :
<remote connector-ref="remoting-connector" thread-pool-name="default"/> - Configuration du transport sécurisé
- Les transports à distance (Remoting) utilisent StartTLS pour avoir une connexion sécurisée (HTTPS, Secure Servlet, etc.) si le client le demande. La même liaison de socket (port réseau) est utilisée pour les connexions sécurisées et non sécurisées, donc aucune configuration côté serveur supplémentaire n'est nécessaire. Le client demande le transport sécurisé ou non sécurisé, tel que le dictent ses besoins. Les composants JBoss Enterprise Application Platform qui utilisent Remoting, tels que les fournisseur JMS, EJB et ORB exigent des interfaces sécurisées par défaut.
Avertissement
StartTLS fonctionne en activant une connexion sécurisée si le client le demande au lieu de, par défaut, d'une connexion non sécurisée. StartTLS est, par nature, sensible à un exploit de style Man in the Middle, dans lequel un attaquant intercepte la demande du client et la modifie pour demander une connexion non sécurisée. Les clients doivent avoir reçu des écritures pour échouer correctement s'ils ne reçoivent pas une connexion sécurisée, sauf si une connexion non sécurisée constitue un fall-back approprié.
Worker Thread Pool
Un Worker Thread Pool est un ensemble de threads qui peuvent traiter les tâches qui arrivent par les connecteurs Remoting. Il s'agit d'un seul élément <worker-thread-pool>, et nécessite un certain nombre d'attributs. Régler ces attributs si vous avez des timeouts de réseau, ou si vous devez limiter l'utilisation de la mémoire. Les conseils varient suivant la situation dans laquelle vous vous trouvez. Contacter Red Hat Global Support Services pour obtenir davantage d'informations.
Tableau 12.1. Attributs de Worker Thread Pool
| Attribut | Description | Commande CLI |
|---|---|---|
| read-threads |
Le nombre de read-threads à créer pour le worker à distance. La valeur par défaut est
1.
| /profile=default/subsystem=remoting/:write-attribute(name=worker-read-threads,value=1)
|
| write-threads |
Le nombre de write-threads à créer pour le worker à distance. La valeur par défaut est
1.
| /profile=default/subsystem=remoting/:write-attribute(name=worker-write-threads,value=1)
|
| task-keepalive |
Le nombre de millisecondes pour conserver les threads de tâche de workers à distance non-core vivants. La valeur par défaut est
60.
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-keepalive,value=60)
|
| task-max-threads |
Le nombre de maximum de threads pour le Worker Task Thread Pool distant. La valeur par défaut est
60.
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-max-threads,value=16)
|
| task-core-threads |
Le nombre de threads principaux pour le Worker Task Thread Pool distant. La valeur par défaut est
4.
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-core-threads,value=4)
|
| task-limit |
Le nombre de maximum de tâches de worker distantes. La valeur par défaut est
16384.
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-limit,value=16384)
|
Connecteur
Le connecteur est le principal élément de configuration de Remoting (d'accès à distance). Les connecteurs multiples sont autorisés. Chacun se compose d'un élément <connector> avec plusieurs sous-éléments, ainsi que quelques attributs possibles. Le connecteur par défaut est utilisé par plusieurs sous-systèmes de JBoss Enterprise Application Platform. Des paramètres spécifiques pour les éléments et les attributs de vos connecteurs personnalisés dépendent de vos applications, donc contactez Red Hat Global Support Services pour plus d'informations.
Tableau 12.2. Attributs de connecteur
| Attribut | Description | Commande CLI |
|---|---|---|
| Nom | Le nom du connecteur, utilisé par JNDI. | /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=name,value=remoting-connector)
|
| socket-binding | Le nom de la liaison de socket à utiliser pour ce connecteur. | /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=socket-binding,value=remoting)
|
| authentication-provider |
Le module JASPIC (de l'anglais Java Authentication Service Provider Interface for Containers) à utiliser avec ce connecteur. Le module doit être dans le chemin de classes.
| /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=authentication-provider,value=myProvider)
|
| security-realm |
En option. Le domaine de la sécurité qui contient les utilisateurs, mots de passe et les rôles de votre application. Un EJB ou une Application Web peut authentifier sur un domaine de sécurité.
ApplicationRealm est disponible dans une installation de JBoss Enterprise Application Platform par défaut.
| /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=security-realm,value=ApplicationRealm)
|
Tableau 12.3. Éléments de connecteur
| Attribut | Description | Commande CLI |
|---|---|---|
| sasl |
Élément englobant des mécanismes d'authentification SASL (Simple Authentication and Security Layer)
| N/A
|
| properties |
Contient un ou plusieurs éléments
<property>, contenant chacun un attribut name et un attribut value optionnel.
| /profile=default/subsystem=remoting/connector=remoting-connector/property=myProp/:add(value=myPropValue)
|
Les connexions de sortie
Vous pouvez spécifier trois types différents d'attribut de connexion sortante :
- Connexion sortante vers un URI.
- Connexion sortante locale – se connectant à une ressource locale, comme un socket.
- Connexion sortante à distance – se connectant à une ressource à distance et s'authentifiant par l'intermédiaire d'un domaine de sécurité.
Toutes les connexions sortantes sont enfermées dans un élément
<outbound-connections>. Chacun de ces types de connexion prend un attribut outbound-socket-binding-ref. La connexion sortante-prend un attribut uri. La connexion sortante à prend les attributs facultatifs username (nom d'utilisateur) et security-realm (domaine de sécurité) à utiliser pour l'autorisation.
Tableau 12.4. Éléments de connexion sortante
| Attribut | Description | Commande CLI |
|---|---|---|
| outbound-connection | Connexion sortante standard | /profile=default/subsystem=remoting/outbound-connection=my-connection/:add(uri=http://my-connection)
|
| local-outbound-connection | Connexion sortante en schéma implicite local:// URI. | /profile=default/subsystem=remoting/local-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting2)
|
| remote-outbound-connection |
Connexions sortantes en schéma remote:// URI, utilisant l'authentification de base/digest avec domaine de sécurité.
| /profile=default/subsystem=remoting/remote-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting,username=myUser,security-realm=ApplicationRealm)
|
Éléments SASL
Avant de définir des éléments enfants SASL, vous devez créer l'élément SASL initial. Utiliser la commande suivante :
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:add
Les éléments enfants de l'élément SASL sont décrits dans le tableau ci-dessous.
| Attribut | Description | Commande CLI |
|---|---|---|
| include-mechanisms |
Contient un attribut
value, qui correspond à une liste de mécanismes SASL séparés par des espaces.
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=include-mechanisms,value=["DIGEST","PLAIN","GSSAPI"]) |
| qop |
Contient un attribut
value, qui correspond à une liste de valeurs de protection SASL séparées par des espaces, en ordre décroissant de préférence.
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=qop,value=["auth"]) |
| puissance |
Contient un attribut
value, qui correspond à une liste de valeurs de puissance cipher SASL séparées par des espaces, en ordre décroissant de préférence.
|
/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=strength,value=["medium"]) |
| reuse-session |
Contient un attribut
value, qui correspond à une valeur booléenne. Si sur true, tente de réutiliser les sessions.
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=reuse-session,value=false) |
| server-auth |
Contient un attribut
value, qui correspond à une valeur booléenne. Si sur true, le serveur s'authentifie auprès du client.
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=server-auth,value=false) |
| politique |
Un élément clôturé qui contient zéro ou plusieurs des éléments suivants, prenant chacun une seule
valeur.
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:add /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=forward-secrecy,value=true) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-active,value=false) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-dictionary,value=true) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-plain-text,value=false) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=pass-credentials,value=true) |
| properties |
Contient un ou plusieurs éléments
<property>, contenant chacun un attribut name et un attribut value optionnel.
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop:add(value=1) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop2:add(value=2) |
Exemple 12.11. Exemples de configurations
Cet exemple montre le sous-système à distance par défaut qui est fourni dans JBoss Enterprise Application Platform 6.
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>
Cet exemple contient de nombreuses valeurs hypothétiques, est est présenté de façon à pouvoir mettre les éléments et les attributs dont on a discuté plus haut en contexte.
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<worker-thread-pool read-threads="1" task-keepalive="60' task-max-threads="16" task-core-thread="4" task-limit="16384" write-threads="1" />
<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
<sasl>
<include-mechanisms value="GSSAPI PLAIN DIGEST-MD5" />
<qop value="auth" />
<strength value="medium" />
<reuse-session value="false" />
<server-auth value="false" />
<policy>
<forward-secrecy value="true" />
<no-active value="false" />
<no-anonymous value="false" />
<no-dictionary value="true" />
<no-plain-text value="false" />
<pass-credentials value="true" />
</policy>
<properties>
<property name="myprop1" value="1" />
<property name="myprop2" value="2" />
</properties>
</sasl>
<authentication-provider name="myprovider" />
<properties>
<property name="myprop3" value="propValue" />
</properties>
</connector>
<outbound-connections>
<outbound-connection name="my-outbound-connection" uri="htt\
p://myhost:7777/"/>
<remote-outbound-connection name="my-remote-connection" outbound-socket-binding-ref="my-remote-socket" username="myUser" security-realm="ApplicationRealm"/>
<local-outbound-connection name="myLocalConnection" outbound-socket-binding-ref="my-outbound-socket"/>
</outbound-connections>
</subsystem>
Aspects de la configuration non encore documentés
- JNDI et Détection automatique multi diffusion
12.3.4.5. Utilisation des domaines de sécurité avec les clients EJB distants
Une façon d'ajouter la sécurité aux clients qui font appel aux EJB à distance consiste à utiliser des domaines de sécurité. Un domaine de la sécurité est une simple base de données de paires nom d'utilisateur/mot de passe et nom d'utilisateur/rôle. La terminologie est également utilisée dans le cadre de conteneurs web, avec un sens légèrement différent.
Pour authentifier un EJB par un nom d'utilisateur ou un mot de passe particulier existant déjà dans un domaine de sécurité, suivre les étapes suivantes :
- Ajouter un nouveau domaine de sécurité au contrôler de domaine ou au serveur autonome.
- Ajoutez les paramètres suivants au fichier
jboss-ejb-client.properties, qui est dans le chemin de classes de l'application. Cet exemple suppose que la connexion est appeléepar défautpar les autres paramètres qui se trouvent dans le fichier.remote.connection.default.username=appuser remote.connection.default.password=apppassword
- Créer un connecteur Remoting personnalisé sur le domaine ou sur le serveur autonome, qui utilise le nouveau domaine de sécurité.
- Déployer votre EJB dans le groupe de serveur configuré pour utiliser le profil avec le connecteur Remoting personnalisé, ou dans le serveur autonome si vous n'utilisez pas de domaine géré.
12.3.4.6. Ajout d'un Domaine de sécurité
Éxécuter le Management CLI.
Démarrer par la commandejboss-cli.shoujboss-cli.batet connectez-vous au serveur.Créer le nouveau domaine de sécurité lui-même.
Exécutez la commande suivante pour créer un nouveau domaine de sécurité nomméMyDomainsur un contrôleur de domaine ou sur un serveur autonome./host=master/core-service=management/security-realm=MyDomainRealm:add()
Créer les références du fichier de propriétés qui stocke les informations sur le nouveau rôle.
Exécuter la commande suivante pour créer un pointeur au fichier nommémyfile.properties, qui contiendra les propriétés attachées au nouveau rôle.Note
Le fichier de propriétés nouvellement créées n'est pas géré par les scriptsadd-user.shetadd-user.batinclus. Il devra être administré en externe./host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
Résultat
Votre nouveau domaine de sécurité est créé. Lorsque vous ajoutez des utilisateurs et des rôles à ce nouveau domaine, l'information va être stockée dans un fichier séparé des domaines de sécurité par défaut. Vous pouvez gérer ce nouveau fichier à l'aide de vos propres applications ou procédures.
12.3.4.7. Ajout d'un utilisateur à un Domaine de sécurité
Éxécuter la commande
add-user.shouadd-user.bat.Ouvrez un shell d'interface en ligne de commande (CLI). Changez de répertoireEAP_HOME/bin/. Si vous exécutez Red Hat Enterprise Linux ou un autre système d'exploitation style UNIX, exécutezadd-user.sh. Si vous exécutez sur un serveur Microsoft Windows, exécutezadd-user.bat.Choisissez d'ajouter un Utilisateur de gestion ou un Utilisateur d'application.
Pour cette procédure, saisirbpour ajouter un Utilisateur d'application.Choisir le domaine dans lequel l'utilisateur sera ajouté.
Par défaut, le seul domaine disponible estApplicationRealm. Si vous avez ajouté un domaine personnalisé, vous pouvez saisir son nom à la place.Saisir le nom d'utilisateur, le mot de passe et les rôles lorsque vous y serez invité.
Saisir le nom d'utilisateur, le mot de passe et les rôles lorsque vous y serez invité. Vérifiez votre choix en tapantyes, ounopour annuler les changements. Les changements sont inscrits dans les fichiers de propriétés du domaine de sécurité.
12.3.4.8. Accès EJB à distance utilisant le cryptage SSL
Par défaut, le trafic réseau pour les RMI (Remote Method Invocation) des Beans EJB2 et EJB3 n'est pas crypté. Dans le cas où le cryptage est requis, SSL (Secure Sockets Layer) peut être utilisé afin que la connexion entre le client et le serveur soit cryptée. L'utilisation SSL a l'avantage supplémentaire de permettre au trafic réseau de traverser les pare-feu qui bloquent le port RMI.
12.4. Sécurité Application JAX-RS
12.4.1. Activer la sécurité basée-rôle pour RESTEasy JAX-RS Web Service
Résumé
RESTEasy supporte les annotations @RolesAllowed, @PermitAll, et @DenyAll sur les méthodes JAX-RS. Cependant, il ne reconnaît pas ces annotations par défaut. Suivre les étapes suivantes pour configurer le fichier web.xml et pour activer la sécurité basée-rôle.
Avertissement
Ne pas activer la sécurité basée-rôle si l'application utilise les EJB. Le conteneur EJB procurera la fonctionnalité à la place de RESTEasy.
Procédure 12.1. Activer la sécurité basée-rôle pour RESTEasy JAX-RS Web Service
- Ouvrir le fichier
web.xmlde l'application dans l'éditeur de textes. - Ajouter le <context-param> suivant au fichier, dans les balises
web-app:<context-param> <param-name>resteasy.role.based.security</param-name> <param-value>true</param-value> </context-param> - Déclarer tous les rôles utilisés dans le fichier RESTEasy JAX-RS WAR file, en utilisant les balises de <security-role>:
<security-role><role-name>ROLE_NAME</role-name></security-role><security-role><role-name>ROLE_NAME</role-name></security-role> - Autorise l'accès à tous les URL gérés par le runtime JAX-RS pour tous les rôles :
<security-constraint><web-resource-collection><web-resource-name>Resteasy</web-resource-name><url-pattern>/PATH</url-pattern></web-resource-collection><auth-constraint><role-name>ROLE_NAME</role-name><role-name>ROLE_NAME</role-name></auth-constraint></security-constraint>
Résultat
La sécurité basée rôle à été activée dans l'application, avec un certain nombre de rôles définis.
Exemple 12.12. Exemple de Configuration de sécurité basée rôles.
<web-app>
<context-param>
<param-name>resteasy.role.based.security</param-name>
<param-value>true</param-value>
</context-param>
<servlet-mapping>
<servlet-name>Resteasy</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>Resteasy</web-resource-name>
<url-pattern>/security</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>user</role-name>
</security-role>
</web-app>
12.4.2. Sécuriser un service JAX-RS Web par des annotations
Résumé
Cette rubrique couvre les étapes à parcourir pour sécuriser un service JAX-RS Web par les annotations de sécurité supportées.
Procédure 12.2. Sécuriser un service JAX-RS Web par des annotations de sécurité supportées.
- Activer la sécurité basée-rôle. Pour plus d'informations, voir Section 12.4.1, « Activer la sécurité basée-rôle pour RESTEasy JAX-RS Web Service ».
- Ajouter des annotations de sécurité au service JAX-RS Web. RESTEasy supporte les annotations suivantes :
- @RolesAllowed
- Définit les rôles qui peuvent accéder à la méthode. Tous les rôles doivent être définis dans le fichier
web.xml. - @PermitAll
- Autorise tous les rôles définis dans le fichier
web.xmlà accéder à la méthode. - @DenyAll
- Refuse tout accès à la méthode.
12.5. Protocole Mots de passes Distants Sécurisés
12.5.1. Protocole pour Mots de passes distants sécurisés (SRP pour Secure Remote Password)
Le protocole SRP est l'implémentation d'une poignée de main d'échange de clés publiques décrite dans Internet Standards Working Group Request For Comments 2945 (RFC2945). L'extrait de RFC2945 énonce ce qui suit :
Ce document décrit un mécanisme d'authentification de réseau à cryptage puissant connu comme le nom de protocole SRP (Secure Remote Password). Ce mécanisme est approprié pour négocier des connexions sécurisées avec un mot de passe fourni par l'utilisateur, tout en éliminant les problèmes de sécurité traditionnellement associées à des mots de passe réutilisables. Ce système effectue également un échange de clé sécurisé dans le processus d'authentification, ce qui permet à ce que des couches de sécurité (protection de la vie privée et/ou de l'intégrité) soient activées lors de la session. Il n'est nul besoin de serveurs de clés de confiance ou d'infrastructures de certificats, et les clients ne sont pas tenus de stocker ou de gérer des clés à long terme. SRP offre des avantages tant au niveau de la sécurité qu'au niveau déploiement sur les techniques existantes de stimulation / réponse, ce qui en fait un remplacement idéal pour les besoins d'authentification de mots de passe sécurisés.
On trouvera la description complète de la spécification RFC2945 à http://www.rfc-editor.org/rfc.html. Vous trouverez plus d'informations sur l'algorithme SRP et son historique à http://srp.stanford.edu/.
Les algorithmes Diffie-Hellman et RSA sont connus comme algorithmes d'échange de clés publiques. Le concept d'algorithmes à clé publique est d'avoir deux clés, une publique accessible à tous et une privée et uniquement connue par vous-même. Quand des personnes veulent vous envoyer des informations cryptées, ils cryptent les informations à l'aide de votre clé publique. Vous seul êtes capable de déchiffrer les informations à l'aide de votre clé privée. Cela contraste avec les systèmes de déchiffrage de mots de passe partagés plus traditionnels qui exigent que l'émetteur et le récepteur partagent le mot de passe. Les algorithmes à clé publiques éliminent le besoin de partager des mots de passe.
12.5.2. Configuration du protocole ISRP (Secure Remote Password)
Afin d'utiliser le protocole SRP (Secure Remote Password) dans votre application, vous devrez tout d'abord créer un MBean qui implémente l'interface
SRPVerifierStore. Vous trouverez des informations sur l'implémentation à Implémentation SRPVerifierStore.
Procédure 12.3. Intégrer le store de mots de passe existant
Créer un store d'informations de mots de passe hachés.
Si vos mots de passe sont déjà stockés sous une forme hachée irréversible, vous aurez besoin de faire cela sur la base utilisateur.Vous pouvez implémenter unsetUserVerifier(String, VerifierInfo)en tant que méthode noOp, ou d'une méthode qui envoie une exception signifiant que le store est en lecture-seule.Créer l'interface SRPVerifierStore.
Créer une implémentation d'interfaceSRPVerifierStorepersonnalisée qui puisse obtenirVerifierInfodu store que vous avez créé.LeverifyUserChallenge(String, Object)peut servir à intégrer des schémas basés token de matériel existant comme SafeWord ou Radius dans l'algorithme SRP. Cette méthode d'interface est appelée uniquement lorsque la configuration SRPLoginModule du client spécifie l'option hasAuxChallenge.Créer le MBean JNDI.
Créer un MBean qui expose l'interfaceSRPVerifierStoredisponible à JNDI, et expose tous les paramètres configurables requis.Le serviceorg.jboss.security.srp.SRPVerifierStoreServicepar défaut vous permet d'implémenter ceci. Vous pouvez également implémenter le MBean par une implémentation de fichier de propriétés Java duSRPVerifierStore.
Implémentation SRPVerifierStore
L'implémentation par défaut de l'interface SRPVerifierStore n'est pas recommandée pour les systèmes de production, car elle exige que toutes les informations de hachage de mot de passe soient disponibles sous forme de fichier d'objets sérialisés.
L'implémentation du
SRPVerifierStore fournit un accès à l'objet SRPVerifierStore.VerifierInfo pour un nom d'utilisateur donné. La méthode getUserVerifier(String) est appelée par le SRPService au départ d'une session SRP utilisateur pour obtenir les paramètres requis par l'algorithme SRP.
Éléments d'un Objet VerifierInfo
- nom d'utilisateur
- Le nom d'utilisateur ou l'ID utilisateur pour s'authentifier
- verifier
- Un hachage unidirectionnel du mot de passe que l'utilisateur saisit comme preuve d'identité. La classe
org.jboss.security.Utilinclut une méthodecalculateVerifierqui exécute l'algorithme de hachage de mot de passe. Le mot de passe de sortie prend la formeH(salt | H(username | password)), oùHest la fonction de hachage sécurisée SHA, telle que définie par RFC2945. Le nom d'utilisateur est converti d'une chaîne en un byte [] en utilisant le codage UTF-8. - salt
- Un nombre aléatoire utilisé pour augmenter la difficulté d'une attaqe de force brute de dictionnaire sur la base de données de mot de passe de vérification dans le cas où la base de données soit compromise. La valeur doit être générée à partir d'un algorithme de cryptage fort composé de nombres aléatoires lorsque le mot de passe en texte clair existant de l'utilisateur est haché.
- g
- Le générateur primitif d'algorithme SRP. Cela peut être un paramètre fixe bien connu plutôt qu'un paramètre par utilisateur. La classe d'utilitaire de
org.jboss.security.srp.SRPConffournit plusieurs paramètres pourg, avec une valeur par défaut appropriée obtenue par l'intermédiaire deSRPConf.getDefaultParams().g(). - N
- SRP algorithm safe-prime modulus. Cela peut être un paramètre fixe bien connu, plutôt qu'un paramètre par utilisateur. La classe d'utilitaire de
org.jboss.security.srp.SRPConffournit plusieurs paramètres pour «N», y compris un bon nombre de valeurs par défaut obtenues viaSRPConf.getDefaultParams().N().
Exemple 12.13. L'interface SRPVerifierStore
package org.jboss.security.srp;
import java.io.IOException;
import java.io.Serializable;
import java.security.KeyException;
public interface SRPVerifierStore
{
public static class VerifierInfo implements Serializable
{
public String username;
public byte[] salt;
public byte[] g;
public byte[] N;
}
public VerifierInfo getUserVerifier(String username)
throws KeyException, IOException;
public void setUserVerifier(String username, VerifierInfo info)
throws IOException;
public void verifyUserChallenge(String username, Object auxChallenge)
throws SecurityException;
}
Chapitre 13. Single Sign On (SSO)
13.1. SSO (Single Sign On) pour les Applications Web
Aperçu
Single Sign On (SSO) autorise l'authentification à une ressource, en vue d'autoriser implicitement l'accès à d'autres ressources.
SSO clusterisés ou non-clusterisés
SSO Non-clusterisé limite le partage des informations d'autorisation pour les applications d'un même hôte virtuel. En outre, il n'y a aucun mécanisme de résilience en cas de défaillance de l'hôte. Les données d'authentification SSO clusterisées peuvent être partagées entre les applications de plusieurs hôtes virtuels et sont résistants au basculement. De plus, SSO clusterisé est capable de recevoir des demandes d'un équilibreur de charges.
La façon dont SSO fonctionne
Si une ressource n'est pas protégée, un utilisateur n'a pas besoin de s'authentifier. Si un utilisateur accède à une ressource protégée, l'utilisateur devra s'authentifier.
Si l'authentification réussit, les rôles associés à l'utilisateur seront stockés et utilisés pour l'autorisation de toutes les ressources associées.
Si l'utilisateur se déconnecte d'une application, ou bien si l'application produit la session par programmation, toutes les données d'autorisation persistées seront retirées, et le processus recommencera.
Un timeout de session ne rend pas la session SSO valide si d'autres sessions sont encore valides.
Les limitations de SSO
- Aucune propagation au-delà des limites de tierce-parties.
- SSO ne peut être utilisé qu'entre des applications déployées au sein de conteneurs JBoss EAP.
- Authentification gérée-conteneur uniquement.
- Vous devez utiliser des éléments d'authentification géré-conteneurs, comme
<login-config>dans leweb.xmlde votre application. - Nécessite des cookies.
- SSO se maintient par des cookies de navigateur et la ré-écriture d'URL n'est pas prise en charge.
- Limitations de domaine et de domaine de sécurité
- À moins que le paramètre
requireReauthenticationsoit défini àtrue, toutes les applications web configurées pour la même valve SSO doivent partager la même configuration Realm dansweb.xmlet le même domaine de sécurité.Vous pouvez imbriquer l'élément Realm à l'intérieur de l'élément Hôte ou de l'élément Engine environnant, mais pas à l'intérieur d'un élément context.xml pour une des applications web concernéesLe<security-domain>configuré dansjboss-web.xmldoit être consistant à travers toutes les applications web.Toutes les intégrations de sécurité doivent pouvoir accepter les mêmes informations d'autorisation (comme les noms d'utilisateur et mots de passe).
13.2. SSO (Single Sign On) clusterisées pour les Applications Web
SSO (Single Sign On) est la possibilité pour les utilisateurs de s'authentifier à une application web unique au moyen d'une authentification réussie, afin d'obtenir l'autorisation de plusieurs autres applications. SSO clusterisée stocke les informations d'authentification et d'autorisation dans un cache clusterisé. Cela permet aux applications de serveurs différents de partager l'information et rend également l'information résistante à une défaillance de l'un des hôtes.
Une configuration SSO s'appelle une vanne. Une vanne est connectée à un domaine de sécurité, qui est configuré au niveau du serveur ou du groupe de serveurs. Chaque application qui doit partager les mêmes informations d'authentification mises en cache est configurée pour utiliser la même valve. Cette configuration s'effectue dans le fichier
jboss-Web.xml de l'application.
Voici quelques valves SSO standards prises en charge par le sous-système de JBoss Enterprise Application Platform:
- Apache Tomcat ClusteredSingleSignOn
- Apache Tomcat IDPWebBrowserSSOValve
- SSO basée-SPNEGO de PicketLink
Suivant le type particulier de valve, vous aurez sans doute besoin d'ajouter des configurations supplémentaires au domaine de sécurité, pour que votre valve puisse fonctionner normalement.
13.3. Choisir l'implémentation SSO qui vous convient
JBoss Enterprise Application Platform exécute des applications de JBoss Enterprise Edition (EE), qui peuvent être des applications web, des applications EJB, des services web ou autres. SSO (Single Sign On) permet de propager les informations de contexte et d'identité de sécurité entre ces applications. Selon les besoins de votre organisation, il existe des solutions SSO différentes. La solution que vous utiliserez dépendra du fait que vous utilisez des applications web, les applications EJB ou des services web; si vos applications s'exécutent sur le même serveur, plusieurs serveurs non-clusterisés ou plusieurs serveurs clusterisés; ou si vous souhaitez l'intégrer dans un système d'authentification basé-bureau où vous avez seulement besoin d'authentification entre vos applications.
SSO Desktop basé-Kerberos
Si votre organisation utilise déjà une authentification basée Kerberos et un système d'autorisation comme Microsoft Active Directory, vos pourrez utiliser les mêmes systèmes pour vous authentifier de façon transparente à vos applications enterprise en cours d'exécution sur JBoss Enterprise Application Platform.
SSO Application Web et Non clusterisée
Si vous avez besoin de propager des informations de sécurité entre des applications qui s'exécutent dans le même groupe de serveurs ou instance, vous pourrez utiliser le SSO non-clusterisé. Cela implique uniquement la configuration de la valve dans le descripteur de jboss-web.xml de votre application.
SSO Application Web et clusterisée
Si vous avez besoin de propager des informations de sécurité entre des applications qui s'exécutent dans un environnement clusterisé sur plusieurs instances de JBoss Enterprise Application Platform, vous pourrez utiliser la valve SSO clusterisée. Ce paramètre est configuré dans le fichierjboss-Web.xml de votre application.
13.4. Utilisation de SSO (Single Sign On) pour les Applications Web
Aperçu
Les fonctionnalités SSO (Single Sign On) sont fournies par les sous-systèmes web et Infinispan. Utiliser cette procédure pour configurer SSO dans les applications web.
Prérequis
- Vous devez avoir un domaine de sécurité configuré qui gère les authentifications et autorisations.
- Le sous-système
infinispandoit être présent. Il se trouve dans le profilcomplet-hapour un domaine géré, ou en utilisant la configurationstandalone-full-ha.xmldans un serveur autonome. - Le
webcache-conteneuret le cache-conteneur SSO doivent chacun être présents. Les exemples de fichiers de configurations contiennent déjà le cache-conteneurweb, et certaines des configurations contiennent déjà le cache-conteneur SSO également. Utilisez les commandes suivantes pour vérifier et activer le cache conteneur SSO. Notez que ces commandes modifient le profilfulld'un domaine géré. Vous pouvez modifier les commandes pour utiliser un profil différent, ou supprimer la portion/profile=fullde la commande, pour un serveur autonome.Exemple 13.1. Vérifier le cache-conteneur
webLes profils et les configurations mentionnées ci-dessus incluent le cache-conteneurwebpar défaut. Utilisez la commande suivante pour vérifier sa présence. Si vous utilisez un profil différent, remplacez par son nom à la place deha./profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=false,proxies=false,include-runtime=false,include-defaults=true)
Si le résultat affiche unsuccess, le sous-système sera présent. Sinon, vous devrez l'ajouter.Exemple 13.2. Ajouter le cache-conteneur
webUtiliser les trois commandes suivantes pour activer le cache-conteneurwebà votre configuration. Modifier le nom du profil selon le cas, ainsi que les autres paramètres. Ici, les paramètres sont ceux utilisés dans une configuration par défaut./profile=ha/subsystem=infinispan/cache-container=web:add(aliases=["standard-session-cache"],default-cache="repl",module="org.jboss.as.clustering.web.infinispan")
/profile=ha/subsystem=infinispan/cache-container=web/transport=TRANSPORT:add(lock-timeout=60000)
/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode="ASYNC",batching=true)
Exemple 13.3. Vérifier le cache-conteneur
SSOÉxécuter la commande de Management CLI suivante :/profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
Chercher une sortie qui ressemble à ceci :"sso" => {Si vous ne la trouvez pas, le cache-conteneur ne sera pas présent dans votre configuration.Exemple 13.4. Ajouter le cache-conteneur
SSO/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)
- Le sous-système
webdoit être configuré pour utiliser SSO. La commande suivante active SSO sur le serveur virtuel appelédefault-hostet le domaine de cookiesdomaine.com. Le nom de cache estsso, et une nouvelle authentification est désactivée./profile=ha/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")
- Chaque application qui partage les informations SSO doit être configurée pour utiliser le même <security-domain> dans son descripteur de déploiement de
jboss-web.xmlet le même Realm dans son fichier de configurationweb.xml.
Différences entre les valves clusteriées et les valves non-clusterisées
SSO clusterisée permet le partage d'authentification entre des hôtes distincts, tandis que ce n'est pas le cas pour SSO non-clusterisée. Les valves SSO en cluster et non clusterisées sont configurées de la même manière, mais SSO clusterisée comprend les paramètres cacheConfig, processExpiresInterval et maxEmptyLife, qui contrôlent la réplication en groupement des données persistantes.
Exemple 13.5. Exemple de configuration SSO clusterisée
Comme les configurations SSO clusterisées ou non sont si semblables, on ne montre que la configuration clusterisée. Cet exemple utilise un domaine de sécurité nommé
tomcat.
<jboss-web> <security-domain>tomcat</security-domain> <valve> <class-name>org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn</class-name> <param> <param-name>maxEmptyLife</param-name> <param-value>900</param-value> </param> </valve> </jboss-web>
Tableau 13.1. Options de configuration SSO
| Option | Description |
|---|---|
| cookieDomain |
Domaine hôte utilisé pour les cookies SSO. La valeur par défaut est
/. Pour permettre à app1.xyz.com et à app2.xyz.com de partager les cookies SSO, vous devrez définir le cookieDomain à xyz.com.
|
| maxEmptyLife |
SSO clusterisée uniquement. Le nombre maximum de secondes qu'une valve SSO sans sessions actives sera utilisable par une demande, avant d'expirer. Une valeur positive permet une manipulation appropriée d'arrêt d'un nœud si c'est le seul avec des sessions actives attachées à la valve. Si maxEmptyLife est défini sur
0, la vanne se terminera en même temps que les copies de la session locale, mais des copies de sauvegarde des sessions, des applications en cluster, seront disponibles à d'autres nœuds du cluster. PSi on permet à la vanne à vivre au-delà de la durée de ses sessions gérées, cela donne du temps à l'utilisateur d'effectuer une autre demande qui puisse basculer sur un nœud différent, où il active la copie de sauvegarde de la session. La valeur par défaut, est de 1800 secondes (30 minutes).
|
| processExpiresInterval |
SSO clusterisé uniquement. Le nombre minimum de secondes entre les efforts de la valve pour trouver et invalider des instances SSO qui ont expiré le délai d'attente de
MaxEmptyLife. La valeur par défaut est de 60 (1 minute).
|
| requiresReauthentication |
Si true, chaque requête utilise des informations d'authentification en cache pour authentifier à nouveau le domaine de sécurité. Si false (la valeur par défaut), une cookie SSO valide sera suffisante pour que la valve puisse authentifier chaque nouvelle requête.
|
Rendre une session non valide
Une application peut rendre invalide une session en invoquant la méthode javax.servlet.http.HttpSession.invalidate().
13.5. Kerberos
Kerberos est un protocole d'authentification réseau pour les applications client/serveur. Il permet l'authentification sur un réseau non sécurisé en toute sécurité, à l'aide de la clé secrète de cryptographie symétrique.
Kerberos utilise les tokens de sécurité appelés «tickets». Pour utiliser un service sécurisé, vous devez obtenir un ticket auprès du Ticket Granting Service (TGS), qui est un service de délivrance de tickets exécuté sur un serveur sur votre réseau. Après avoir obtenu le ticket, vous pourrez demander un Ticket de Service (ST ou Service Ticket) d'un Service d'authentification (AS), qui est un autre service s'exécutant sur votre réseau. Utilisez ensuite ST pour vous authentifier auprès du service que vous souhaitez utiliser. Les TGS et AS tous exécutent tous deux à l'intérieur d'un service intégré appelé KDC (Key Distribution Center).
Kerberos est conçu pour être utilisé dans un environnement client-serveur et est rarement utilisé dans les applications Web ou des environnements clients légers. Cependant, de nombreuses organisations utilisent déjà un système Kerberos pour l'authentification desktop et préfèrent réutiliser leur système existant plutôt que d'en créer un second pour leurs applications web. Kerberos est partie intégrante de Microsoft Active Directory et est également utilisé dans de nombreux environnements Red Hat Enterprise Linux.
13.6. SPNEGO
Simple and Protected GSS_API Negotiation Mechanism (SPNEGO) propose un mécanisme d'expension d'environnement SSO (Single Sign On) pour les applications web.
Lorsqu'une application d'ordinateur client, comme un navigateur web, tente d'accéder à une page de protection sur le serveur web, le serveur répond qu'une autorisation est requise. Ensuite, l'application demande un ticket de service du Centre de distribution des clés Kerberos (KDC). Après l'obtention du ticket, l'application le renvoie dans une requête formatée SPNEGO et l'envoie à l'application web, par l'intermédiaire du navigateur. Le conteneur web exécutant l'application web déployée ouvre la requête et authentifie le billet. Après une authentification réussie, l'accès est accordé.
SPNECO fonctionne avec tous les types de fournisseurs Kerberos, y compris le service Kerberos inclus dans Red Hat Enterprise Linux et le serveur Kerberos, qui fait partie intégrale du Microsoft Active Directory.
13.7. Microsoft Active Directory
Microsoft Active Directory est un service de répertoires développé par Microsoft pour authentifier les utilisateurs et les ordinateurs d'un domaine Microsoft Windows. Il est inclus dans Microsoft Windows Server. L'ordinateur dans Microsoft Windows Server est nommé le Contrôleur de domaine. Les serveurs de Red Hat Enterprise Linux exécutant le service Samba peuvent aussi agir comme Contrôleur de domaine dans ce type de réseau.
Active Directory repose sur trois technologies principales dépendantes les unes des autres :
- LDAP (Lightweight Directory Access Protocol), qui stocke les informations utilisateurs, ordinateurs, mots de passe et autres ressources.
- Kerberos qui procure une authentification sécurisée sur le réseau.
- DNS (Domain Service Name) qui fournit des mappages entre les adresses IP, les noms d'hôtes et les ordinateurs ou autres périphériques du réseau.
13.8. Configuration de Kerberos ou Microsoft Active Directory Desktop SSO pour les applications web
Introduction
Pour authentifier vos applications web ou EJB à l'aide de l'authentification basée sur Kerberos existante de votre organisation et de votre infrastructure d'autorisation, comme Microsoft Active Directory, vous pouvez utiliser les fonctionnalités de JBoss Negotation intégrées dans JBoss Enterprise Application Platform 6. Si vous configurez votre application web correctement, une connexion réussie en desktop ou réseau sera suffisante pour vous authentifier en toute transparence dans votre application web, donc aucune invite de connexion supplémentaire ne sera nécessaire.
Différence par rapport aux versions précédentes de la plateforme
Il existe des différences notables entre la plateforme JBoss Enterprise Application Platform 6 et les versions précédentes :
- Les domaines de sécurité sont configurés centralement, pour chaque profil d'un domaine géré, ou pour chaque serveur autonome. Ils ne font pas partie du déploiement lui-même. Le domaine de sécurité qu'un déploiement doit utiliser est nommé dans le fichier de déploiement
jboss-web.xmloujboss-ejb3.xml. - Les propriétés de sécurité sont configurées dans le cadre du domaine de sécurité, faisant partie de sa configuration centrale. Elles ne font pas partie du déploiement.
- Vous pouvez ne plus remplacer les authentificateurs dans votre déploiement. Toutefois, vous pouvez ajouter une valve NegotiationAuthenticator à votre descripteur
jboss-web.xmlafin d'obtenir le même effet. La valve nécessite toujours les éléments<security-constraint>et<login-config>à définir dans le fichierweb.xml. Ils servent à décider quelles ressources sont sécurisées. Cependant, l'auth-method choisie sera être substituée par la valve NegotiationAuthenticator du fichierjboss-web.xml. - Les attributs
CODEdes domaines de sécurité utilisent maintenant un nom simple au lieu d'un nom de classe complet. Le tableau suivant montre les mappages entre les classes utilisées pour JBoss Negotiation, et leurs classes.
Tableau 13.2. Codes de modules de connexion et Noms de classes
| Nom simple | Nom de classe | But |
|---|---|---|
| Kerberos | com.sun.security.auth.module.Krb5LoginModule | Module de connexion Kerberos |
| SPNEGO | org.jboss.security.negotiation.spnego.SPNEGOLoginModule | Le mécanisme qui permet aux applications web de s'authentifier à votre serveur d'authentification Kerberos. |
| AdvancedLdap | org.jboss.security.negotiation.AdvancedLdapLoginModule | Utilisé avec les serveurs LDAP autres que Microsoft Active Directory. |
| AdvancedAdLdap | org.jboss.security.negotiation.AdvancedADLoginModule | Utilisé avec les serveurs Microsoft Active Directory LDAP. |
Jboss Negotiation Toolkit
JBoss Negotiation Toolkit est un outil de débogage que vous pouvez télécharger à partir de https://community.jboss.org/servlet/JiveServlet/download/16876-2-34629/jboss-negotiation-toolkit.war. Il est fourni comme un outil supplémentaire pour vous aider à déboguer et tester les mécanismes d'authentification avant d'introduire votre application en production. C'est un outil non pris en charge, mais considéré comme très utile. Comme SPNEGO, cet outil peut être difficile à configurer pour les applications web.
Procédure 13.1. Installation de l'authentification SSO (Single Sign On) pour les Applications Web ou EJB
Configurer un domaine de sécurité qui représente l'identité de votre serveur. Définir les propriétés système si nécessaire.
Le premier domaine de sécurité authentifie le conteneur lui-même au service de répertoires. Il a besoin d'utiliser un module de connexion qui accepte un type de mécanisme de connexion statique, car un utilisateur réel n'est pas impliqué. Cet exemple utilise une entité de sécurité statique et fait référence à un fichier keytab qui contient les informations d'identification.Le code XML est donné ici dans un but de clarification, mais vous devez utiliser la Console de gestion ou le Management CLI pour configurer vos domaines de sécurité.<security-domain name="host" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="host/testserver@MY_REALM"/> <module-option name="keyTab" value="/home/username/service.keytab"/> <module-option name="doNotPrompt" value="true"/> <module-option name="debug" value="false"/> </login-module> </authentication> </security-domain>Configurer un second domaine de sécurité pour sécuriser l'application web ou les applications. Définir les propriétés système si nécessaire.
Le deuxième domaine de sécurité est utilisé pour authentifier l'utilisateur particulier au serveur d'authentification Kerberos ou SPNEGO. Vous avez besoin d'au moins un module de connexion pour authentifier l'utilisateur et un autre à la recherche de rôles à appliquer à l'utilisateur. Le code XML suivant montre un exemple de domaine de sécurité SPNEGO. Il inclut un module d'autorisation pour mapper les rôles aux utilisateurs individuels. Vous pouvez également utiliser un module de recherche pour les rôles sur le serveur d'authentification lui-même.<security-domain name="SPNEGO" cache-type="default"> <authentication> <!-- Check the username and password --> <login-module code="SPNEGO" flag="requisite"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="host"/> </login-module> <!-- Search for roles --> <login-module code="UserRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass" /> <module-option name="usersProperties" value="spnego-users.properties" /> <module-option name="rolesProperties" value="spnego-roles.properties" /> </login-module> </authentication> </security-domain>Spécifier la security-constraint et la login-config dans le fichier
web.xmlLe descripteurweb.xmlcontient des informations sur les contraintes de sécurité et sur la configuration de la connexion. En voici des exemples :<security-constraint> <display-name>Security Constraint on Conversation</display-name> <web-resource-collection> <web-resource-name>examplesWebApp</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>RequiredRole</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>SPNEGO</auth-method> <realm-name>SPNEGO</realm-name> </login-config> <security-role> <description> role required to log in to the Application</description> <role-name>RequiredRole</role-name> </security-role>Indiquer le domaine de sécurité et les autres paramètres dans le descripteur
jboss-web.xml.Spécifiez le nom du domaine de la sécurité côté client (l'autre dans cet exemple) dans le descripteurjboss-Web.xmlde votre déploiement, pour obliger votre application à utiliser ce domaine de sécurité.Vous ne pouvez plus remplacer les authentificateurs directement. À la place, vous devez ajouter NegotiationAuthenticator comme valve au descripteurjboss-web.xmlsi nécessaire.<jacc-star-role-allow>vous permet d'utiliser un astérisque (*) pour faire correspondre plusieurs noms de rôles, et est optionnel.<jboss-web> <security-domain>java:/jaas/SPNEGO</security-domain> <valve> <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> </valve> <jacc-star-role-allow>true</jacc-star-role-allow> </jboss-web>Ajouter une dépendance au
MANIFEST.MFde votre application, pour trouver l'emplacement des classes Negotiation.L'application web a besoin d'une dépendance sur la classeorg.jboss.security.negotiationà ajouter au manifesteMETA-INF/MANIFEST.MFdu déploiement pour pouvoir localiser les classes JBoss Negotiation. Ce qui suit vous montre une entrée formatée correctement.Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.jboss.security.negotiation
Résultat
Votre application web accepte et authentifie les informations d'identification avec Kerberos, Active Directory de Microsoft ou autre service de répertoire compatible SPNEGO. Si l'utilisateur exécute l'application d'un système qui est déjà enregistré dans le service de répertoires, et où les rôles sont déjà appliqués à l'utilisateur, l'application web ne requiert par l'authentification, et les fonctionnalités SSO sont opérationnelles.
Chapitre 14. Sécurité basée-rôle pour les applications
14.1. La Sécurité Applications
Pour chaque développeur d'applications, sécuriser vos applications est une tâche importante et couvrant des aspects multiples. JBoss Enterprise Application Platform vous donne tous les outils dont vous aurez besoin pour rédiger des applications sécurisées, y compris les possibilités suivantes :
14.2. Security Auditing
Security Auditing se réfère au déclenchement d'événements, comme écrire un blog en réponse à un événement qui a lieu dans le sous-système de sécurité. Les mécanismes de sécurité sont configurés dans le cadre du domaine de sécurité, avec les informations d'authentification, d'autorisation ou de mappage de sécurité.
Auditing utilise des modules de fournisseur. Vous pouvez en utiliser un existant ou bien créer le vôtre.
14.3. Security Mapping
Le mappage de sécurité vous permet de combiner l'authentification et l'autorisation d'informations après que l'authentification ou l'autorisation aient eu lieu, mais avant que l'information ait été passée à votre application. Un exemple qui l'illustre est l'utilisation d'un certificat X509 pour l'authentification, puis la conversion du principal du certificat en nom logique que votre application puisse afficher.
Vous pouvez mapper vos principaux (authentification), rôles (autorisation), ou identifiants (attributs qui ne sont ni principaux, ni rôles).
Le mappage de rôles est utilisé pour ajouter, remplacer ou supprimer des rôles du sujet après l'authentification.
Le mappage du principal est utilisé pour modifier un principal après l'authentification.
Le mappage d'attributs est utilisé pour convertir des attributs d'un système externe à utiliser par votre application, et vice versa.
14.4. Security Extension Architecture
L'architecture des extensions de sécurité de la plateforme JBoss Enterprise Application se compose de trois parties. Ces trois parties connectent votre application à votre infrastructure de sécurité sous-jacente, que ce soit LDAP, Kerberos ou un autre système externe.
JAAS
La première partie de l'infrastructure est l'API JAAS. JAAS est un framework additionnel qui procure une couche d'abstraction entre l'infrastructure de sécurité et votre application.
L'implémentation JAAS est
org.jboss.security.plugins.JaasSecurityManager, qui implémente les interfaces AuthenticationManager et RealmMapping. JaasSecurityManager s'intègre dans les couches de conteneur EJB et web, basées sur l'élément <security-domain> du descripteur de déploiement du composant correspondant.
Pour plus d'information sur JAAS, voir Section 16.3, « Java Authentication et Authorization Service (JAAS) ».
Le MBean
JaasSecurityManagerService
Le service MBean JaasSecurityManagerService s'occupe des gestionnaires de la sécurité. Bien que son nom commence par Jaas, les gestionnaires de sécurité qu'il gère n'ont pas besoin pas d'utiliser JAAS dans leur implémentation. Le nom reflète le fait que l'implémentation de gestionnaire de sécurité par défaut est le JaasSecurityManager
Le rôle principal du
JaasSecurityManagerService est d'externaliser la mise en œuvre du gestionnaire de sécurité. Vous pouvez modifier la mise en œuvre du gestionnaire de sécurité en fournissant une implémentation alternative des interfaces AuthenticationManager et RealmMapping.
Le deuxième rôle fondamental de
JaasSecurityManagerService est de fournir une implémentation javax.naming.spi.ObjectFactory JNDI pour permettre une gestion simple de la liaison dépourvue de code entre le nom JNDI et l'implémentation du gestionnaire de sécurité, sans code. Pour activer la sécurité, spécifiez le nom JNDI de l'implémentation du gestionnaire de sécurité par l'intermédiaire de l'élément de descripteur de déploiement <security-domain>.
Quand vous spécifiez un nom JNDI, un object-binding doit déjà être présent. Pour simplifier l'installation de la liaison entre le nom JNDI et le gestionnaire de sécurité, le service
JaasSecurityManagerService relie un next naming system reference, qui se nomme lui-même comme ObjectFactory JNDI sous le nom java:/jaas. Cela permet à une convention de nommage de la forme java:/jaas/XYZ à correspondre à la valeur de l'élément <security-domain>, et l'instance du gestionniaire de sécurité du domaine de sécurité XYZ sera créée selon les besoins, en créant une instance de la classe spécifiée par l'attribut SecurityManagerClassName, par l'intermédiaire d'un constructeur qui prendra le nom du domaine de sécurité.
Note
Vous n'avez pas besoin d'ajouter le préfixe
java:/jaas à votre descripteur de déploiement. Vous pouvez le faire, pour les raisons de compatibilité rétroactive, mais ce sera ignoré.
JaasSecurityDomain MBean
org.jboss.security.plugins.JaasSecurityDomain est une extension de JaasSecurityManager, qui ajoute la notion de KeyStore, de KeyManagerFactory et de TrustManagerFactory pour SSL et autres cas d'utilisation cryptographique.
Pour plus d'informations
Pour plus d'informations, et pour obtenir des exemples pratiques de l'architecture de sécurité en action, voir Section 14.5, « Java Authentication and Authorization Service (JAAS) ».
14.5. Java Authentication and Authorization Service (JAAS)
L'architecture de sécurité de JBoss Enterprise Application Platform 6 comprend le sous-système de configuration de sécurité, des configurations de sécurité propres aux applications qui sont incluses dans plusieurs fichiers de configuration de l'application et le gestionnaire de sécurité JAAS, qui est implémenté comme un MBean.
Domaine, Groupe serveur et Configuration spécifique du serveur
Les groupes de serveurs (dans un domaine géré) et serveurs (dans un serveur autonome) comprennent la configuration des domaines de sécurité. Un domaine de sécurité comprend des informations sur une combinaison d'authentification, autorisation, mapping et modules, avec détails de configuration. Une application spécifie quel domaine de sécurité est exigé, par nom, dans son fichier jboss-web.xml.
Configuration spécifique à une application
Une configuration spécifique à une application a lieu dans un ou plusieurs fichiers.
Tableau 14.1. Fichiers de configuration spécifique à une application
| Fichier | Description |
|---|---|
| ejb-jar.xml |
Le descripteur de déploiement pour une application Enterprise JavaBeans (EJB), situé dans le répertoire
META-INF de l'EJB. Utiliser le fichier ejb-jar.xml pour préciser les rôles et les mapper aux principaux, au niveau de l'application. Vous pouvez également limiter certaines méthodes et classes spécifiques à certains rôles. Également utilisé pour les autres configurations EJB spécifiques non liées à la sécurité.
|
| web.xml |
Le descripteur de déploiement pour une application web en Java Enterprise Edition (EE). Utilisez le fichier
web.xml pour déclarer le domaine de sécurité que l'application utilise pour l'authentification et l'autorisation, ainsi que les contraintes de transport et ressources, comme limiter les types de demandes HTTP autorisées. Vous pouvez également configurer l'authentification basée-web dans ce fichier. Utilisé également pour d'autre configurations spécifiques à l'application non liées à la sécurité.
|
| jboss-ejb3.xml |
Contient des extensions au descripteur
ejb-jar.xml spécifiques à JBoss.
|
| jboss-web.xml |
Contient des extensions au descripteur
web.xml spécifiques à JBoss.
|
Note
Les fichiers
ejb-jar.xml et web.xml sont définis dans la spécification Java Enterprise Edition (Java EE). Le fichier jboss-ejb3.xml fournit des extensions spécifiques à JBoss pour le fichier ejb-jar.xml, et le fichier jboss-web.xml fournit des extensions spécifiques à JBoss pour le fichier web.xml.
JAAS Security Manager MBean
Java Authentication and Authorization Service (JAAS) est un cadre de sécurité niveau utilisateur pour les applications Java, utilisant des modules d'authentification enfichables (PAM). Il est intégré dans le Java Runtime Environment (JRE). Dans JBoss Enterprise Application Platform, le composant côté conteneur est le MBean org.jboss.security.plugins.JaasSecurityManager. Il fournit les implémentations par défaut des interfaces AuthenticationManager et RealmMapping.
JaasSecurityManager MBean s'intègre dans EJB et dans les couches de conteneur web basées sur le domaine de sécurité spécifié dans EJB ou dans les fichiers de descripteur de déploiement de l'application. Lorsqu'une application se déploie, le conteneur associe le domaine de sécurité spécifié dans le descripteur de déploiement avec l'instance de gestionnaire de sécurité du conteneur. Le gestionnaire de sécurité applique la configuration du domaine de sécurité telle qu'elle est configurée sur le serveur de groupe ou autonome.
Flux des interactions entre le Client et le Conteneur dans JAAS
JaasSecurityManager utilise les packages JAAS pour implémenter le comportement d'interface AuthenticationManager et RealmMapping. En particulier, son comportement découle de l'exécution des instances de module de connexion qui sont configurées dans le domaine de sécurité assigné au JaasSecurityManager. Les modules de connexion implémentent l'authentification principale du domaine de sécurité et le comportement de mappage de rôle. Vous pouvez utiliser le JaasSecurityManager à travers tous les domaines de la sécurité en assignant des configurations de module de connexion différentes pour les domaines.
Pour montrer comment le JaasSecurityManager utilise le processus d'authentification JAAS, les étapes suivantes vont indiquer une méthode d'invocation du client qui implémente la méthode
EJBHome. L'EJB a déjà été déployé dans le serveur et ses méthodes d'interface EJBHome ont déjà été sécurisées par les éléments <method-permission> qui se trouvent dans le descripteur ejb-jar.xml. Utilise le domaine de sécurité jwdomain, qui est indiqué dans l'élément <security-domain> du fichier jboss-ejb3.xml. L'image ci-dessous indique les étapes qui seront expliquées par la suite.
Figure 14.1. Étapes d'une invocation de méthode EJB sécurisée
- Le client effectue une connexion JAAS pour établir le principal et les informations d'identification pour l'authentification. Correspond à Client Side Login dans le schéma. Peut être exécuté via JNDI.Pour effectuer une connexion JAAS, vous devez créer une instance de LoginContext et y indiquer le nom de la configuration à utiliser. Ici, le nom de configuration est
other. Cette connexion unique associe la connexion principale et les informations d'identification à toutes les invocations de méthode EJB. Le processus n'authentifie pas forcément l'utilisateur. La nature de la connexion côté client dépend de la configuration du module de connexion que le client utilise. Dans cet exemple, l'entrée de configurationothercôté client utilise le module de connexionClientLoginModule. Ce module lie le nom d'utilisateur et le mot de passe à la couche d'invocation EJB pour une authentification ultérieure sur le serveur. L'identité du client n'est pas authentifiée sur le client. - Le client obtient la méthode
EJBHomeet l'invoque sur le serveur. L'invocation inclut les arguments de la méthode adoptée par le client, ainsi que l'identité de l'utilisateur et les informations d'identification de la connexion JAAS de côté client. - Sur le serveur, l'intercepteur de sécurité authentifie l'utilisateur qui a invoqué la méthode. Cela nécessite une autre connexion JAAS.
- Le domaine de sécurité ci-dessous détermine le choix des modules de connexion. Le nom du domaine de sécurité est passé au constructeur
LoginContexten tant que nom de configuration de la connexion. Le domaine de sécurité des EJB estjwdomain. Si l'authentification JAAS est réussie, un sujet JAAS sera créé. Un sujet JAAS comprend un PrincipalSet avec les détails suivants :- Une instance
java.security.Principalqui correspond à l'identité du client en provenance de l'environnement de sécurité du déploiement. - Un groupe
java.security.acl.GroupappeléRoles, qui contient les noms de rôle du domaine d'application de l'utilisateur. Les objets de typeorg.jboss.security.SimplePrincipalreprésentent les noms de rôle. Ces rôles valident l'accès aux méthodes EJB suivant les contraintes deejb-jar.xmlet de l'implémentation de la méthodeEJBContext.isCallerInRole(String). - Un
java.security.acl.Groupoptionnel nomméCallerPrincipal, contenant un seulorg.jboss.security.SimplePrincipalqui correspond à l'identité de l'appelant du domaine de l'application. Le membre du groupe CallerPrincipal correspond à la valeur renvoyée par la méthodeEJBContext.getCallerPrincipal(). Ce mappage permet au Principal de l'environnement de sécurité professionnel de se mapper à un Principal connu de l'application. En l'absence d'un mappage CallerPrincipal, le principal opérationnel est le même que le principal du domaine d'application.
- Le serveur vérifie que l'utilisateur qui appelle la méthode EJB a la permission de le faire. Cette autorisation requiert les étapes suivantes :
- Obtenir les noms des rôles autorisés à accéder à la méthode EJB à partir du conteneur EJB. Les noms de rôle sont déterminés par les éléments <role-name> de tous les éléments <method-permission> du descripteur
ejb-jar.xmlqui contiennent la méthode invoquée. - Si aucun des rôles n'a été attribué, ou si la méthode est spécifiée dans un élément de la liste d'exclusion, l'accès à la méthode sera refusé. Sinon, la méthode
doesUserHaveRolesera appelée dans le gestionnaire de sécurité par l'intercepteur de sécurité pour vérifier si l'appelant possède l'un des noms de rôle assigné. Cette méthode effectue une itération dans les noms de rôles et vérifie si le groupeSubject Rolesde l'utilisateur authentifié contient un SimplePrincipal avec le nom de rôle assigné. L'accès est autorisé si un nom de rôle est membre du groupe Roles. L'accès est refusé si aucun des noms de rôle n'est membre. - Si l'EJB utilise un proxy de sécurité personnalisé, l'invocation de méthode sera déléguée au proxy. Si le proxy de sécurité refuse l'accès à l'appelant, elle lève une exception
java.lang.SecurityException. Sinon, l'accès à la méthode EJB sera autorisé et l'invocation de méthode passera au prochain intercepteur de conteneur. Le SecurityProxyInterceptor s'occupe de ce contrôle et cet intercepteur n'est pas affiché. - Pour les demandes de connexion web, le serveur web vérifie les contraintes de sécurité définies dans
web.xmlqui correspondent à la ressource demandée et à la méthode HTTP à laquelle on a accédé.S'il existe une contrainte pour la demande, le serveur web appelle le JaasSecurityManager pour effectuer l'authentification du principal, qui assure à son tour veille à ce que les rôles d'utilisateur soient associés à cet objet principal.
14.6. Utiliser un domaine de sécurité dans votre application
Aperçu
Pour utiliser un domaine de sécurité dans votre application, vous devez tout d'abord configurer le domaine dans le fichier de configuration du serveur ou dans le fichier de descripteur de l'application. Ensuite, vous devez ajouter les annotations requises à l'EJB qui l'utilise. Cette rubrique décrit les étapes requises pour utiliser un domaine de sécurité dans votre application.
Procédure 14.1. Configurer votre application pour qu'elle puisse utiliser un Domaine de sécurité
Définir le Domaine de sécurité
Vous pouvez définir le domaine de sécurité soit dans le fichier de configuration du serveur, soit dans le fichier du descripteur de l'application.Configurer le domaine de sécurité dans le fichier de configuration du serveur
Le domaine de la sécurité est configuré dans le sous-système desécuritédu fichier de configuration du serveur. Si l'instance de JBoss Enterprise Application Platform s'exécute dans un domaine géré, il s'agira du fichierdomain/configuration/domain.xml. Si l'instance de JBoss Enterprise Application Platform s'exécute comme un serveur autonome, ce sera le fichierstandalone/configuration/standalone.xml.Les domaines de sécuritéother,jboss-web-policy, etjboss-ejb-policysont fournis par défaut dans JBoss Enterprise Application Platform 6. L'exemple XML suivant a été copié à partir du sous-système desécuritédans le fichier de configuration du serveur.<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domains> <security-domain name="other" cache-type="default"> <authentication> <login-module code="Remoting" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> <login-module code="RealmDirect" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> </authentication> </security-domain> <security-domain name="jboss-web-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> <security-domain name="jboss-ejb-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> </security-domains> </subsystem>Vous pouvez configurer des domaines de sécurité supplémentaires selon les besoins par la Console de gestion ou par le Management CLI.Configurer le domaine de sécurité dans le fichier de descripteur de l'application.
Le domaine de sécurité est spécifié dans l'élément enfant<security-domain>de l'élément<jboss-web>du fichierWEB-INF/jboss-web.xmlde l'application. L'exemple suivant configure un domaine de sécurité nommémy-domain.<jboss-web> <security-domain>my-domain</security-domain> </jboss-web>Il s'agit d'une des configurations que vous pouvez indiquer dans le descripteurWEB-INF/jboss-web.xml.
Ajouter l'annotation requise à l'EJB.
Vous pouvez configurer la sécurité dans EJB par les annotations@SecurityDomainet@RolesAllowed. L'exemple de code EJB suivant limite l'accès au domaine de sécuritéotheraux utilisateurs ayant pour rôleguest(invité).package example.ejb3; import java.security.Principal; import javax.annotation.Resource; import javax.annotation.security.RolesAllowed; import javax.ejb.SessionContext; import javax.ejb.Stateless; import org.jboss.ejb3.annotation.SecurityDomain; /** * Simple secured EJB using EJB security annotations * Allow access to "other" security domain by users in a "guest" role. */ @Stateless @RolesAllowed({ "guest" }) @SecurityDomain("other") public class SecuredEJB { // Inject the Session Context @Resource private SessionContext ctx; /** * Secured EJB method using security annotations */ public String getSecurityInfo() { // Session context injected using the resource annotation Principal principal = ctx.getCallerPrincipal(); return principal.toString(); } }Pour obtenir des exemples de code supplémentaires, voirejb-securityQuickstart dans le package JBoss Enterprise Application Platform 6 Quickstarts disponible à partir du Portail Clients Red Hat.
14.7. Utilisation de la Sécurité basée-rôle dans les Servlets
Pour ajouter la sécurité à un servlet, vous mappez chaque servlet à un type d'URL et créez des contraintes de sécurité sur les types d'URL qui doivent être sécurisés. Les contraintes de sécurité limitent l'accès des URL aux rôles. L'authentification et l'autorisation sont gérées par le domaine de sécurité spécifié dans
jboss-web.xml du WAR.
Prérequis
Avant d'utiliser la sécurité basée-rôles dans une servlet, le domaine de sécurité utilisé pour authentifier et autoriser l'accès doit être configuré sur la plateforme JBoss Enterprise Application Platform.
Procédure 14.2. Ajout de la Sécurité basée-rôle dans les Servlets
Ajout de mappages entre les types d'URL et les servlets.
Utiliser les éléments<servlet-mapping>du fichierweb.xmlpour mapper les servlets individuels à des types d'URL. L'exemple suivant mappe le serveur nomméDisplayOpResultau type d'URL/DisplayOpResult.<servlet-mapping> <servlet-name>DisplayOpResult</servlet-name> <url-pattern>/DisplayOpResult</url-pattern> </servlet-mapping>Ajout des contraintes de sécurité aux types d'URL.
Pour mapper le type d'URL avec une contrainte de sécurité, utilisez un<security-constraint>. L'exemple suivant limite l'accès d'un type d'URL/DisplayOpResultafin qu'il soit accessible aux principaux ayant pour rôleeap_admin. Le rôle doit être présent dans le domaine de sécurité.<security-constraint> <display-name>Restrict access to role eap_admin</display-name> <web-resource-collection> <web-resource-name>Restrict access to role eap_admin</web-resource-name> <url-pattern>/DisplayOpResult/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>eap_admin</role-name> </auth-constraint> <security-role> <role-name>eap_admin</role-name> </security-role> </security-constraint>
Indiquer le domaine de sécurité et le fichier
jboss-web.xmldu WAR.Ajouter le domaine de sécurité au fichierjboss-Web.xmldu WAR afin de connecter les servlets au domaine de la sécurité configuré sachant comment authentifier et autoriser les principaux selon les contraintes de sécurité. L'exemple suivant utilise le domaine de sécurité appeléacme_domain.<jboss-web> ... <security-domain>acme_domain</security-domain> ... </jboss-web>
14.8. Utilisation d'une authentification système de tierce partie pour votre application
Vous pouvez intégrer des systèmes de sécurité de tierce partie avec JBoss Enterprise Application Platform. Ces types de systèmes sont habituellement basés sur des tokens. Le système externe effectue l'authentification et passe un token à l'application web via les en-têtes de demande. Ceci est souvent dénommé authentification de périmètre. Pour configurer la sécurité de périmètre dans votre application, ajoutez une valve d'authentification personnalisée. Si vous avez une valve d'un fournisseur tiers, veillez à ce qu'elle soit sur votre chemin de classe et suivez les exemples ci-dessous, ainsi que la documentation pour votre module d'authentification tiers.
Note
L'emplacement pour la configuration des valves a changé dans JBoss Enterprise Application Platform 6. Il n'y a plus de descripteur de déploiement
context.xml. Les valves sont configurées directement dans le descripteur jboss-web.xml à la place. Le fichier context.xml peut maintenant être ignoré.
Exemple 14.1. Valve d'authentification de base
<jboss-web>
<valve>
<class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
</valve>
</jboss-web>
Cette valve est utilisée pour les SSO basés-Kerberos. Montre également les modèles les plus simples d'indication d'authentificateurs de tierce partie pour votre application web.
Exemple 14.2. Personnaliser une Valve avec des Attributs d'en-tête
<jboss-web>
<valve>
<class-name>org.jboss.web.tomcat.security.GenericHeaderAuthenticator</class-name>
<param>
<param-name>httpHeaderForSSOAuth</param-name>
<param-value>sm_ssoid,ct-remote-user,HTTP_OBLIX_UID</param-value>
</param>
<param>
<param-name>sessionCookieForSSOAuth</param-name>
<param-value>SMSESSION,CTSESSION,ObSSOCookie</param-value>
</param>
</valve>
</jboss-web>
Cet exemple montre comment définir des attributs personnalisés sur votre valve. L'authentificateur vérifie la présence de l'en-tête ID et de la clé de session, puis les passe au framework JAAS qui actionne la couche de sécurité, comme le nom d'utilisateur et le mot de passe. Vous avez besoin d'un module de connexion JAAS personnalisé qui puisse traiter le nom d'utilisateur et le mot de passe tout en remplissant le sujet de les rôles corrects. Si aucune valeur d'en-tête ne correspond aux valeurs configurées, les sémantiques de d'authentification basée sur les formulaires réguliers s'appliqueront.
Rédaction d'un authentificateur personnalisé
Rédiger vous-même votre authentificateur est en dehors de la portée de ce document. Cependant, le code Java suivant est fourni comme exemple.
Exemple 14.3. GenericHeaderAuthenticator.java
/*
* JBoss, Home of Professional Open Source.
* Copyright 2006, Red Hat Middleware LLC, and individual contributors
* as indicated by the @author tags. See the copyright.txt file in the
* distribution for a full listing of individual contributors.
*
* This is free software; you can redistribute it and/or modify it
* under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation; either version 2.1 of
* the License, or (at your option) any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this software; if not, write to the Free
* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
*/
package org.jboss.web.tomcat.security;
import java.io.IOException;
import java.security.Principal;
import java.util.StringTokenizer;
import javax.management.JMException;
import javax.management.ObjectName;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.catalina.Realm;
import org.apache.catalina.Session;
import org.apache.catalina.authenticator.Constants;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.deploy.LoginConfig;
import org.jboss.logging.Logger;
import org.jboss.as.web.security.ExtendedFormAuthenticator;
/**
* JBAS-2283: Provide custom header based authentication support
*
* Header Authenticator that deals with userid from the request header Requires
* two attributes configured on the Tomcat Service - one for the http header
* denoting the authenticated identity and the other is the SESSION cookie
*
* @author <a href="mailto:Anil.Saldhana@jboss.org">Anil Saldhana</a>
* @author <a href="mailto:sguilhen@redhat.com">Stefan Guilhen</a>
* @version $Revision$
* @since Sep 11, 2006
*/
public class GenericHeaderAuthenticator extends ExtendedFormAuthenticator {
protected static Logger log = Logger
.getLogger(GenericHeaderAuthenticator.class);
protected boolean trace = log.isTraceEnabled();
// JBAS-4804: GenericHeaderAuthenticator injection of ssoid and
// sessioncookie name.
private String httpHeaderForSSOAuth = null;
private String sessionCookieForSSOAuth = null;
/**
* <p>
* Obtain the value of the <code>httpHeaderForSSOAuth</code> attribute. This
* attribute is used to indicate the request header ids that have to be
* checked in order to retrieve the SSO identity set by a third party
* security system.
* </p>
*
* @return a <code>String</code> containing the value of the
* <code>httpHeaderForSSOAuth</code> attribute.
*/
public String getHttpHeaderForSSOAuth() {
return httpHeaderForSSOAuth;
}
/**
* <p>
* Set the value of the <code>httpHeaderForSSOAuth</code> attribute. This
* attribute is used to indicate the request header ids that have to be
* checked in order to retrieve the SSO identity set by a third party
* security system.
* </p>
*
* @param httpHeaderForSSOAuth
* a <code>String</code> containing the value of the
* <code>httpHeaderForSSOAuth</code> attribute.
*/
public void setHttpHeaderForSSOAuth(String httpHeaderForSSOAuth) {
this.httpHeaderForSSOAuth = httpHeaderForSSOAuth;
}
/**
* <p>
* Obtain the value of the <code>sessionCookieForSSOAuth</code> attribute.
* This attribute is used to indicate the names of the SSO cookies that may
* be present in the request object.
* </p>
*
* @return a <code>String</code> containing the names (separated by a
* <code>','</code>) of the SSO cookies that may have been set by a
* third party security system in the request.
*/
public String getSessionCookieForSSOAuth() {
return sessionCookieForSSOAuth;
}
/**
* <p>
* Set the value of the <code>sessionCookieForSSOAuth</code> attribute. This
* attribute is used to indicate the names of the SSO cookies that may be
* present in the request object.
* </p>
*
* @param sessionCookieForSSOAuth
* a <code>String</code> containing the names (separated by a
* <code>','</code>) of the SSO cookies that may have been set by
* a third party security system in the request.
*/
public void setSessionCookieForSSOAuth(String sessionCookieForSSOAuth) {
this.sessionCookieForSSOAuth = sessionCookieForSSOAuth;
}
/**
* <p>
* Creates an instance of <code>GenericHeaderAuthenticator</code>.
* </p>
*/
public GenericHeaderAuthenticator() {
super();
}
public boolean authenticate(Request request, HttpServletResponse response,
LoginConfig config) throws IOException {
log.trace("Authenticating user");
Principal principal = request.getUserPrincipal();
if (principal != null) {
if (trace)
log.trace("Already authenticated '" + principal.getName() + "'");
return true;
}
Realm realm = context.getRealm();
Session session = request.getSessionInternal(true);
String username = getUserId(request);
String password = getSessionCookie(request);
// Check if there is sso id as well as sessionkey
if (username == null || password == null) {
log.trace("Username is null or password(sessionkey) is null:fallback to form auth");
return super.authenticate(request, response, config);
}
principal = realm.authenticate(username, password);
if (principal == null) {
forwardToErrorPage(request, response, config);
return false;
}
session.setNote(Constants.SESS_USERNAME_NOTE, username);
session.setNote(Constants.SESS_PASSWORD_NOTE, password);
request.setUserPrincipal(principal);
register(request, response, principal, HttpServletRequest.FORM_AUTH,
username, password);
return true;
}
/**
* Get the username from the request header
*
* @param request
* @return
*/
protected String getUserId(Request request) {
String ssoid = null;
// We can have a comma-separated ids
String ids = "";
try {
ids = this.getIdentityHeaderId();
} catch (JMException e) {
if (trace)
log.trace("getUserId exception", e);
}
if (ids == null || ids.length() == 0)
throw new IllegalStateException(
"Http headers configuration in tomcat service missing");
StringTokenizer st = new StringTokenizer(ids, ",");
while (st.hasMoreTokens()) {
ssoid = request.getHeader(st.nextToken());
if (ssoid != null)
break;
}
if (trace)
log.trace("SSOID-" + ssoid);
return ssoid;
}
/**
* Obtain the session cookie from the request
*
* @param request
* @return
*/
protected String getSessionCookie(Request request) {
Cookie[] cookies = request.getCookies();
log.trace("Cookies:" + cookies);
int numCookies = cookies != null ? cookies.length : 0;
// We can have comma-separated ids
String ids = "";
try {
ids = this.getSessionCookieId();
log.trace("Session Cookie Ids=" + ids);
} catch (JMException e) {
if (trace)
log.trace("checkSessionCookie exception", e);
}
if (ids == null || ids.length() == 0)
throw new IllegalStateException(
"Session cookies configuration in tomcat service missing");
StringTokenizer st = new StringTokenizer(ids, ",");
while (st.hasMoreTokens()) {
String cookieToken = st.nextToken();
String val = getCookieValue(cookies, numCookies, cookieToken);
if (val != null)
return val;
}
if (trace)
log.trace("Session Cookie not found");
return null;
}
/**
* Get the configured header identity id in the tomcat service
*
* @return
* @throws JMException
*/
protected String getIdentityHeaderId() throws JMException {
if (this.httpHeaderForSSOAuth != null)
return this.httpHeaderForSSOAuth;
return (String) mserver.getAttribute(new ObjectName(
"jboss.web:service=WebServer"), "HttpHeaderForSSOAuth");
}
/**
* Get the configured session cookie id in the tomcat service
*
* @return
* @throws JMException
*/
protected String getSessionCookieId() throws JMException {
if (this.sessionCookieForSSOAuth != null)
return this.sessionCookieForSSOAuth;
return (String) mserver.getAttribute(new ObjectName(
"jboss.web:service=WebServer"), "SessionCookieForSSOAuth");
}
/**
* Get the value of a cookie if the name matches the token
*
* @param cookies
* array of cookies
* @param numCookies
* number of cookies in the array
* @param token
* Key
* @return value of cookie
*/
protected String getCookieValue(Cookie[] cookies, int numCookies,
String token) {
for (int i = 0; i < numCookies; i++) {
Cookie cookie = cookies[i];
log.trace("Matching cookieToken:" + token + " with cookie name="
+ cookie.getName());
if (token.equals(cookie.getName())) {
if (trace)
log.trace("Cookie-" + token + " value=" + cookie.getValue());
return cookie.getValue();
}
}
return null;
}
}
Chapitre 15. Migration
15.1. Configurer les changements de sécurité d'applications
Configurer la sécurité pour l'authentification de base
Le UsersRolesLoginModule a toujours recherché les fichiers de propriétés dans le chemin de classes. Dans les versions précédentes de JBoss Enterprise Application Platform, les fichiers de propriétés qui se trouvent dans le répertoire EAP_HOME/server/SERVER_NAME/conf/ étaient sur un chemin de classe et on pouvait les trouver facilement avec UsersRolesLoginModule. Dans JBoss Enterprise Application Platform 6, la structure du répertoire a changé. Les fichiers de propriétés doivent être empaquetés dans l'application pour les rendre disponibles par le chemin de classe.
Important
Vous devez interrompre le serveur avant de modifier le fichier de configuration du serveur pour que votre changement puisse être persisté au redémarrage du serveur.
Pour configurer la sécurité de l'authentification de base, ajouter un nouveau domaine de sécurité sous
security-domains au standalone/configuration/standalone.xml ou au fichier de configuration du serveur domain/configuration/domain.xml:
<security-domain name="example">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties"
value="${jboss.server.config.dir}/example-users.properties"/>
<module-option name="rolesProperties"
value="${jboss.server.config.dir}/example-roles.properties"/>
</login-module>
</authentication>
</security-domain>
Si l'instance de JBoss Enterpise Application Platform 6 exécute en tant que serveur autonome,
${jboss.server.config.dir} fait référence au répertoire EAP_HOME/standalone/configuration/. Si l'instance exécute en domaine géré, ${jboss.server.config.dir} fait référence au répertoire EAP_HOME/domain/configuration/.
Modifier les noms de domaine de sécurité
Dans JBoss Enterprise Application Platform 6, les domaines de sécurité n'utilisent plus le préfixe java:/jaas/ dans leurs noms.
- Pour les applications web, vous devez supprimer ce préfixe des configurations du domaine de sécurité dans le fichier
jboss-web.xml. - Dans les applications Enterprise, vous devez supprimer ce préfixe des configurations du domaine de sécurité dans le fichier
jboss-ejb3.xml. Ce fichier remplace le fichierjboss.xmlde JBoss Enterprise Application Platform 6.
Chapitre 16. Authentification et Autorisation
16.1. Authentification
L'authentification consiste à identifier un sujet et à vérifier l'authenticité de l'identification. Le mécanisme d'authentification le plus commun est une combinaison de nom d'utilisateur et de mot de passe. D'autres mécanismes d'authentification communs utilisent des clés partagées, des smart cards (cartes à puce) ou des empreintes digitales. Le résultat d'une authentification à succès s'appelle un Principal, en termes de sécurité déclarative Java Enterprise Edition.
JBoss Enterprise Application Platform utilise un système pouvant se connecter à des modules d'authentification en vue de flexibilité et d'intégration avec les systèmes d'authentification que vous utilisez dans votre organisation. Chaque domaine de sécurité contient un ou plusieurs modules d'authentification configurés. Chaque module comprend des paramètres de configuration supplémentaires pour personnaliser son comportement. Le plus simple consiste à configurer le sous-système d'authentification dans la console de gestion web.
L'authentification n'est pas le même chose que l'autorisation, même si elles sont souvent liées. Bon nombre des modules d'authentification intégrés peuvent également gérer des autorisations.
16.2. L'autorisation
L'autorisation est un mécanisme d'octroi ou de refus de permission d'accéder à une ressource, basé sur l'identité. Ce mécanisme est implémenté sous forme de rôles de sécurité déclarative, qui peuvent être donnés à des principaux.
JBoss Enterprise Application Platform utilise un système modulaire pour configurer l'autorisation. Chaque domaine de sécurité peut contenir une ou plusieurs stratégies d'autorisation. Chaque stratégie possède un module de base qui définit son comportement. Il est configuré via les attributs et indicateurs spécifiques. La façon la plus simple consiste à configurer le sous-système de l'autorisation à l'aide de la console de gestion basée web.
L'authentification est différente de l'autorisation, et a lieu, en général, après l'authentification. La plupart des modules d'authentification gèrent également l'autorisation.
16.3. Java Authentication et Authorization Service (JAAS)
Java Authentication and Authorization Service (JAAS) est une API de sécurité qui consiste en un ensemble de packages Java conçus pour l'autorisation et l'authentification des utilisateurs. L'API est une implémentation Java du framework standard PAM (de l'anglais Pluggable Authentication Modules). Étend l'architecture de contrôle d'accès de Java Enterprise Edition pour approuver l'autorisation basée utilisateur.
Dans JBoss Enterprise Application Platform, JAAS ne fournit qu'une sécurité déclarative basée rôle. Pour plus d'informations sur le sécurité déclarative, voir Section 2.4, « Sécurité déclarative ».
JAAS est indépendant de toute technologie d'authentification sous-jacent, comme Kerberos ou LDAP. Vous pouvez modifier votre structure de sécurité sous-jacente sans modifier votre application. Vous devez uniquement modifier la configuration JAAS.
16.4. Java Authentication and Authorization Service (JAAS)
L'architecture de sécurité de JBoss Enterprise Application Platform 6 comprend le sous-système de configuration de sécurité, des configurations de sécurité propres aux applications qui sont incluses dans plusieurs fichiers de configuration de l'application et le gestionnaire de sécurité JAAS, qui est implémenté comme un MBean.
Domaine, Groupe serveur et Configuration spécifique du serveur
Les groupes de serveurs (dans un domaine géré) et serveurs (dans un serveur autonome) comprennent la configuration des domaines de sécurité. Un domaine de sécurité comprend des informations sur une combinaison d'authentification, autorisation, mapping et modules, avec détails de configuration. Une application spécifie quel domaine de sécurité est exigé, par nom, dans son fichier jboss-web.xml.
Configuration spécifique à une application
Une configuration spécifique à une application a lieu dans un ou plusieurs fichiers.
Tableau 16.1. Fichiers de configuration spécifique à une application
| Fichier | Description |
|---|---|
| ejb-jar.xml |
Le descripteur de déploiement pour une application Enterprise JavaBeans (EJB), situé dans le répertoire
META-INF de l'EJB. Utiliser le fichier ejb-jar.xml pour préciser les rôles et les mapper aux principaux, au niveau de l'application. Vous pouvez également limiter certaines méthodes et classes spécifiques à certains rôles. Également utilisé pour les autres configurations EJB spécifiques non liées à la sécurité.
|
| web.xml |
Le descripteur de déploiement pour une application web en Java Enterprise Edition (EE). Utilisez le fichier
web.xml pour déclarer le domaine de sécurité que l'application utilise pour l'authentification et l'autorisation, ainsi que les contraintes de transport et ressources, comme limiter les types de demandes HTTP autorisées. Vous pouvez également configurer l'authentification basée-web dans ce fichier. Utilisé également pour d'autre configurations spécifiques à l'application non liées à la sécurité.
|
| jboss-ejb3.xml |
Contient des extensions au descripteur
ejb-jar.xml spécifiques à JBoss.
|
| jboss-web.xml |
Contient des extensions au descripteur
web.xml spécifiques à JBoss.
|
Note
Les fichiers
ejb-jar.xml et web.xml sont définis dans la spécification Java Enterprise Edition (Java EE). Le fichier jboss-ejb3.xml fournit des extensions spécifiques à JBoss pour le fichier ejb-jar.xml, et le fichier jboss-web.xml fournit des extensions spécifiques à JBoss pour le fichier web.xml.
JAAS Security Manager MBean
Java Authentication and Authorization Service (JAAS) est un cadre de sécurité niveau utilisateur pour les applications Java, utilisant des modules d'authentification enfichables (PAM). Il est intégré dans le Java Runtime Environment (JRE). Dans JBoss Enterprise Application Platform, le composant côté conteneur est le MBean org.jboss.security.plugins.JaasSecurityManager. Il fournit les implémentations par défaut des interfaces AuthenticationManager et RealmMapping.
JaasSecurityManager MBean s'intègre dans EJB et dans les couches de conteneur web basées sur le domaine de sécurité spécifié dans EJB ou dans les fichiers de descripteur de déploiement de l'application. Lorsqu'une application se déploie, le conteneur associe le domaine de sécurité spécifié dans le descripteur de déploiement avec l'instance de gestionnaire de sécurité du conteneur. Le gestionnaire de sécurité applique la configuration du domaine de sécurité telle qu'elle est configurée sur le serveur de groupe ou autonome.
Flux des interactions entre le Client et le Conteneur dans JAAS
JaasSecurityManager utilise les packages JAAS pour implémenter le comportement d'interface AuthenticationManager et RealmMapping. En particulier, son comportement découle de l'exécution des instances de module de connexion qui sont configurées dans le domaine de sécurité assigné au JaasSecurityManager. Les modules de connexion implémentent l'authentification principale du domaine de sécurité et le comportement de mappage de rôle. Vous pouvez utiliser le JaasSecurityManager à travers tous les domaines de la sécurité en assignant des configurations de module de connexion différentes pour les domaines.
Pour montrer comment le JaasSecurityManager utilise le processus d'authentification JAAS, les étapes suivantes vont indiquer une méthode d'invocation du client qui implémente la méthode
EJBHome. L'EJB a déjà été déployé dans le serveur et ses méthodes d'interface EJBHome ont déjà été sécurisées par les éléments <method-permission> qui se trouvent dans le descripteur ejb-jar.xml. Utilise le domaine de sécurité jwdomain, qui est indiqué dans l'élément <security-domain> du fichier jboss-ejb3.xml. L'image ci-dessous indique les étapes qui seront expliquées par la suite.
Figure 16.1. Étapes d'une invocation de méthode EJB sécurisée
- Le client effectue une connexion JAAS pour établir le principal et les informations d'identification pour l'authentification. Correspond à Client Side Login dans le schéma. Peut être exécuté via JNDI.Pour effectuer une connexion JAAS, vous devez créer une instance de LoginContext et y indiquer le nom de la configuration à utiliser. Ici, le nom de configuration est
other. Cette connexion unique associe la connexion principale et les informations d'identification à toutes les invocations de méthode EJB. Le processus n'authentifie pas forcément l'utilisateur. La nature de la connexion côté client dépend de la configuration du module de connexion que le client utilise. Dans cet exemple, l'entrée de configurationothercôté client utilise le module de connexionClientLoginModule. Ce module lie le nom d'utilisateur et le mot de passe à la couche d'invocation EJB pour une authentification ultérieure sur le serveur. L'identité du client n'est pas authentifiée sur le client. - Le client obtient la méthode
EJBHomeet l'invoque sur le serveur. L'invocation inclut les arguments de la méthode adoptée par le client, ainsi que l'identité de l'utilisateur et les informations d'identification de la connexion JAAS de côté client. - Sur le serveur, l'intercepteur de sécurité authentifie l'utilisateur qui a invoqué la méthode. Cela nécessite une autre connexion JAAS.
- Le domaine de sécurité ci-dessous détermine le choix des modules de connexion. Le nom du domaine de sécurité est passé au constructeur
LoginContexten tant que nom de configuration de la connexion. Le domaine de sécurité des EJB estjwdomain. Si l'authentification JAAS est réussie, un sujet JAAS sera créé. Un sujet JAAS comprend un PrincipalSet avec les détails suivants :- Une instance
java.security.Principalqui correspond à l'identité du client en provenance de l'environnement de sécurité du déploiement. - Un groupe
java.security.acl.GroupappeléRoles, qui contient les noms de rôle du domaine d'application de l'utilisateur. Les objets de typeorg.jboss.security.SimplePrincipalreprésentent les noms de rôle. Ces rôles valident l'accès aux méthodes EJB suivant les contraintes deejb-jar.xmlet de l'implémentation de la méthodeEJBContext.isCallerInRole(String). - Un
java.security.acl.Groupoptionnel nomméCallerPrincipal, contenant un seulorg.jboss.security.SimplePrincipalqui correspond à l'identité de l'appelant du domaine de l'application. Le membre du groupe CallerPrincipal correspond à la valeur renvoyée par la méthodeEJBContext.getCallerPrincipal(). Ce mappage permet au Principal de l'environnement de sécurité professionnel de se mapper à un Principal connu de l'application. En l'absence d'un mappage CallerPrincipal, le principal opérationnel est le même que le principal du domaine d'application.
- Le serveur vérifie que l'utilisateur qui appelle la méthode EJB a la permission de le faire. Cette autorisation requiert les étapes suivantes :
- Obtenir les noms des rôles autorisés à accéder à la méthode EJB à partir du conteneur EJB. Les noms de rôle sont déterminés par les éléments <role-name> de tous les éléments <method-permission> du descripteur
ejb-jar.xmlqui contiennent la méthode invoquée. - Si aucun des rôles n'a été attribué, ou si la méthode est spécifiée dans un élément de la liste d'exclusion, l'accès à la méthode sera refusé. Sinon, la méthode
doesUserHaveRolesera appelée dans le gestionnaire de sécurité par l'intercepteur de sécurité pour vérifier si l'appelant possède l'un des noms de rôle assigné. Cette méthode effectue une itération dans les noms de rôles et vérifie si le groupeSubject Rolesde l'utilisateur authentifié contient un SimplePrincipal avec le nom de rôle assigné. L'accès est autorisé si un nom de rôle est membre du groupe Roles. L'accès est refusé si aucun des noms de rôle n'est membre. - Si l'EJB utilise un proxy de sécurité personnalisé, l'invocation de méthode sera déléguée au proxy. Si le proxy de sécurité refuse l'accès à l'appelant, elle lève une exception
java.lang.SecurityException. Sinon, l'accès à la méthode EJB sera autorisé et l'invocation de méthode passera au prochain intercepteur de conteneur. Le SecurityProxyInterceptor s'occupe de ce contrôle et cet intercepteur n'est pas affiché. - Pour les demandes de connexion web, le serveur web vérifie les contraintes de sécurité définies dans
web.xmlqui correspondent à la ressource demandée et à la méthode HTTP à laquelle on a accédé.S'il existe une contrainte pour la demande, le serveur web appelle le JaasSecurityManager pour effectuer l'authentification du principal, qui assure à son tour veille à ce que les rôles d'utilisateur soient associés à cet objet principal.
16.5. Java Authorization Contract for Containers (JACC)
16.5.1. Java Authorization Contract for Containers (JACC)
Java Authorization Contract for Containers (JACC) est une norme qui définit un contrat entre les conteneurs et les fournisseurs de services d'autorisation, et qui se traduit par l'implémentation de fournisseurs qui seront utilisés par des conteneurs. Il a été défini dans JSR-115, qui se trouve sur le site Web de Java Community Process http://jcp.org/en/jsr/detail?id=115. A fait partie de la spécification Java Enterprise Edition (Java EE) depuis la version 1.3 de Java EE.
JBoss Enterprise Application Platform implémente un support pour JACC dans la fonctionnalité de sécurité du sous-système de sécurité.
16.5.2. Configurer la sécurité JACC (Java Authorization Contract for Containers)
Pour configurer JACC (Java Authorization Contract for Containers), vous devez configurer votre domaine de sécurité avec le module qui convient, puis modifiez votre fichier
jboss-web.xml pour y inclure les paramètres qu'il faut.
Ajouter JACC au Domaine de sécurité
Pour ajouter JACC au domaine de sécurité, ajouter la police d'autorisation JACC à la pile d'autorisations du domaine de sécurité, avec l'indicateur required. Voici un exemple de domaine de sécurité avec support JACC. Cependant, le domaine de sécurité est configuré dans la Console de gestion ou Management CLI, plutôt que directement dans le code XML.
<security-domain name="jacc" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
</login-module>
</authentication>
<authorization>
<policy-module code="JACC" flag="required"/>
</authorization>
</security-domain>
Configurer une application web qui utilise JACC
Le fichier jboss-web.xml se trouve dans META-INF/ ou dans le répertoire WEB-INF/ de votre déploiement, et contient des ajouts ou remplacements de configuration spécifique JBoss pour le conteneur web. Pour utiliser votre domaine de sécurité activé-JACC, vous devrez inclure l'élément <security-domain>, et aussi définir l'élément <use-jboss-authorization> àtrue. L'application suivante est configurée correctement pour pouvoir utiliser le domaine de sécurité JACC ci-dessus.
<jboss-web>
<security-domain>jacc</security-domain>
<use-jboss-authorization>true</use-jboss-authorization>
</jboss-web>
Configurer une application EJB pour utiliser JACC
La façon de configurer les EJB pour qu'ils utilisent un domaine de sécurité et pour qu'ils utilisent JACC diffère selon de la méthode utilisée pour les applications Web. Pour un EJB, vous pouvez déclarer des method permissions (permissions de méthode) sur une méthode ou sur un groupe de méthodes, dans le descripteur ejb-jar.xml. Dans l'élément <ejb-jar>, chaque élément <method-permission> dépendant contient des informations sur les rôles JACC. Voir l'exemple de configuration pour plus d'informations. La classe EJBMethodPermission fait partie de l'API Java Enterprise Edition 6, et est documentée dans http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html.
Exemple 16.1. Exemple de Permissions de méthode JACC dans un EJB
<ejb-jar>
<method-permission>
<description>The employee and temp-employee roles may access any method of the EmployeeService bean </description>
<role-name>employee</role-name>
<role-name>temp-employee</role-name>
<method>
<ejb-name>EmployeeService</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
</ejb-jar>
Vous pouvez également contraindre les mécanismes d'authentification et d'autorisation d'un EJB à l'aide d'un domaine de sécurité, comme vous pouvez le faire pour une application web. Les domaines de sécurité sont déclarés dans le descripteur
jboss-ejb3.xml qui se trouve dans l'élément dépendant <security>. En plus du domaine de sécurité, vous pouvez également spécifier le run-as principal, qui change le principal que l'EJB exécute.
Exemple 16.2. Exemple de déclaration de domaine de sécurité dans un EJB
<security> <ejb-name>*</ejb-name> <security-domain>myDomain</s:security-domain> <run-as-principal>myPrincipal</s:run-as-principal> </s:security>
16.6. Java Authentication SPI for Containers (JASPI)
16.6.1. Sécurité Java Authentication SPI pour Conteneurs (JASPI)
Java Application SPI pour Conteneurs (JASPI or JASPIC) est une interface enfichable pour applications JSR-196 du Java Community Process. Consulter http://www.jcp.org/en/jsr/detail?id=196 pour obtenir des informations sur la spécification.
16.6.2. Configuration de la Sécurité Java Authentication SPI pour Conteneurs (JASPI)
Pour s'authentifier auprès d'un fournisseur JASPI, ajouter un élément
<authentication-jaspi> à votre domaine de sécurité. La configuration est similaire à celle d'un module d'authentification standard, mais les éléments de module de login sont inclus dans l'élément <login-module-stack>. La structure de configuration est la suivante :
Exemple 16.3. Structure de l'élément authentication-jaspi
<authentication-jaspi> <login-module-stack name="..."> <login-module code="..." flag="..."> <module-option name="..." value="..."/> </login-module> </login-module-stack> <auth-module code="..." login-module-stack-ref="..."> <module-option name="..." value="..."/> </auth-module> </authentication-jaspi>
Le module de connexion est lui-même configuré de la même façon que le module d'authentification standard.
Comme la console de gestion basée web n'expose pas la configuration des modules d'authentification JASPI, vous devez stopper la plateforme JBoss Enterprise Application Platform complètement avant d'ajouter la configuration directement dans le fichier
EAP_HOME/domain/configuration/domain.xml ou dans le fichier EAP_HOME/standalone/configuration/standalone.xml.
Annexe A. Référence
A.1. Modules d'authentification inclus
Les modules d'authentification suivants sont inclus dans JBoss Enterprise Application Platform. Certains d'entre eux gèrent l'autorisation ainsi que l'authentification. Ceux-ci incluent généralement le mot
Role dans le nom de Code
Quand vous configurez ces modules, utiliser la valeur
Code ou le nom complet (package) pour vous référer au module.
Modules d'authentification
Tableau A.1. Client
| Code | Client
|
| Class | org.jboss.security.ClientLoginModule
|
| Description |
Ce module de connexion est conçu pour établir l'identité de l'appelant et les informations d'identification lorsque JBoss Enterprise Application Platform agit en tant que client. Il ne doit jamais servir sous forme de domaine de sécurité pour l'authentification serveur.
|
Tableau A.2. Options de Modules Client
| Option | Type | Par défaut | Description |
|---|---|---|---|
multi-threaded | true ou false
| false
|
Définir la valeur sur true si chaque thread possède son propre stockage d'informations d'identification et principal. La valeur false pour indiquer que tous les threads de la machine virtuelle partagent la même identité et informations d'identification.
|
password-stacking
| useFirstPass ou false
| false
|
Définir la valeur sur useFirstPass pour indiquer que ce module de connexion doive rechercher les informations stockées dans le LoginContext à utiliser comme identité. Cette option peut être utilisée lorsque vous empilez les autres modules de connexion avec.
|
>restore-login-identity
| true ou false
| false
|
Définir sur true si l'identité et les informations d'identification du début le la méthode login() doivent être restaurées une fois que la méthode logout() est invoquée.
|
Tableau A.3. Certificate
| Code | Certificate
|
| Class | org.jboss.security.auth.spi.BaseCertLoginModule
|
| Description |
Ce module de connexion est conçu pour authentifier les utilisateurs basés sur des
X509 Certificates. Un cas d'utilisation pour ceci est l'authentification CLIENT-CERT d'une application web.
|
Tableau A.4. Options de module Certificate
| Option | Type | Par défaut | Description |
|---|---|---|---|
securityDomain
| chaîne |
aucun
|
Nom du domaine de sécurité qui possède la configuration JSSE du truststore qui contient les certificats approuvés.
|
verifier
| Class |
aucun
|
Le nom de classe du org.jboss.security.auth.certs.X509CertificateVerifier à utiliser pour vérifier le certificat de connexion.
|
Tableau A.5. CertificateUsers
| Code | CertificateUsers
|
| Class | org.jboss.security.auth.spi.UsersRolesLoginModule
|
| Description |
Utilise deux ressources de propriété. La première mappe les noms d'utilisateur aux mots de passe, et la seconde mappe les noms d'utilisateurs aux rôles.
|
Tableau A.6. Options de module CertificateUsers
| Option | Type | Par défaut | Description |
|---|---|---|---|
unauthenticatedIdentity
| Une chaîne |
aucun
|
Définit le nom principal devant être affecté aux demandes qui ne contiennent aucune information d'authentification. Cela peut permettre à des servlets non protégés d'appeler des méthodes sur EJB ne nécessitant pas un rôle spécifique. Un tel principal ne possédera aucun rôle associé et ne ne pourra accéder qu'aux méthodes EJB ou EJB non sécurisées associées à la contrainte de
permission non contrôlée.
|
password-stacking
| useFirstPass ou false
| false
|
Définir la valeur sur
useFirstPass pour indiquer que ce module de connexion doive rechercher les informations stockées dans le LoginContext à utiliser comme identité. Cette option peut être utilisée lorsque vous empilez les autres modules de connexion avec celui-ci.
|
hashAlgorithm | Une chaîne |
aucun
|
Le nom de l'algorithme
java.security.MessageDigest à utiliser pour hacher le mot de passe. Il n'y a pas de valeur par défaut pour cette option, donc vous devez la définir explicitement pour permettre le hachage. Quand hashAlgorithm est spécifié, le mot de passe en texte clair obtenu de CallbackHandler sera haché avant de passer à UsernamePasswordLoginModule.validatePassword comme argument d'inputPassword. Le expectedPassword stocké dans le fichier users.properties doit être haché de façon similaire. Voir http://docs.oracle.com/javase/6/docs/api/java/security/MessageDigest.html pour obtenir des informations sur java.security.MessageDigest
|
hashEncoding
| base64 ou hex
| base64
|
Le format du string du mot de passe haché, si
hashAlgorithm est défini également.
|
hashCharSet
| Une chaîne |
Le codage par défaut défini dans l'environnement du conteneur.
|
Le codage utilisé pour convertir le mot de passe de texte en clair en un tableau d'octets.
|
usersProperties
|
Le chemin d'accès complet et le nom d'une ressource ou d'un fichier de propriétés
| users.properties
|
Le fichier qui contient les mappages entre les utilisateurs et les mots de passe. Chaque propriété du fichier a le format
username=password.
|
rolesProperties
| Le chemin d'accès complet et le nom d'une ressource ou d'un fichier de propriétés | roles.properties
|
Le fichier qui contient les mappages entre les utilisateurs et les rôles. Chaque propriété du fichier a le format
username=role1,role2,...,roleN
|
ignorePasswordCase
| true ou false
| false
|
Si la comparaison de mot de passe doit ignorer la casse. Ceci est utile pour le codage de mots de passe hachés quand le mot de passe haché n'est pas significatif.
|
principalClass
| Un nom de classe complet. |
aucun
|
Une classe d'implémentation de
Principalcontenant un constructeur qui prend l'argument du String comme nom de principal.
|
roleGroupSeparator
|
Un seul caractère
| . (un seul point)
|
Le caractère utilisé pour séparer le nom d'utilisateur du nom de groupe de rôle dans le fichier
rolesGroup.
|
defaultUsersProperties
| chaîne | defaultUsers.properties
|
Nom de la ressource ou du fichier où se replier si le fichier usersProperties est introuvable.
|
defaultRolesProperties
| chaîne | defaultRoles.properties
|
Nom de la ressource ou du fichier où se replier si le fichier
rolesProperties est introuvable.
|
hashUserPassword
| true ou false
| true
|
Indique si on doit hacher le mot de passe entré par l'utilisateur, lorsqu'
hashAlgorithm est indiqué. La valeur par défaut est true.
|
hashStorePassword
| true ou false
| true
|
Indique le mot de passe de store retourné quand le
getUsersPassword() doit être haché, quand hashAlgorithm est spécifié.
|
digestCallback
| Un nom de classe complet. |
aucun
|
Le nom de classe de l'implémentation
org.jboss.crypto.digest.DigestCallback qui inclut le contenu pre/post digest comme les valeurs salt. Utilisé uniquement si l'hashAlgorithm est spécifié.
|
storeDigestCallback
| Un nom de classe complet. |
aucun
|
Le nom de classe de l'implémentation
org.jboss.crypto.digest.DigestCallback qui inclut le contenu pre/post digest comme les valeurs salt pour hacher le mot de passe du store. Utilisé uniquement si l'hashStoreAlgorithm est sur true et si hashAlgorithm est spécifié.
|
callback.option.STRING
| Divers | aucun |
Toutes les options ayant comme préfixe
callback.option. sont passées à la méthode DigestCallback.init(Map). Le nom d'utilisateur entré est toujours passé par l'option javax.security.auth.login.name, et le mot de passe input/store password est passé par l'option javax.security.auth.login.password au digestCallback ou au storeDigestCallback.
|
Tableau A.7. CertificateRoles
| Code | CertificateRoles
|
| Class | org.jboss.security.auth.spi.CertRolesLoginModule
|
| Description |
Ce module de connexion étend le module de connexion de certificat pour ajouter des fonctions de mappage de rôle à partir d'un fichier de propriétés. Il prend les mêmes options que le module de connexion du certificat et ajoute les options suivantes.
|
Tableau A.8. Options de module CertificateRoles
| Option | Type | Par défaut | Description |
|---|---|---|---|
rolesProperties
| Une chaîne | roles.properties
|
Le nom de la ressource ou du fichier contenant les rôles à attribuer à chaque utilisateur. Le fichier de propriétés de rôle doit être dans sous format nom d'utilisateur=role1,role2, où le nom d'utilisateur est le nom unique du certificat, sans signe égal ou espace blanc. L'exemple suivant est dans le bon format :
CN\=unit-tests-client,\ OU\=Red\ Hat\ Inc.,\ O\=Red\ Hat\ Inc.,\ ST\=North\ Carolina,\ C\=US=JBossAdmin |
defaultRolesProperties
| Une chaîne | defaultRoles.properties
|
Nom de la ressource ou du fichier où se replier si le fichier
rolesProperties est introuvable.
|
roleGroupSeparator
| Un seul caractère | . (un seul point)
|
Le caractère à utiliser comme séparateur de groupe rôle dans le fichier de
roleProperties
|
Tableau A.9. Database
| Code | Database |
| Class | org.jboss.security.auth.spi.DatabaseServerLoginModule
|
| Description |
Un module de connexion basé-JDBC supportant le mappage de rôle et l'authentification. Basé sur deux tables logiques, avec les définitions suivantes.
|
Tableau A.10. Database Module Options
| Option | Type | Par défaut | Description |
|---|---|---|---|
dsJndiName
| Ressource JNDI |
aucun
|
Le nom de la ressource JNDI qui store les informations d'authentification. Cette option est requise.
|
principalsQuery
| Énoncé SQL | select Password from Principals where PrincipalID=?
|
La requête SQL préparée pour obtenir les informations sur le principal.
|
rolesQuery
| Énoncé SQL | select Role, RoleGroup from Roles where PrincipalID=?
|
Enoncé SQL préparé en vue d'exécuter pour mapper les rôles. Doit être équivalent à
select Role, RoleGroup from Roles where PrincipalID=?, avec Role comme nom de rôle et la valeur de la colonne RoleGroup doit toujours être Roles. avec un R majuscule.
|
Tableau A.11. DatabaseCertificate
| Code | DatabaseCertificate
|
| Class | org.jboss.security.auth.spi.DatabaseCertLoginModule
|
| Description |
Ce module de connexion étend le module de connexion de certificat pour ajouter des fonctions de mappage de rôle d'une table de bases de données. Il possède les mêmes options mais aussi ces options supplémentaires :
|
Tableau A.12. DatabaseCertificate Module Options
| Option | Type | Par défaut | Description |
|---|---|---|---|
dsJndiName
| Ressource JNDI | |
Le nom de la ressource JNDI qui store les informations d'authentification. Cette option est requise.
|
rolesQuery
| Énoncé SQL | select Role,RoleGroup from Roles where PrincipalID=?
|
Enoncé SQL préparé en vue d'exécuter pour mapper les rôles. Doit être équivalent à
select Role, RoleGroup from Roles where PrincipalID=?, avec Role comme nom de rôle et la valeur de la colonne RoleGroup doit toujours être Roles. avec un R majuscule.
|
suspendResume
| true ou false
| true
|
Indique si une transaction JTA existante doit être suspendue pendant les opérations de base de données.
|
Tableau A.13. Identity
| Code | Identity
|
| Class | org.jboss.security.auth.spi.IdentityLoginModule
|
| Description |
Associe le principal spécifié dans les options de module avec n'importe quel sujet authentifié dans le module. Le type de classe de principal utilisée est
org.jboss.security.SimplePrincipal.. Si aucune option de principal n'est spécifiée, on utilisera un principal ayant pour nom guest.
|
Tableau A.14. Options de module Identity
| Option | Type | Par défaut | Description |
|---|---|---|---|
principal
| Une chaîne | guest
|
Le nom à utiliser pour le principal.
|
roles
| Une liste de strings séparée par des virgules |
aucun
|
Une liste de rôles séparée par des virgules qui sera assignée au sujet.
|
Tableau A.15. Ldap
| Code | Ldap
|
| Class | org.jboss.security.auth.spi.LdapLoginModule
|
| Description |
Authentifie sur un serveur LDAP, lorsque le nom d'utilisateur et le mot de passe sont stockés dans un serveur LDAP qui est accessible à l'aide d'un fournisseur LDAP JNDI. Bon nombre des options ne sont pas requises, car elles sont déterminées par le fournisseur LDAP ou l'environnement.
|
Tableau A.16. Options de module Ldap
| Option | Type | Par défaut | Description |
|---|---|---|---|
java.naming.factory.initial
| class name | com.sun.jndi.ldap.LdapCtxFactory
|
Nom de classe de l'implémentation
InitialContextFactory.
|
java.naming.provider.url
| ldap:// URL
|
aucun
|
URL pour le serveur LDAP
|
java.naming.security.authentication
| none, simple, ou le nom d'un mécanisme SASL
| simple
|
Le niveau de sécurité à utiliser pour la liaison avec le serveur LDAP.
|
java.naming.security.protocol
| Protocole de transport |
Si non spécifié, déterminé par le fournisseur.
|
Le protocole de transport à utiliser pour l'accès sécurisé, comme SSL.
|
java.naming.security.principal
| Une chaîne |
aucun
|
Le nom du principal permettant d'authentifier l'appelant vers le service. Il est construit à partir des autres propriétés décrites ci-dessous.
|
java.naming.security.credentials
| Un type d'information d'identification |
aucun
|
Le type d'information d'identification utilisée par le schéma d'authentification. Exemples : mot de passe haché, mot de passe de texte clair, clé ou certificat. Si cette propriété n'est pas spécifiée, le comportement est déterminé par le fournisseur de service.
|
principalDNPrefix
| Une chaîne |
aucun
|
Préfixe ajouté au nom d'utilisateur pour former le DN de l'utilisateur. Vous pouvez demander à l'utilisateur un nom d'utilisateur et créer le nom de domaine DN complet en utilisant
principalDNPrefix et principalDNSuffix.
|
principalDNSuffix
| chaîne | |
Suffixe ajouté au nom d'utilisateur pour former le DN de l'utilisateur. Vous pouvez demander à l'utilisateur un nom d'utilisateur et créer le nom de domaine DN complet en utilisant
principalDNPrefix et principalDNSuffix.
|
useObjectCredential
| true ou false
|
false
|
Si les informations d'identification doivent être obtenues sous forme d'objet opaque à l'aide du type de Callback
org.jboss.security.auth.callback.ObjectCallback plutôt que comme mot de passe char[] utilisant un JAAS PasswordCallback. Cela permet de passer les informations d'identification non-char[] au serveur Ldap.
|
rolesCtxDN
| DN complet |
aucun
|
Le DN complet pour le contexte à chercher pour les rôles d'utilisateur.
|
userRolesCtxDNAttributeName
|
Attribut
|
aucun
|
L'attribut dans l'objet utilisateur qui contient le nom unique DN pour que le contexte rechercher des rôles d'utilisateur. Cela diffère de
rolesCtxDN dans ce contexte de recherche car les rôles d'un utilisateur peuvent être uniques pour chaque utilisateur.
|
rolesAttributeID
| Attribut | roles
|
Nom de l'attribut qui contient les rôles d'utilisateur.
|
rolesAttributeIsDN
| true ou false
| false
|
Indique si le
roleAttributeID contient le nom de domaine complet d'un objet de rôle. Si false, le nom de rôle est tiré de la valeur de l'attribut roleNameAttributeId du nom de contexte. Certains schémas de répertoire, tel que Active Directory, requièrent que cet attribut soit défini à true.
|
rolesNameAttributeID
| Attribut | group
|
Nom de l'attribut du contexte de
roleCtxDN qui contient le nom de rôle. Si la propriété roleAttributeIsDN est définie sur true, cette propriété sera utilisée pour rechercher l'attribut de nom de l'objet rôle.
|
uidAttributeID
| Attribut | uid
|
Nom de l'attribut qui contient le
UserRolesAttributeDN correspondant à l'ID d'utilisateur. Utilisé pour localiser les rôles d'utilisateur.
|
matchOnUserDN
| true ou false
| false
|
Si la recherche de rôles d'utilisateur doit correspondre au DN de l'utilisateur entièrement distinct ou au nom d'utilisateur uniquement. Si
true, l'userDN complet sera utilisé comme valeur de correspondance. Si false, seul le nom d'utilisateur sera utilisé comme valeur de correspondance pour l'attribut UserRolesAttributeDN.
|
allowEmptyPasswords
| true ou false
| true
|
Indique si on doit autoriser les mots de passe vides. La plupart des serveurs LDAP traitent les mots de passe vides comme des tentatives de connexion anonymes. Pour rejeter les mots de passe vides, définir à false.
|
Tableau A.17. LdapExtended
| Code | LdapExtended
|
| Class | org.jboss.security.auth.spi.LdapExtLoginModule
|
| Description |
Une autre implémentation de module de connexion LDAP qui utilise les recherches pour localiser l'utilisateur de liaisons et rôles associés. La requête de rôles suit récursivement les noms de domaines DN pour naviguer dans une structure de rôles hiérarchique. Il utilise les mêmes options
java.naming que le module Ldap, et utilise les options suivantes à la place des autres options du module Ldap.
L'authentification a lieu en 2 étapes :
|
Tableau A.18. Options de module LdapExtended
| Option | Type | Par défaut | Description |
|---|---|---|---|
baseCtxDN
| DN complet |
aucun
|
Le DN fixe de contexte de niveau supérieur pour commencer la recherche utilisateur.
|
bindDN
| DN complet |
aucun
|
Le DN utilisé pour la liaison au serveur LDAP pour les requêtes d'utilisateurs et de rôles. Ce nom unique a besoin d'autorisations de lecture et de recherche pour les valeurs
baseCtxDN et rolesCtxDN.
|
bindCredential
| Un string, parfois crypté |
aucun
|
Le mot de passe pour le
bindDN. Peut être crypté si le jaasSecurityDomain est spécifié.
|
jaasSecurityDomain
| JMX ObjectName |
aucun
|
L'
ObjectName JMX du JaasSecurityDomain à utiliser pour décrypter les bindCredential. La forme cryptée du mot de passe correspond au format retourné par la méthode JaasSecurityDomain.encrypt64(byte[]).
|
baseFilter
| String de filtre LDAP |
aucun
|
Un filtre de recherche permettant de localiser le contexte de l'utilisateur à authentifier. L'entrée username ou userDN obtenue à partir du rappel de module de connexion est substitué dans le filtre à chaque fois qu'une expression
{0} est utilisée. Un exemple de filtre de recherche est (uid={0}).
|
rolesCtxDN
| DN complet |
aucun
|
Le DN fixe du contexte pour rechercher des rôles d'utilisateur. Ce n'est pas le DN où les rôles se trouvent, mais le DN où les objets contenant les rôles d'utilisateur se trouvent. Par exemple, dans un serveur Active Directory de Microsoft, c'est le DN où le compte d'utilisateur se trouve.
|
roleFilter
| String de filtre LDAP | |
Un filtre de recherche permettant de localiser les rôles associés à l'utilisateur authentifié. L'entrée user ou userDN obtenue à partir du rappel de module de connexion est substitué dans le filtre à chaque fois qu'une expression
{0} est utilisée. L'utilisateurDN (userDN) authentifié sera substitué dans le filtre à chaque fois qu'un {1} est utilisé. Un exemple de filtre de recherche qui correspond au nom d'utilisateur d'entrée serait (member={0}). Un autre correspondant au userDN authentifié pourrait être (member={1}).
|
roleAttributeIsDN | true ou false
| false
|
Indique si le
roleAttributeID contient le nom de domaine complet d'un objet de rôle. Si false, le nom de rôle est tiré de la valeur de l'attribut roleNameAttributeId du nom de contexte. Certains schémas de répertoire, tel que Active Directory, requièrent que cet attribut soit défini à true.
|
defaultRole
|
Un nom de rôle.
|
aucun
|
Un rôle inclus pour tous les utilisateurs authentifiés
|
parseRoleNameFromDN
| true ou false
| false
|
Un indicateur qui signale si le DN retourné par une requête contient le roleNameAttributeID. Si la valeur est
true, le DN est vérifié pour le roleNameATtributeID. Si la valeur est false, le DN n'est pas coché pour le roleNameAttributeID. Cet indicateur peut améliorer les performances des requêtes LDAP.
|
parseUsername
| true ou false
| false
|
Un indicateur qui signale si le DN doit être vérifié niveau nom d'utilisateur. Si la valeur est
true, le DN est vérifié niveau nom d'utilisateur. Si la valeur est false, le DN n'est pas vérifié au niveau nom d'utilisateur. Cet option peut à la fois être utilisée pour usernameBeginString et usernameEndString.
|
usernameBeginString
|
une chaîne
|
aucun
|
Définit le string qui doit être supprimé au début du DN pour révéler le nom d'utilisateur. Cette option est utilisée avec
usernameEndString.
|
usernameEndString
|
une chaîne
|
aucun
|
Définit le string qui doit être supprimé à la fin du DN pour révéler le nom d'utilisateur. Cette option est utilisée avec
userBeginString.
|
roleNameAttributeID
| Attribut | group
|
Nom de l'attribut du contexte de
roleCtxDN qui contient le nom de rôle. Si la propriété roleAttributeIsDN est définie sur true, cette propriété sera utilisée pour rechercher l'attribut de nom de l'objet rôle.
|
distinguishedNameAttribute
| Attribut | distinguishedName
|
Le nom de l'attribut dans l'entrée de l'utilisateur qui contient le nom unique de l'utilisateur. Ceci peut être nécessaire si le DN de l'utilisateur lui-même contient des caractères spéciaux (barre oblique inverse par exemple) qui empêchent le mappage de l'utilisateur. Si l'attribut n'existe pas, le DN de l'entrée sera utilisé.
|
roleRecursion
| Un entier relatif | 0
|
Le nombre de niveaux de récursivité de la recherche de rôle dans un contexte de correspondance donné. Désactiver la récursivité en attribuant le paramètre
0.
|
searchTimeLimit
| Un entier relatif | 10000 (10 seconds)
|
Timeout en millisecondes pour les recherches utilisateur/rôle.
|
searchScope
|
Un parmi :
OBJECT_SCOPE, ONELEVEL_SCOPE, SUBTREE_SCOPE
| SUBTREE_SCOPE
|
Étendue à utiliser.
|
allowEmptyPasswords
| true ou false
| true
|
Indique si on doit autoriser les mots de passe vides. La plupart des serveurs LDAP traitent les mots de passe vides comme des tentatives de connexion anonymes. Pour rejeter les mots de passe vides, définir à false.
|
Tableau A.19. RoleMapping
| Code | RoleMapping
|
| Class | org.jboss.security.auth.spi.RoleMappingLoginModule
|
| Description |
Mappe un rôle qui est le résultat final du processus d'authentification de manière déclarative. Ce module doit être marqué comme étant
optionnel quand vous y ajoutez le domaine de sécurité.
|
Tableau A.20. Options de module RoleMapping
| Option | Type | Par défaut | Description |
|---|---|---|---|
rolesProperties
| Le chemin d'accès complet et le nom d'une ressource ou d'un fichier de propriétés | roles.properties
|
Nom de la ressource ou du fichier de propriétés qui mappe les rôles aux rôles de remplacement. Le format est
original_role=role1,role2,role3
|
replaceRole
| true ou false
| false
|
Indique si on doit ajouter les rôles en cours, ou les remplacer par les rôles mappés. Sont remplacés si définis sur
true.
|
Tableau A.21. RunAs
| Code | RunAs
|
| Class | Class: org.jboss.security.auth.spi.RunAsLoginModule
|
| Description |
Un module d'assistance qui pousse un rôle
run as dans la pile pour la durée de la phase d'authentification de la connexion, et qui extrait le rôle run as de la pile soit dans la phase commit ou abort. Ce module de connexion fournit un rôle pour les autres modules de connexion qui doivent accéder aux ressources sécurisées afin d'effectuer leur authentification, par exemple un module de connexion qui accède à un EJB sécurisé. RunAsLoginModule doit être configuré avant que les modules de connexion qui ont besoin d'une rôle run as soient mis en place.
|
Tableau A.22. Options RunAs
| Option | Type | Par défaut | Description |
|---|---|---|---|
roleName
| Un nom de rôle. | nobody
|
Le nom de rôle à utiliser comme rôle
run as pendant la phase de connexion.
|
Tableau A.23. Simple
| Code | Simple
|
| Class | org.jboss.security.auth.spi.SimpleServerLoginModule
|
| Description |
Module d'installation rapide de sécurité pour les tests. Implémente ce simple algorithme :
|
Simple Module Options
Le module Simple n'a pas d'options.
Tableau A.24. ConfiguredIdentity
| Code | ConfiguredIdentity
|
| Class | org.picketbox.datasource.security.ConfiguredIdentityLoginModule
|
| Description |
Associe le principal spécifié dans les options du module avec n'importe quel sujet authentifié dans le module. Le type de classe du Principal classe est
org.jboss.security.SimplePrincipal.
|
Tableau A.25. ConfiguredIdentity Module Options
| Option | Type | Par défaut | Description |
|---|---|---|---|
principal
| Nom d'un principal. | guest
|
Le principal qui sera associé avec n'importe quel sujet authentifié dans le module.
|
Tableau A.26. SecureIdentity
| Code | SecureIdentity
|
| Class | org.picketbox.datasource.security.SecureIdentityLoginModule
|
| Description |
Ce module est fourni à des fins d'héritage. Il permet de crypter un mot de passe et ensuite d'utiliser le mot de passe crypté avec un principal statique. Si votre application utilise
SecureIdentity, envisager plutôt d'utiliser un mécanisme d'archivage sécurisé de mot de passe.
|
Tableau A.27. Options de module SecureIdentity
| Option | Type | Par défaut | Description |
|---|---|---|---|
username
| chaîne | aucun | Le nom d'utilisateur pour l'authentification. |
password
| string encodé | aucun |
Le mot de passe à utiliser pour l'authentification. Pour crypter le mot de passe, utilisez le module directement dans la ligne de commande.
Coller le résultat de cette commande dans le champ d'option de module.
|
managedConnectionFactoryName
| Une ressource JCA | aucun |
Le nom de la fabrique de connexions JCA à utiliser pour votre source de données.
|
Tableau A.28. PropertiesUsers
| Code | PropertiesUsers
|
| Class | org.jboss.security.auth.spi.PropertiesUsersLoginModule
|
| Description |
Utilise un fichier de propriétés pour stocker les noms d'utilisateur et mots de passe pour l'authentification. Aucune autorisation (correspondance de rôle) n'est fournie. Ce module convient seulement pour les tests.
|
Tableau A.29. Options de module PropertiesUsers
| Option | Type | Par défaut | Description |
|---|---|---|---|
properties
| Le chemin d'accès complet et le nom d'une ressource ou d'un fichier de propriétés Java. | aucun |
Le fichier de propriétés contenant les noms d'utilisateur et mots de passe en texte clair à utiliser pour l'authentification.
|
Tableau A.30. SimpleUsers
| Code | SimpleUsers
|
| Class | org.jboss.security.auth.spi.SimpleUsersLoginModule
|
| Description |
Ce module de connexion stocke le nom d'utilisateur et le mot de passe en texte clair dans un fichier de propriétés de Java. Il est inclus pour les essais uniquement et n'est pas approprié pour un environnement de production.
|
Tableau A.31. Options de module SimpleUsers
| Option | Type | Par défaut | Description |
|---|---|---|---|
username
| chaîne | aucun | Le nom d'utilisateur pour l'authentification. |
password
| chaîne | aucun | Le nom d'utilisateur en texte clair pour l'authentification. |
Tableau A.32. LdapUsers
| Code | LdapUsers
|
| Class | org.jboss.security.auth.spi.LdapUsersLoginModule
|
| Description |
Le module
LdapUsers est remplacé par les modules ExtendedLDAP et AdvancedLdap.
|
Tableau A.33. Kerberos
| Code | Kerberos
|
| Class | com.sun.security.auth.module.Krb5LoginModule
|
| Description |
Effectue l'authentification de connexion Kerberos avec GSSAPI. Ce module fait partie de la structure de sécurité de l'API fourni par Sun Microsystems. Vous trouverez des informations à ce sujet dans http://docs.oracle.com/javase/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html. Ce module devra être mis en correspondance avec un autre module qui gère les mappages d'authentification et de rôles.
|
Tableau A.34. Options de module Kerberos
| Option | Type | Par défaut | Description |
|---|---|---|---|
storekey
| true ou false
| false |
Indique si on doit ajouter
KerberosKey dans les informations d'authentification privées du sujet.
|
doNotPrompt
| true ou false
| false |
Si défini à
true, l'utilisateur n'aura pas besoin de mot de passe.
|
useTicketCache
|
Valeur booléenne de
. true ou false
| false |
Si défini à
true, le GTG sera obtenu à partir du cache du ticket. Si défini sur false, le cache du ticket ne sera pas utilisé.
|
ticketcache
| Un fichier ou une ressource qui représente un cache de ticket Kerberos. |
La valeur par défaut dépend du système d'exploitation que vous utilisez.
| Emplacement du ticketcache. |
useKeyTab
| true ou false
| false | Indique si on doit obtenir la clé du principal à partir d'un keytab. |
keytab
| Un fichier ou une ressource représentant un onglet de clé Kerberos. |
l'emplacement du fichier de configuration Kerberos du système d'exploitation, ou
/home/user/krb5.keytab
| Emplacement du fichier keytab. |
principal
| Une chaîne | aucun |
Le nom du principal. Cela peut être un simple nom d'utilisateur ou un nom de service tel que
host/testserver.acme.com. Utiliser cela au lieu d'obtenir le principal d'un fichier keytab, ou lorsque le fichier keytab contient plus d'un principal.
|
useFirstPass
| true ou false
| false |
Indique si on doit extraire le nom d'utilisateur et le mot de passe de l'état partagé du module à l'aide de
javax.security.auth.login.name et de javax.security.auth.login.password comme clés. Si l'authentification échoue, il n'y aura pas de nouvelle tentative.
|
tryFirstPass
| true ou false
| false |
Identique à
useFirstPass, mais si l'authentification échoue, le module utilise le CallbackHandler pour récupérer un nouveau nom d'utilisateur et mot de passe. Si la seconde authentification échoue, l'échec sera signalé à l'application appelante.
|
storePass
| true ou false
| false |
Indique si on doit stocker le nom d'utilisateur et le mot de passe de l'état partagé du module. N'a pas lieu si les clés existent déjà dans l'état partagé, ou si l'authentification a échoué.
|
clearPass
| true ou false
| false |
Définir à
true pour supprimer le nom de l'utilisateur et le mot de passe de l'état partagé une fois que les deux phases d'authentification sont terminées.
|
Tableau A.35. SPNEGOUsers
| Code | SPNEGOUsers
|
| Class | org.jboss.security.negotiation.spnego.SPNEGOLoginModule
|
| Description |
Effectue l'authentification de connexion SPNEGO vers un serveur Microsoft Active Directory ou autre environnement qui supporte SPNEGO. SPNEGO peut également transporter les informations d'identification de Kerberos. Ce module a besoin de fonctionner en parallèle à un autre module qui gère l'authentification et le mappage des rôles.
|
Tableau A.36. Options de module SPNEGO
| Option | Type | Par défaut | Description |
|---|---|---|---|
storeKey
| true ou false
| false
|
Indique si on doit stocker la clé ou non.
|
useKeyTab
| true ou false
| false
|
Indique si on doit utiliser un keytab.
|
principal
|
String représentant un principal d'authentification.
|
aucun
|
Le nom du principal pour l'authentification.
|
keyTab
|
Un fichier ou une ressource représentant un keytab.
| none
|
L'emplacement d'un keytab.
|
doNotPrompt
| true ou false
| false
|
Si on doit demander un mot de passe.
|
debug
| true ou false
| false
|
Indique si on doit enregistrer plus de messages verbeux pour pouvoir déboguer.
|
Tableau A.37. AdvancedLdap
| Code | AdvancedLdap |
| Class | org.jboss.security.negotiation.AdvancedLdapLoginModule
|
| Description |
Module qui fournit davantage de fonctionnalité, comme SASL et l'utilisation d'un domaine de sécurité JAAS.
|
Tableau A.38. Options de module AdvancedLdap
| Option | Type | Par défaut | Description |
|---|---|---|---|
bindAuthentication
|
chaîne
|
aucun
|
Le type d'authentification SASL à utiliser pour se lier au serveur de répertoires.
|
jassSecurityDomain
| string
|
aucun
|
Le nom du domaine de sécurité JAAS à utiliser.
|
java.naming.provider.url
| string
|
aucun
|
L'URI du serveur de répertoires.
|
baseCtxDN
|
DN (Nom Distinctif) complet
|
aucun
|
Le nom distinctif à utiliser comme base pour les recherches.
|
baseFilter
|
Chaîne représentant un filtre de recherche LDAP
|
aucun
|
Le filtre à utiliser pour réduire les résultats des recherches.
|
roleAttributeID
|
Chaîne représentant un attribut LDAP
|
aucun
|
L'attribut LDAP qui contient les noms des rôles d'autorisation.
|
roleAttributeIsDN
| true ou false
| false
|
Indique si l'attribut de rôle est un Nom Distinctif (DN).
|
roleNameAttributeID
|
Chaîne représentant un attribut LDAP
|
aucun
|
L'attribut contenu dans
RoleAttributeId qui contient lui-même l'attribut de rôle.
|
recurseRoles
| true ou false
| false
|
Indique si on doit chercher récursivement des rôles dans
RoleAttributeId.
|
Tableau A.39. AdvancedADLdap
| Code | AdvancedADLdap |
| Class | org.jboss.security.negotiation.AdvancedADLoginModule
|
| Description |
Ce module étend le module de connexion
AdvancedLdap, et ajoute des paramètres supplémentaires utiles au répertoire Microsoft Active DIrectory.
|
Tableau A.40. UsersRoles
| Code | UsersRoles |
| Class | org.jboss.security.auth.spi.UsersRolesLoginModul
|
| Description |
Un module de connexion supportant des utilisateurs multiples et des rôles utilisateur stockés dans deux fichiers de propriétés différents.
|
Tableau A.41. Options de module UsersRoles
| Option | Type | Par défaut | Description |
|---|---|---|---|
usersProperties
|
Chemin d'accès à un fichier ou à une ressource.
| users.properties
|
Fichier ou ressource qui contient les mappages d'utilisateur aux mots de passe. Le format du fichier est
user=hashed-password
|
rolesProperties
|
Chemin d'accès à un fichier ou à une ressource.
| roles.properties
|
Fichier ou ressource qui contient les mappages d'utilisateur aux rôles. Le format du fichier est
username=role1,role2,role3
|
password-stacking
| useFirstPass ou false
| false
|
La valeur de
useFirstPass indique si ce module de connexion doit tout d'abord rechercher les informations stockées dans le LoginContext à utiliser comme identité. Cette option peut être utilisée lorsque vous empilez les autres modules de connexion avec celui-ci.
|
hashAlgorithm
|
Chaîne représentant un algorithme de hachage de mot de passe.
| none
|
Le nom de l'algorithme
java.security.MessageDigest à utiliser pour hacher le mot de passe. Il n'y a pas de valeur par défaut pour cette option, donc vous devez la définir explicitement pour permettre le hachage. Quand hashAlgorithm est spécifié, le mot de passe en texte clair obtenu de CallbackHandler isera haché avant d'être passé à UsernamePasswordLoginModule.validatePassword comme argument inputPassword. Le mot de passe stocké dans le fichier users.properties doit être haché de façon similaire.
|
hashEncoding
| base64 ou hex
| base64
|
Le format du string du mot de passe haché, si hashAlgorithm est défini également.
|
hashCharset
|
Une chaîne
|
Le codage par défaut défini dans l'environnement runtime du conteneur.
|
Le codage utilisé pour convertir le mot de passe de texte en clair en un tableau d'octets.
|
unauthenticatedIdentity
|
Un nom de principal
|
aucun
|
Définit le nom principal affecté aux demandes qui ne contiennent aucune information d'authentification. Cela peut permettre à des servlets non protégés d'appeler des méthodes sur EJB ne nécessitant pas un rôle spécifique. Un tel principal ne possédera aucun rôle associé et ne ne pourra accéder qu'aux méthodes EJB ou EJB non sécurisées associées à la contrainte de
permission non contrôlée.
|
Modules d'authentification personnalisés
Les modules d'authentification sont des implémentations de org.jboss.security.LoginModule. Consulter la documentation de l'API pour obtenir plus d'informations sur la façon de créer un module d'authentification personnalisé.
A.2. Modules d'autorisation inclus
Les modules suivants procurent des services d'autorisation.
| Code | Class |
|---|---|
| DenyAll | org.jboss.security.authorization.modules.AllDenyAuthorizationModule |
| PermitAll | org.jboss.security.authorization.modules.AllPermitAuthorizationModule |
| Delegating | org.jboss.security.authorization.modules.DelegatingAuthorizationModule |
| Web | org.jboss.security.authorization.modules.WebAuthorizationModule |
| JACC | org.jboss.security.authorization.modules.JACCAuthorizationModule |
A.3. Modules de sécurité inclus
Les rôles de mappage de sécurité suivants sont fournis dans JBoss Enterprise Application Platform.
| Code | Class |
|---|---|
| PropertiesRoles | org.jboss.security.mapping.providers.role.PropertiesRolesMappingProvider |
| SimpleRoles | org.jboss.security.mapping.providers.role.SimpleRolesMappingProvider |
| DeploymentRoles | org.jboss.security.mapping.providers.DeploymentRolesMappingProvider |
| DatabaseRoles | org.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider |
| LdapRoles | org.jboss.security.mapping.providers.role.LdapRolesMappingProvider |
A.4. Modules de fournisseurs d'auditing de sécurité inclus
La plateforme Enterprise Application Platform fournit un fournisseur d'auditing de sécurité.
| Code | Class |
|---|---|
| LogAuditProvider | org.jboss.security.audit.providers.LogAuditProvider |
A.5. Référence de Configuration jboss-web.xml
Introduction
Le fichier jboss-web.xml se trouve dans WEB-INF ou dans le répertoire META-INF de votre déploiement. Il contient des informations de configuration sur des fonctionnalités que le conteneur JBoss Web ajoute au Servlet 3.0. Les paramètres de configuration spécifiques à la spécification de Servlet 3.0 se trouvent dans web.xml, dans le même répertoire.
L'élément qui se trouve tout en haut dans le fichier
jboss-web.xml est l'élément <jboss-web>.
Mappage des ressources globales aux prérequis WAR
La plupart des paramètres de configuration font correspondre les prérequis définis dans le fichier web.xml de l'application à des ressources locales. Pour plus d'explications sur les paramètres de configuraiton de web.xml consulter http://docs.oracle.com/cd/E13222_01/wls/docs81/webapp/web_xml.html.
Ainsi, si
web.xml requiert jdbc/MyDataSource, alors jboss-web.xml fera sans doute correspondre la source de données globale java:/DefaultDS pour remplir ce besoin. Le WAR utilise la source de données globale pour faire correspondre jdbc/MyDataSource.
Tableau A.42. Attributs de Haut niveau Communs
| Attribut | Description |
|---|---|
| env-entry |
Un mappage à
env-entry requis par web.xml.
|
| ejb-ref |
Un mappage à
ejb-ref requis par web.xml.
|
| ejb-local-ref |
Un mappage à
ejb-local-ref requis par web.xml.
|
| service-ref |
Un mappage à
service-ref requis par web.xml.
|
| resource-ref |
Un mappage à
resource-ref requis par web.xml.
|
| resource-env-ref |
Un mappage à
resource-env-ref requis par web.xml.
|
| message-destination-ref |
Un mappage à
message-destination-ref requis par web.xml.
|
| persistence-context-ref |
Un mappage à
persistence-context-ref requis par web.xml.
|
| persistence-unit-ref |
Un mappage à
persistence-unit-ref requis par web.xml.
|
| post-construct |
Un mappage à
post-context requis par web.xml.
|
| pre-destroy |
Un mappage à
pre-destroy requis par web.xml.
|
| data-source |
Un mappage à
data-source requis par web.xml.
|
| context-root | Le contexte root de l'application. La valeur par défaut est le nom du déploiement sans le suffixe .war. |
| virtual-host | Le nom de l'hôte virtuel HTTP à partir duquel l'application accepte les requêtes. Se réfère au contenu de l'en-tête de l'Host HTTP. |
| annotation | Décrit une annotation utilisée par l'application. Voir <annotation> pour plus d'information. |
| listener | Décrit un listener utilisé par l'application. Voir <listener> pour plus d'information. |
| session-config | Cet élément remplit la même fonction que l'élément <session-config> du fichier web.xml et est inclus dans un but de compatibilité seulement. |
| valve | Décrit une valve utilisée par l'application. Voir <valve> pour plus d'information. |
| overlay | Le nom d'une couche supplémentaire à ajouter à l'application. |
| security-domain | Le nom du domaine de sécurité utilisé par l'application. Le domaine de sécurité lui-même est configuré à partir de la console de gestion basée web ou le Management CLI. |
| security-role | Cet élément remplit la même fonction que l'élément <session-role> du fichier web.xml et est inclus dans un but de compatibilité seulement. |
| use-jboss-authorization | Si cet élément est présent et contient la valeur non sensible à la casse "true", la pile d'autorisation web JBoss sera utilisée. S'il n'est pas présent ou contient une valeur non "true", alors seuls les mécanismes d'autorisation indiqués dans les spécifications Java Enterprise Edition specifications seront utilisés. Cet élément est nouveau dans JBoss Enterprise Application Platform 6. |
| disable-audit | Si cet élément vide est présent, l'auditing de sécurité web sera désactivé. Sinon, il sera activé. L'auditing de sécurité web ne fait pas partie de la spécification Java EE. Cet élément est nouveau dans JBoss Enterprise Application Platform 6. |
| disable-cross-context | Si sur false, l'application sera en mesure d'appeler un autre contexte d'application. La valeur par défaut est true. |
Les éléments suivants ont chacun des éléments enfants.
<annotation>
Décrit une annotation utilisée par l'application. Le tableau suivant liste les éléments enfants d'une <annotation>.
Tableau A.43. Éléments de configuration d'une annotation
| Attribut | Description |
|---|---|
| class-name |
Nom de la classe de l'annotation
|
| servlet-security |
L'élément, comme
@ServletSecurity, qui représente la sécurité du servlet.
|
| run-as |
L'élément, comme
@RunAs, qui représente l'information run-as
|
| multi-part |
L'élément, comme
@MultiPart, qui représente l'information multi-part.
|
<listener>
Décrit un listener. Le tableau suivant liste les éléments enfants d'un <listener>.
Tableau A.44. Éléments de configuration d'un listener
| Attribut | Description |
|---|---|
| class-name |
Nom de la classe du listener
|
| listener-type |
Liste les éléments de
condition qui indiquent quel sorte de listener ajouter au contexte de l'application. Les choix valides sont les suivants :
|
| module |
Le nom du module qui contient la classe du listener.
|
| param |
Un paramètre. Contient deux éléments enfants,
<param-name> et <param-value>.
|
<valve>
Décrit une valve de l'application. Contient les mêmes éléments de configuration que <listener>.
A.6. Référence de paramètre de sécurité EJB
Tableau A.45. Éléments de paramètres de sécurité EJB
| Élément | Description |
|---|---|
<security-identity>
|
Contient des éléments enfants relatifs à l'identité de sécurité d'un EJB.
|
<use-caller-identity />
|
Indique que l'EJB utilise la même identité de sécurité que l'appelant.
|
<run-as>
|
Contient un élément
<role-name>.
|
<run-as-principal>
|
Si présent, indique le principal assigné aux appels sortants. Si non présent, les appels sortants sont assignés à un principal nommé
anonymous.
|
<role-name>
|
Spécifie le role d'exécution de l'EJB.
|
<description>
|
Décrit le role nommé dans
. <role-name>
|
Exemple A.1. Exemples d'identité de sécurité
Cet exemple décrit chaque balise décrite dans Tableau A.45, « Éléments de paramètres de sécurité EJB ». Peuvent également être mis dans un
<servlet>.
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>ASessionBean</ejb-name>
<security-identity>
<use-caller-identity/>
</security-identity>
</session>
<session>
<ejb-name>RunAsBean</ejb-name>
<security-identity>
<run-as>
<description>A private internal role</description>
<role-name>InternalRole</role-name>
</run-as>
</security-identity>
</session>
<session>
<ejb-name>RunAsBean</ejb-name>
<security-identity>
<run-as-principal>internal</run-as-principal>
</security-identity>
</session>
</enterprise-beans>
</ejb-jar>
Annexe B. Revision History
| Historique des versions | |||
|---|---|---|---|
| Version 1.1-3 | Thu Jul 11 2013 | ||
| |||
Note légale
Copyright © 2014 Red Hat, Inc..
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
