Guide de sécurité
À utiliser dans Red Hat JBoss Enterprise Application Platform 6
Red Hat Customer Content Services
Résumé
Partie I. Sécurité dans Red Hat JBoss Enterprise Application Platform 6
Chapitre 1. Introduction
1.1. Red Hat JBoss Enterprise Application Platform 6
1.2. Sécuriser JBoss Enterprise Application Platform 6
Partie II. Sécuriser la plate-forme
Chapitre 2. Java Security Manager
2.1. Java Security Manager
Java Security Manager est une classe qui gère la limite extérieure de la sandbox Java Virtual Machine (JVM), contrôlant ainsi comment le code exécuté dans la JVM peut interagir avec les ressources extérieures à 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.
2.2. Polices du Java Security Manager
Un jeu d'autorisations définies pour les différentes classes du code. Le Java Security Manager examine les requêtes en provenance des applications en fonction de la stratégie de sécurité. Si une action est autorisée par la stratégie, le Java Security Manager permettra que l'action ait lieu. Si l'action n'est pas autorisée par la stratégie, le Java Security Manager refusera cette action. La stratégie de sécurité peut définir des autorisations basées sur l'emplacement du code ou sur les principaux du sujet.
java.security.manager
et java.security.policy
.
Une entrée de police de sécurité consiste en les éléments de configuration suivants connectés au policytool
:
- 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 correspondre à 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 Java Security Manager.
- Principaux
- Une liste de paires
principal_type
/principal_name
, qui doivent être présentes au sein de l'ensemble principal du thread en cours d'exécution. L'entrée de principaux est facultative. Si elle est est omise, cela signifie que les principaux du thread en cours n'auront aucun impact sur le Java Security Manager. - 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).
2.3. Exécuter JBoss EAP 6 dans le Java Security Manager
domain.sh
ou standalone.sh
. La procédure suivante va vous guider à travers les étapes de configuration de votre instance pour exécuter au sein d'une stratégie Java Security Manager.
Pré-requis
- Avant de suivre cette procédure, vous devrez rédiger une stratégie de sécurité, en utilisant la commande
policytool
comprise dans votre Java Development Kit (JDK). Cette procédure assume que votre stratégie se trouve dansEAP_HOME/bin/server.policy
. Sinon, vous pouvez écrire la stratégie de sécurité à l'aide 'un éditeur de texte et la sauvegarder commeEAP_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édure 2.1. Configurer le gestionnaire de sécurité dans JBoss EAP 6
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é
- Dans Linux:
EAP_HOME/bin/domain.conf
- Dans Windows:
EAP_HOME\bin\domain.conf.bat
Serveur autonome
- Dans Linux:
EAP_HOME/bin/standalone.conf
- Dans Windows:
EAP_HOME\bin\standalone.conf.bat
Ajouter les options Java au fichier.
Pour s'assurer que les options Java soient bien utilisées, ajouter les au blic de code qui commence par :if [ "x$JAVA_OPTS" = "x" ]; then
Vous pouvez modifier la valeur de-Djava.security.policy
pour indiquer l'emplacement exact de votre police de sécurité. Cela ne doit prendre qu'une seule ligne, sans saut de ligne. Utiliser==
quand vous définissez la propriété-Djava.security.policy
indique que le gestionnaire de sécurité utilisera uniquement le fichier de police spécifié. Utiliser=
indique que le gestionnaire de sécurité utilisera la police spécifiée en combinaison à la police définie dans la sectionpolicy.url
deJAVA_HOME/lib/security/java.security
.Important
Les versions de JBoss Enterprise Application Platform à partir de 6.2.2 requièrent que la propriété systèmejboss.modules.policy-permissions
soit sur true.Exemple 2.1. domain.conf
JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==$PWD/server.policy -Djboss.home.dir=/path/to/EAP_HOME -Djboss.modules.policy-permissions=true"
Exemple 2.2. domain.conf.bat
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.manager -Djava.security.policy==\path\to\server.policy -Djboss.home.dir=\path\to\EAP_HOME -Djboss.modules.policy-permissions=true"
Exemple 2.3. standalone.conf
JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==$PWD/server.policy -Djboss.home.dir=$JBOSS_HOME -Djboss.modules.policy-permissions=true"
Exemple 2.4. standalone.conf.bat
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.manager -Djava.security.policy==\path\to\server.policy -Djboss.home.dir=%JBOSS_HOME% -Djboss.modules.policy-permissions=true"
Démarrer le domaine ou le serveur.
Démarrer le domaine ou le serveur en tant que normal.
2.4. Écrire une stratégie pour le Java Security Manager
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/.
Procédure 2.2. Définir une stratégie pour le Java Security Manager
Démarrez
policytool
.Démarrez l'outilpolicytool
d'une des façons suivantes.Red Hat Enterprise Linux
À partir de votre GUI ou invite de commande, exécutez/usr/bin/policytool
.Microsoft Windows Server
Exécutezpolicytool.exe
à partir du menu de Démarrage (Start) ou à partir debin\
de votre installation Java. L'emplacement peut varier.
Créer une stratégie.
Pour créer une stratégie, sélectionnez Add Policy Entry. Ajouter les paramètres dont vous aurez besoin, et cliquez sur Done.Modifier une stratégie existante
Sélectionnez la police à partir d'une liste de stratégies existantes, et sélectionnez le bouton Edit Policy Entry. Modifiez les paramètres suivant les besoins.Supprimer une stratégie existante.
Sélectionnez la stratégie à partir d'une liste de stratégies existantes, et sélectionnez le bouton Remove Policy Entry.
2.5. IBM JRE et Java Security Manager
JAVA_HOME/jre/lib/security/java.security
, et définir la valeur de policy.provider
à sun.security.provider.PolicyFile
.
policy.provider=sun.security.provider.PolicyFile
2.6. Débogage des stratégies du gestionnaire de sécurité
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 de l'aide 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 2.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 EAP 6 exécute sur une domaine géré, la ligne sera ajoutée au fichier
bin/domain.conf
de Linux ou au fichierbin\domain.conf.bat
de Windows. - Si l'instance de JBoss EAP exécute sur un domaine autonome, la ligne sera ajoutée au fichier
bin/standalone.conf
de Linux ou au fichierbin/standalone.conf.bat
de Windows.
Linux
JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
Windows
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.debug=access:failure"
Un niveau général d'informations de débogage lié à la sécurité a été activé.
Chapitre 3. Domaines de sécurité
3.1. Domaines de sécurité
ManagementRealm
stocke les informations d'authentification pour l'API de gestion, qui fournit les fonctionnalités pour l'interface CLI et la Console de gestion sur le web. Il fournit un système d'authentification pour gérer JBoss EAP 6 . Vous pouvez également utiliser leManagementRealm
si votre application a besoin des mêmes règles commerciales que vous utilisez pour l'API de gestion, lors de son authentification.ApplicationRealm
stocke l'utilisateur, le mot de passe et les informations de rôle pour les applications Web et les EJB.
REALM-users.properties
stocke les mots de passe et les mots de passe hachés.REALM-roles.properties
stocke les mappages user-to-role.mgmt-groups.properties
stocke le fichier de mappage user-to-group pourManagementRealm
. Utilisé uniquement quand RBAC (Role-based Access Control) est activé.
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.
3.2. Ajout d'un domaine de sécurité
Exécuter l'interface CLI
Démarrez par la commandejboss-cli.sh
oujboss-cli.bat
et 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éMyDomainRealm
sur 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écutez 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.sh
etadd-user.bat
inclus. Il devra être administré en externe./host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
Votre nouveau domaine de sécurité sera 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.
3.3. Ajout d'un utilisateur à un domaine de sécurité
Éxécuter la commande
add-user.sh
ouadd-user.bat
.Ouvrez un terminal (shell) et 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
.Choisir d'ajouter un utilisateur de gestion ou un utilisateur d'application.
Pour cette procédure, saisirb
pour 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
, ouno
pour annuler les changements. Les changements sont inscrits dans les fichiers de propriétés du domaine de sécurité.
Chapitre 4. Encoder le traffic réseau
4.1. Indiquer l'interface de réseau que JBoss EAP 6 utilise
Isolez les services afin qu'ils soient accessibles uniquement aux clients qui en ont besoin augmente la sécurité de votre réseau. JBoss EAP 6 comprend deux interfaces dans sa configuration par défaut, qui se lient à l'IP adresse 127.0.0.1
ou localhost
, par défaut. Une des interfaces est appelée gestion
et est utilisée par la Console de gestion, CLI et API. L'autre est appelé public
et est utilisé pour déployer des applications. Ces interfaces ne sont pas spéciales ou importantes, mais sont fournies comme point de départ.
management
utilise les ports 9990
et 9999
par défaut, et l'interface public
utilise le port 8080
, ou le port 8443
avec HTTPS.
Avertissement
Stopper le serveur JBoss EAP 6
Stoppez JBoss EAP 6 en envoyant une interruption de manière appropriée à votre système d'exploitation. Si vous exécutez JBoss EAP 6 comme une application de premier plan, il suffit d'appuyer sur Ctrl+C.Démarrer JBoss EAP 6 à nouveau, en spécifiant l'adresse de liaison.
Utilisez l'argument de ligne de commande-b
pour démarrer JBoss EAP 6 sur une interface particulière.Exemple 4.1. Indiquez l'interface publique.
EAP_HOME/bin/domain.sh -b 10.1.1.1
Exemple 4.2. Indiquez l'interface de gestion.
EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1
Exemple 4.3. Indiquez des adresses différentes pour chaque interface.
EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1
Exemple 4.4. Liez l'interface publique à toutes les interfaces de réseau.
EAP_HOME/bin/domain.sh -b 0.0.0.0
-b
pour spécifier une adresse IP en cours d'exécution, donc ce n'est pas recommandé. Si vous décidez de le faire, n'oubliez pas de stopper JBoss EAP 6 complètement avant d'éditer le fichier XML.
4.2. Configurer les pare-feux de réseau pour qu'ils fonctionnent dans JBoss EAP 6
La plupart des environnements de production utilisent des pare-feux dans le cadre d'une stratégie globale de sécurité réseau. Si vous avez besoin que plusieurs instances de serveur puissent communiquer entre eux 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 uniquement les ports qui sont nécessaires à l'opération et limite l'accès aux ports pour des adresses IP, des sous-réseaux et protocoles réseau spécifiques.
Pré-requis
- Déterminez les ports que vous souhaitez ouvrir.
- Vous devez avoir une bonne compréhension de vos logiciels de pare-feux. Cette procédure utilise la commande
system-config-firewall
de 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. Sur un serveur Microsoft Windows, vous pouvez utiliser PowerShell pour configurer le pare-feu.
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
- JBoss EAP 6 exécute sur l'hôte
10.1.1.2
. En option, le serveur peut avoir son propre pare-feu. - Le serveur du pare-feu de réseau exécute sur l'hôte
10.1.1.1
sur l'interfaceeth0
, et possède une interface externeeth1
. - Le trafic de réseau du port
5445
(port utilisé par JMS) devra être renvoyé sur JBoss EAP 6. Aucun autre trafic doit pouvoir transiter par le pare-feu du réseau.
Procédure 4.1. Gérer les pare-feux de réseau pour qu'ils soient opérationnels dans JBoss EAP 6
Connectez-vous à la Console de management.
Connectez-vous dans la Console de gestion. Par défaut, elle exécute sur http://localhost:9990/console/.Déterminez les liaisons de socket utilisées par le groupe de liaisons de socket.
- Cliquez sur l'étiquette Configuration qui se trouve en haut de la console de gestion.
- Étendre le menu General Configuration. Sélectionnez Socket Binding (liaison de sockets).
- L'écran Socket Binding Declarations apparaît. Au départ, le groupe
standard-sockets
apparaît. Choisissez un autre groupe en le sélectionnant à partir de la case de combo sur la 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 huit valeurs par page. Vous pourrez naviguer entre les pages grâce à la flèche de navigation en dessous du tableau.Déterminez 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 ouverts sur votre pare-feu.Configurez votre pare-feu pour redirigez 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-firewall
pour 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 Customize, 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 Forward, 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.
- Saisir
5445
dans le champ Port / Port Range, puis utiliser la clé TAB pour vous rendre dans le champ Protocol, puis saisirtcp
. Utiliser la clé TAB pour naviguer vers le bouton OK, puis appuyer sur ENTER. - Utiliser la clé TAB pour naviguer vers le bouton Forward jusqu'à atteindre l'écran 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
- Protocole :
tcp
- Port / Plage de port :
5445
- Destination IP address :
10.1.1.2
- Port / Plage de port :
5445
Utiliser la clé TAB pour naviguer vers le bouton OK, puis appuyer sur la clé ENTER. - Utiliser la clé TAB pour naviguer vers le bouton Close, puis appuyer sur la clé ENTER.
- Utiliser la clé TAB pour naviguer vers le bouton OK, puis appuyer sur ENTER. Pour appliquer les changements, lire la notice d'avertissement, puis appuyer sur Yes.
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. Voir Section 4.3, « Ports de réseau utilisés par 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 sauf22
(utilisé pour Secure Shell (SSH) et5353
(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.
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.
Procédure 4.2. Configurer le pare-feu dans Microsoft Windows avec PowerShell
- Désactiver le pare-feu pour déterminer si le comportement de réseau actuel est lié à la configuration du pare-feu à des fins de débogage.
Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall set allprofiles state off"'
- Autoriser les connexions UDP sur le port 23364. Par exemple :
Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall firewall add rule name="UDP Port 23364" dir=in action=allow protocol=UDP localport=23364"' Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall firewall add rule name="UDP Port 23364" dir=out action=allow protocol=UDP localport=23364"'
4.3. Ports de réseau utilisés par JBoss EAP 6
- 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é.
- Les exigences de vos déploiements individuels.
Note
8080
et si votre serveur utilise un décalage de port de 100
, son port HTTP sera 8180
.
Groupes de liaison de sockets par défaut
full-ha-sockets
full-sockets
ha-sockets
standard-sockets
Tableau 4.1. Référence aux Groupes de liaisons de sockets par défaut
Nom | Port | Port multi-diffusion | 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 | Multidiffusion. Utilisée pour découvrir des pairs dans les groupements HA. Non configurable par les Interfaces de gestion. | Oui | Non | Oui | Non | |
jgroups-mping | 45700 | Multidiffusion. Utilisée pour découvrir l'appartenance de groupe d'origine dans un cluster HA. | Oui | Non | Oui | Non | |
jgroups-tcp | 7600 | Découverte de pairs unicastes 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 pairs unicastes dans les groupements HA avec UDP. | 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 diffusion HornetQ JMS et les groupes Discovery | Oui | Oui | Non | Non | ||
messaging-throughput | 5455 | Utilisé par JMS Remoting. | Oui | Oui | Non | Non | |
mod_cluster | 23364 | Port de multidiffusion pour la communication entre JBoss EAP 6 et l'équilibreur de charges HTTP. | Oui | Non | Oui | Non | |
osgi-http | 8090 | Utilisé par les composants internes qui utilisent le sous-système OSGi. Non configurable par les Interfaces de gestion. | 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 |
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 web9999
- Le port utilisé par la Console de gestion et par le Managemetn API
4.4. Cryptage
4.5. Cryptage SSL
4.6. Implémentation du cryptage SSL pour le serveur de JBoss EAP 6.
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
- Un ensemble de clés de cryptage SSL et 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 4.7, « Générer une clé de cryptage SSL et un certificat ».
- Informations utiles sur votre environnement et sur votre installation :
- Le nom complet du répertoire où les fichiers de certificats sont stockés.
- Le mot de passe de cryptage pour vos clés de cryptage.
- Exécuter l'interface CLI et le connecter à votre contrôleur de domaine ou à votre serveur autonome.
Note
/profile=default
du début d'une commande de Management CLI.
Procédure 4.3. Configurer le JBoss Web Server pour qu'il puisse utiliser HTTPS
Ajoutez un nouveau connecteur HTTPS.
Exécutez 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 4.5. Commande de Management CLI
/profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
- Éxécutez la commande de Management CLI suivante pour définir le protocole à
TLSv1
.Exemple 4.6. Commande de Management CLI
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=TLSv1)
Sélectionnez les suites de cryptage qui conviennent
Il existe un certain nombre de primitives cryptographiques disponibles, utilisées comme blocs de base pour former des suites de chiffrement. Le premier tableau répertorie les primitives cryptographiques recommandées. Le deuxième énumère les primitives cryptographiques qui, bien qu'elles puissent être utilisées pour assurer la compatibilité avec les logiciels existants, ne sont pas considérées comme aussi sûres que celles qui sont recommandées.Avertissement
Red Hat recommande de faire une liste blanche sélective d'un ensemble d'algorithmes de chiffrage puissants à utiliser pour lacipher-suite
. L'activation de systèmes de chiffrage faibles est un risque important de sécurité. Consultez la documentation du fournisseur de votre JDK avant de statuer sur les suites de chiffrement particulières à utiliser, car il peut y avoir des problèmes de compatibilité.Tableau 4.2. Primitives cryptographiques recommandées
RSA avec clés 2048 bit et OAEP AES-128 en mode CBC SHA-256 HMAC-SHA-256 HMAC-SHA-1 Tableau 4.3. Autres primitives cryptographiques
RSA avec des clés qui dépassent 1024 et taille de remplissage héritée AES-192 AES-256 3DES (triple DES, avec deux ou trois clés de 56 bit) RC4 (fortement déconseillé) SHA-1 HMAC-MD5 Pour obtenir une liste complète des paramètres que vous pouvez définir pour les propriétés SSL du connecteur, voir Section 4.8, « Référence de connecteur SSL ».Configurer le certificat de cryptage SSL et les clés.
Exécutez la commande CLI suivante 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 4.7. 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, cipher-suite=CIPHERS)
Déployer une application.
Déployez 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 HTTPS en sa direction utilisent la nouvelle connexion cryptée-SSL.
4.7. Générer une clé de cryptage SSL et un certificat
Pré-requis
- La commande
keytool
doit être disponible. Elle est fournie par le Java Development Kit. 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 standard, car des discussions plus sophistiquées sur les spécificités des certificats SSL ou sur la commandekeytool
sont hors de portée de cette documentation.
Procédure 4.4. 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écutez la commande suivante pour générer un keystore nomméserver.keystore
ayant comme aliasjboss
dans votre répertoire actuel.keytool -genkeypair -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 -genkeypair
La commande keytool
qui génère une paire de clés contenant une clé publique et une clé privée.-alias
L'alias est pour le keystore. Cette valeur est arbitraire, mais l'alias jboss
est la valeur par défaut utilisée par le serveur JBoss Web.-keyalg
L'algorithme de création de paires de clés. Dans ce cas, c'est RSA
.-keystore
Le 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
.-storepass
Ce 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.-keypass
Il 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.--dname
Une 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", leCN
sera "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ètre 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
-storepass
sur 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'utilisez pas le paramètre
-keypass
sur 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.keystore
contiendra la clé unique avec l'aliasjboss
.Vérifier la clé.
Vérifiez 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 estPrivatekeyEntry
. 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 commandekeytool
crée alors une nouvelle demande de signature de certificat nomméecertreq.csr
dans le répertoire en cours d'utilisation.Tester la demande de signature de certificat nouvellement générée.
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 demande de signature de certificat à une autorité de certification (AC).
Une Autorité de Certification (AC) authentifie 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.ca
ouserver.crt
par 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 dont vous les transporterez entre les serveurs.keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.ca
keytool -importcert -alias jboss -keystore server.keystore -file server.crt
Testez que vos certificats soient bien importés avec succès.
Exécutez la commande suivante, et saisissez le mot de passe de keystore quand on vous le demandera. Les contenus de votre keystore seront affichés, et les certificats feront partie de la liste.keytool -list -keystore server.keystore
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.
4.8. Référence de connecteur SSL
par défaut
. Changez 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 4.4. Attributs de connecteurs SSL
Attribut | Description | Commande CLI |
---|---|---|
name |
Le nom d'affichage du connecteur SSL
|
L'attribute
name est en lecture seule.
|
verify-client |
Les valeurs possibles de
verify-client diffèrent selon qu'il s'agisse d'un connecteur HTTP/HTTPS ou d'un connecteur natif APR qui est utilisé.
Connecteur HTTP/HTTPS
Les valeurs possibles sont Connecteur APR natif
Les valeurs possibles sont |
La commande du premier exemple utilise le connecteur HTTPS.
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-client,value=want)
La commande du second exemple utilise le connecteur APR.
/profile=default/subsystem=web/connector=APR/ssl=configuration/:write-attribute(name=verify-client,value=require) |
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 EAP 6. 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éfinissez 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) |
password |
Le mot de passe pour le trustore et le keystore à la fois. Dans l'exemple suivant, remplacez PASSWORD par votre propre mot de passe.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=password,value=PASSWORD) |
protocol |
Version du protocole SSL à utiliser. Les valeurs prises en charge dépendent de l'implémentation sous-jacente (JSSE ou OpenSSL). Consultez Java SSE Documentation.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=ALL) |
cipher-suite |
Une liste des cryptages autorisés. Pour la syntaxe JSSE, cela devra corrrespondre à une liste séparée par des virgules. Pour la syntaxe OpenSSL, cela devra correspondre à une liste séparée par deux-points.
La valeur par défaut est
HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5 .
L'exemple ne mentionne que deux cryptages possibles, mais les exemples de la vie courante en utilisent d'autres.
Important
L'utilisation de cryptages faibles posent des risques de sécurité importants. Voir http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295 pour obtenir des informations NIST sur les suites de cryptage.
Pour obtenir une liste de cryptage OpenSSL, consultez https://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS. Notez que ce qui suit n'est pas pris en charge :
@SECLEVEL , SUITEB128 , SUITEB128ONLY , SUITEB192 .
|
/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. Dans l'exemple suivant, remplacez KEY_ALIAS par l'alias de votre certificat.
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=key-alias,value=KEY_ALIAS) |
truststore-type |
Le type de truststore. Il existe différents types de truststores, 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 pour le
ca-certificate-file . Dans l'exemple ci-dessous, remplacez MASKED_PASSWORD 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. Cet attribut s'applique uniquement aux connecteurs JSSE. La valeur par défaut est
0 , qui indique une taille de cache illimitée.
|
/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. Cet attribut s'applique uniquement aux connecteurs JSSE. 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) |
4.9. Encodage se conformant à FIPS 140-2
4.9.1. Conformité FIPS 140-2
4.9.2. Cryptographie compatible FIPS 140-2 dans JDK IBM
Stockage des clés
keytool
en mode compatible FIPS, utilisez l'option -providerClass
sur chaque commande, comme suit :
keytool -list -storetype JCEKS -keystore mystore.jck -storepass mystorepass -providerClass com.ibm.crypto.fips.provider.IBMJCEFIPS
Examinez les informations de fournisseur FIPS
-Djavax.net.debug=true
à standalone.conf
ou à domain.conf
. Les informations sur le fournisseur FIPS seront journalisées dans server.log
, comme par exemple :
04:22:45,685 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using MessageDigest SHA from provider IBMJCEFIPS version 1.7 04:22:45,689 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyPairGenerator from provider from init IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using KeyFactory DiffieHellman from provider IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using KeyAgreement DiffieHellman from provider IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyAgreement from provider IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyAgreement from provider from initIBMJCEFIPS version 1.7
4.9.3. Mots de passe conformes FIPS 140-2
- Une longueur minimale de sept (7) caractères.
- Il doit inclure des caractères d'au moins trois (3) des classes de caractères suivantes :
- chiffres ASCII,
- minuscules ASCII,
- majuscules ASCII,
- non alphanumériques ASCII, et
- non-ASCII.
4.9.4. Activer la Cryptography FIPS 140-2 pour SSL dans Red Hat Enterprise Linux 6
Pré-requis
- Red Hat Enterprise Linux 6 doit déjà être configuré pour être configuré en conformité avec FIPS 140-2. Voir https://access.redhat.com/knowledge/solutions/137833.
Procédure 4.5. Voir Conformité Cryptographie FIPS 140-2 pour SSL
Créez la base de données
Créez la base de données NSS dans un répertoire qui appartienne à l'utilisateurjboss
.$ mkdir -p /usr/share/jboss-as/nssdb $ chown jboss /usr/share/jboss-as/nssdb $ modutil -create -dbdir /usr/share/jboss-as/nssdb
Créez un fichier de configuration NSS
Créez un nouveau fichier texte ayant comme nomnss_pkcsll_fips.cfg
dans le répertoire/usr/share/jboss-as
avec le contenu suivant :name = nss-fips nssLibraryDirectory=/usr/lib64 nssSecmodDirectory=/usr/share/jboss-as/nssdb nssModule = fips
Le fichier de configuration NSS doit spécifier :- un nom,
- le répertoire où se trouve la bibliothèque, et
- le répertoire où la base de données NSS a été créée selon l'étape 1.
Si vous n'êtes pas sur une version 64bit de Red Hat Enterprise Linux 6, alors définisseznssLibraryDirectory
à/usr/lib
à la place de/usr/lib64
.Activez le fournisseur SunPKCS11
Modifiez le fichier de configurationjava.security
de votre JRE ($JAVA_HOME/jre/lib/security/java.security
) et ajoutez la ligne suivante :security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/share/jboss-as/nss_pkcsll_fips.cfg
Notez que le fichier de configuration spécifié sur cette ligne est le fichier créé à l'étape 2.Toute autre lignesecurity.provider.X
de ce fichier devra posséder la valeur X +1 pour que la priorité soit donnée à ce fournisseur.Activez le mode FIPS pour la bibliothèque NSS
Exécutez la commandemodutil
comme indiqué pour activer le mode FIPS :modutil -fips true -dbdir /usr/share/jboss-as/nssdb
Notez que le répertoire indiqué ici est le répertoire créé à l'étape 1.Vous aurez sans doute une erreur de bibliothèque à ce niveau, ce qui vous oblige à régénérer les signatures de bibliothèques sur certains des objets NSS partagés.Modifiez le mot de passe du token FIPS
Définissez le mot de passe du token FIPS par la commande suivante. Notez que le nom du token doit correspondre àNSS FIPS 140-2 Certificate DB
.modutil -changepw "
NSS FIPS 140-2 Certificate DB
" -dbdir /usr/share/jboss-as/nssdbLe mot de passe utilisé pour le token FIPS doit être un mot de passe conforme FIPS.Créez le certificat grâce aux outils NSS
Saisissez la commande suivante pour créer un certificat par les outils NSS.certutil -S -k rsa -n jbossweb -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdb
Configurez le connecteur HTTPS pour utiliser le keystore PKCS11
Ajoutez un connecteur HTTPS par la commande suivante dans JBoss CLI :/subsystem=web/connector=https/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
Puis, ajoutez la configuration SSL par la commande suivante, en remplaçant PASSWORD par le mot de passe conforme FIPS de l'étape 5./subsystem=web/connector=https/ssl=configuration:add(name=https,password=PASSWORD,keystore-type=PKCS11, cipher-suite="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA")
Vérifier
Vérifiez que la JVM puisse lire la clé privée du keystore PKCS11 en exécutant la commande suivante :keytool -list -storetype pkcs11
Exemple 4.8. Configuration XML du connecteur HTTPS avec conformité FIPS 140-2
<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true"> <ssl name="https" password="****" cipher-suite="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA" keystore-type="PKCS11"/> </connector>
cipher-suite
a des sauts de ligne insérés pour faciliter la lecture.
Chapitre 5. Sécuriser les interfaces de gestion
5.1. Configuration de la sécurité utilisateur par défaut
Toutes les interfaces de gestion de JBoss EAP 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 permettait 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 possible, les autres mécanismes de sécurité sont alors 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 ait bien un 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 l'instance 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 de JBoss EAP 6 Installation Guide. Pour chaque utilisateur, le nom d'utilisateur, un mot de passe haché sont stockés dans un fichier.- Domaine géré
EAP_HOME/domain/configuration/mgmt-users.properties
- Serveur autonome
EAP_HOME/standalone/configuration/mgmt-users.properties
Même si les contenus demgmt-users.properties
sont 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.
5.2. Aperçu général de la configuration de l'interface de gestion avancée
EAP_HOME/domain/configuration/host.xml
ou EAP_HOME/standalone/configuration/standalone.xml
contrôle l'interface réseau à laquelle se relie 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.
<management>
avec les quatre éléments enfant configurables suivants. Les domaines de sécurité et les connexions sortantes sont définies chacune pour commencer, puis appliquées aux interfaces de gestion en tant qu'attributs.
- <security-realms>
- <outbound-connections>
- <management-interfaces>
- <audit-log>
Note
Le domaine de sécurité est chargé de l'authentification et de permettre aux utilisateurs autorisés d'administrer JBoss EAP 6 via l'API de gestion, l'interface CLI ou la Console de gestion basée-web.
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
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.
Une interface de gestion comprend des propriétés sur la façon de connecter et configurer JBoss EAP. 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-interface
est la configuration de la console de gestion basée-web.native-interface
est la configuration pour la Management CLI en ligne de commande et l'API de gestion Rest-like.
5.3. Désactiver l'interface de gestion HTTP
Note
console-enabled
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)
Exemple 5.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"
}
}
Exemple 5.2. Supprimer l'interface HTTP
/host=master/core-service=management/management-interface=http-interface/:remove
Exemple 5.3. Recréer l'Interface HTTP
/host=master/core-service=management/management-interface=http-interface:add(console-enabled=true,interface=management,port="${jboss.management.http.port:9990}",security-realm=ManagementRealm)
5.4. Supprimer l'authentification silencieuse du domaine de sécurité par défaut.
L'installation par défaut de JBoss EAP 6 contient une méthode d'authentification silencieuse pour un utilisateur de Management CLI local. Cela donne à l'utilisateur local la possibilité d'accéder au Management CLI sans authentification par nom d'utilisateur ou 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 fonctionnalité utile étant donné que l'accès à la configuration locale donne généralement aussi à l'utilisateur la possibilité d'ajouter ses propres informations d'utilisateur ou sinon la possibilité de désactiver les contrôles de sécurité.
local
dans la section security-realm
du fichier de configuration. S'applique à la fois à standalone.xml
pour une instance de serveur autonome, ou à host.xml
pour un domaine géré. Vous ne devez envisager de supprimer l'élément local
que si vous comprenez l'impact que ceci peut avoir sur la configuration de votre serveur particulier.
local
visible dans l'exemple suivant.
Exemple 5.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>
Conditions préalables9
- Démarrer l'instance de JBoss EAP 6
- Lancer l'interface CLI.
Procédure 5.1. Supprimer l'authentification silencieuse du domaine de sécurité par défaut.
Supprimer l'authentification silencieuse par l'interface CLI
Supprimer l'élémentlocal
du Domaine de gestion et du Domaine d'applications comme requis.- Supprimer l'élément
local
du 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
local
du 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
L'authentification silencieuse est retirée du ManagementRealm
et de l'ApplicationRealm
.
5.5. Désactiver l'accès à distance du sous-système JMX
/profil=default
. Pour un serveur autonome, retirez complètement cette partie de la commande.
Note
Exemple 5.5. Supprimez le connecteur distant du sous-système JMX
/profile=default/subsystem=jmx/remoting-connector=jmx/:remove
Exemple 5.6. Supprimez le Sous-système JMX
/profile=default/subsystem=jmx/:remove
5.6. Configurer les domaines de sécurité des interfaces de gestion
Les interfaces de gestion sont configurées pour pouvoir utiliser le domaine de sécurité ManagementRealm
par défaut. Le ManagementRealm stocke ses combinaisons d'utilisateurs et de mots de passe dans le fichier mgmt-users.properties
.
Exemple 5.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"
}}
}
}
Les commandes suivantes créent un nouveau domaine de sécurité nommé TestRealm
et définissent le répertoire du fichier de propriétés qui conviennent.
Exemple 5.8. Créer un nouveau 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)
Pour utiliser un domaine de sécurité pour s'authentifier à des interfaces de gestion :
security-realm
de l'interface de gestion :
Exemple 5.9. Spécifier un domaine de sécurité à utiliser pour l'interface de gestion HTTP
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
5.7. Configurer la console de gestion pour HTTPS
standalone
ou en domain
. En mode domain
, donnez le préfixe de nom d'hôte aux commandes CLI, par exemple /host=master
.
Procédure 5.2.
Créez un keystore pour sécuriser la console de gestion.
Note
Ce keystore doit être en format JKS car la console de gestion n'est pas compatible avec les keystores en format JCEKS.Dans un émulateur de terminal, saisissez la commande suivante. Pour les paramètresalias
,keypass
,keystore
,storepass
etdname
, remplacez les valeurs en exemple par les valeurs de votre choix.Le paramètrevalidity
indique le nombre de jours pendant la clé est valide. Une valeur de 730 correspondra à deux ans.keytool -genkeypair -alias appserver -storetype jks -keyalg RSA -keysize 2048 -keypass password1 -keystore
EAP_HOME/standalone/configuration/identity.jks
-storepass password1 -dname "CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US" -validity 730 -vVeillez à ce que la console de gestion soit bien reliée à HTTPS
Mode autonome
Veillez à ce que la Console de gestion soit reliée àHTTPS
pour son interface en ajoutant la configurationmanagement-https
et en supprimant la configurationmanagement-http
.Assurez vous bien que l'instance JBoss EAP est en cours d'exécution, et saisir les commandes CLI de gestion suivantes :/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
/core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)
La sortie de cette commande sera comme suit :{"outcome" => "success"}
Note
À cet point dans le temps, le journal de JBoss EAP affichera sans doute le message d'erreur suivant. C'est normal car la configuration SSL n'est pas encore terminée.JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.
Mode Domaine
Modifiez l'élément de socket de la section management-interface en ajoutant secure-port et en supprimant la configuration de port.Assurez vous bien que l'instance JBoss EAP est en cours d'exécution, et saisir les commandes CLI de gestion suivantes :/host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9443)
/host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)
Note
À cet point dans le temps, le journal de JBoss EAP affichera sans doute le message d'erreur suivant. C'est normal car la configuration SSL n'est pas encore terminée.JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.
Option : personnalisation du groupe de socket-binding
Si vous utilisez un groupesocket-binding
personnalisé, veillez à ce que la liaisonmanagement-https
soit définie (présente par défaut, liée au port9443
). Modifiez le fichier de configuration du master - par exemplestandalone.xml
- pour qu'il puisse correspondre à ce qui suit.<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> <socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>
Créer un nouveau domaine de sécurité
Exécutez la commande suivante pour créer un nouveau domaine de sécurité nomméMyDomainRealm
./host=master/core-service=management/security-realm=ManagementRealmHTTPS/:add /host=master/core-service=management/security-realm=ManagementRealmHTTPS/authentication=properties/:add(path=ManagementUsers.properties, relative-to=jboss.domain.config.dir)
Configurez l'interface de gestion avec le nouveau domaine de sécurité.
Saisir les commandes suivantes :/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
Configurez la console de gestion pour qu'elle puisse utiliser le keystore.
Saisissez la commande CLI suivante. Pour les paramètresfile
,password
etalias
, leurs valeurs doivent être copiées à partir de l'étape Create a keystore to secure the management console (Créer un keystore pour sécuriser la console de gestion)./core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:add(keystore-path=
identity.jks
,keystore-relative-to=jboss.server.config.dir, keystore-password=password1, alias=appserver)La sortie de cette commande sera comme suit :{ "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } }
Démarrez à nouveau le serveur JBoss EAP.
Au redémarrage du serveur, le journal doit contenir ce qui suit, juste avant le texte qui indique le nombre de services démarrés. La console de gestion est maintenant en écoute sur le port 9443, ce qui confirme que la procédure a réussi.14:53:14,720 INFO [org.jboss.as] (Controller Boot Thread) JBAS015962: Http management interface listening on https://127.0.0.1:9443/management 14:53:14,721 INFO [org.jboss.as] (Controller Boot Thread) JBAS015952: Admin console listening on https://127.0.0.1:9443
Note
5.8. Utiliser des interfaces distinctes pour les connexions HTTP et HTTPS pour l'interface de gestion.
secure-interface
indique l'interface de réseau sur laquelle le socket de l'hôte doit être ouvert pour la communication de ka gestuib HTTPS, si une interface différente de celle spécifiée par l'attribut interface
doit être utilisée. Si non spécifiée, l'interface spécifiée par l'attribut interface
sera utilisée.
secure-interface
n'a aucun effet si l'attribut secure-port
n'est pas défini.
EAP_HOME/domain/configuration/host.xml
qui définit l'attribut secure-interface
pour qu'il écoute le traffic HTTPS sur une interface différente du traffic HTTP :
<?xml version='1.0' encoding='UTF-8'?> <host name="master" xmlns="urn:jboss:domain:3.0"> <management> <security-realms> <security-realm name="ManagementRealm"> <authentication> <local default-user="$local" /> <properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> </security-realm> </security-realms> <management-interfaces> <native-interface security-realm="ManagementRealm"> <socket interface="management" port="${jboss.management.native.port:9999}"/> </native-interface> <http-interface security-realm="ManagementRealm"> <socket interface="management" port="${jboss.management.http.port:9990}" secure-port="${jboss.management.https.port:9943}" secure-interface="secure-management"/> </http-interface> </management-interfaces> </management> <domain-controller> <local/> <!-- Alternative remote domain controller configuration with a host and port --> <!-- <remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> --> </domain-controller> <interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="secure-management"> <inet-address value="${jboss.bind.address:10.10.64.1}"/> </interface> </interfaces> </host>
5.9. Authentification SSL 2-way dans l'Interface de gestion et dans le CLI
- HOST1
- Le nom d'hôte du serveur JBoss. Par exemple ;
jboss.redhat.com
- HOST2
- Un nom qui convient au client. Par exemple :
myclient
. Notez qu'il ne s'agit par forcément d'un nom d'hôte. - CA_HOST1
- Le DN (distinguished name) utilisé pour le certificat HOST1. Par exemple
cn=jboss,dc=redhat,dc=com
. - CA_HOST2
- Le DN (distinguished name) utilisé pour le certificat HOST2. Par exemple
cn=myclient,dc=redhat,dc=com
.
Pré-requis
- Si vous souhaitez utiliser l'archivage de mots de passe pour stocker les mots de passe de keystore et de truststore (recommandé), l'archivage de mots de passe doit déjà avoir été créé. Voir Section 7.1, « Système d'archivage sécurisé de mots de passe ».
Procédure 5.3.
- Générez les stores :
keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret
keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret
- Exportez les certificats :
keytool -exportcert -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer
keytool -exportcert -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer
- Importe des certificats dans les trust stores opposés :
keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer
keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer
- Définir un CertificateRealm dans la configuration de votre installation (
host.xml
oustandalone.xml
) et y pointez l'interface :Cela peut se faire en modifiant le fichier de configuration manuellement (non recommandé) ou en utilisant les commandes suivantes :/core-service=management/security-realm=CertificateRealm:add()
/core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks,keystore-password=secret, alias=HOST1_alias)
/core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)
Important
Les commandes données ne s'appliquent qu'en mode autonome. Pour le mode domaine, ajoutez/host=master
avant chaque commande. - Modifiez le
security-realm
de l'interface native du domaine de sécurité./host=master/core-service=management/management-interface=native-interface:write-attribute(name=security-realm,value=CertificateRealm)
- Ajoutez la configuration SSL au CLI, utilisant le fichier
EAP_HOME/bin/jboss-cli.xml
pour les configurations. Utilisez soit un archivage de mots de passe pour stocker les mots de passe de keystore ou de truststore (recommandé), ou les stocker en texte brut :- Pour stocker les mots de passe de keystore et de truststore dans un archivage de mots de passe :Modifiez
EAP_HOME/bin/jboss-cli.xml
et ajoutez la configuration SSL (en utilisant les valeurs appropriées pour les variables). Ajoutez également la configuration de l'archivage, en remplaçant chaque valeur par celle de votre archivage.<ssl> <vault> <vault-option name="KEYSTORE_URL" value="path-to/vault/vault.keystore"/> <vault-option name="KEYSTORE_PASSWORD" value="MASK-5WNXs8oEbrs"/> <vault-option name="KEYSTORE_ALIAS" value="vault"/> <vault-option name="SALT" value="12345678"/> <vault-option name="ITERATION_COUNT" value="50"/> <vault-option name="ENC_FILE_DIR" value="path-to/jboss-eap/vault/"/> </vault> <alias>$HOST2alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>VAULT::VB::cli_pass::1</key-store-password> <key-password>VAULT::VB::cli_pass::1</key-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>VAULT::VB::cli_pass::1</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl>
- Pour stocker les mots de passe de keystore et de truststore en texte brut :Modifiez
EAP_HOME/bin/jboss-cli.xml
et ajoutez la configuration SSL (en utilisant les valeurs appropriées pour les variables) :<ssl> <alias>$HOST2alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>secret</key-store-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>secret</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl>
5.10. Sécuriser les interfaces de gestion via JAAS
/subsystem=security/security-domain=UsersLMDomain:add(cache-type=default) /subsystem=security/security-domain=UsersLMDomain/authentication=classic:add /subsystem=security/security-domain=UsersLMDomain/authentication=classic/login-module=UsersRoles:add()
/core-service=management/security-realm=SecurityDomainAuthnRealm:add /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)
assign-groups
détermine si les informations chargées d'appartenance à un groupe de l'utilisateur en provenance du domaine de sécurité sont utilisées pour l'allocation à un groupe dans le domaine de sécurité. Si défini sur true
, cette allocation de groupe sera utilisée pour le RBAC (Role-Based Access Control).
assign-groups
peut être défini à true par la commande CLI :
/core-service=management/security-realm=ManagementRealm/authentication=jaas:write-attribute(name=assign-groups,value=true)
5.11. LDAP
5.11.1. LDAP
5.11.2. Utiliser LDAP pour vous authentifier auprès des interfaces de gestion
- 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.
La connexion sortante LDAP autorise les attributs suivants :
Tableau 5.1. Attributs d'une connexion sortante LDAP
Attribut | Requis | Description |
---|---|---|
url | oui |
L'adresse URL du serveur de répertoire.
|
search-dn | non |
Le nom distinctif (DN) de l'utilisateur autorisé à effectuer des recherches.
|
search-credentials | non |
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 .
|
security-realm | non |
Domaine de sécurité à référencer pour obtenir un
SSLContext configuré pour établir la connexion.
|
Exemple 5.10. Ajouter une connexion sortante LDAP
- Search DN:
cn=search,dc=acme,dc=com
- Search Credential:
myPass
- URL:
ldap://127.0.0.1:389
/host=master/core-service=management/security-realm=ldap_security_realm:add
/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")
Les interfaces de gestion peuvent s'authentifier sur le serveur LDAP au lieu des domaines de sécurité basés fichiers de propriété et configurés par défaut. L'authentificateur LDAP fonctionne en établissant tout d'abord une connexion vers le 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 distinctif complet (DN) du dossier LDAP. Une nouvelle connexion est alors établie, utilisant le DN de l'utilisateur comme information 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.
- connection
- Le nom de la connexion défini dans
outbound-connections
à utiliser pour se connecter au répertoire LDAP. - advanced-filter
- Le filtre complet utilisé pour rechercher un utilisateur basé sur l'ID d'utilisateur fourni. Le filtre doit contenir une variable suivant le format suivant :
{0}
. Sera plus tard remplacé par le nom d'utilisateur fourni par l'utilisateur. - base-dn
- Le nom distinctif (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 contient le nom distinctif (DN). Utilisé par la suite pour tester l'authentification. Valeur par défaut
dn
. - username-attribute
- Le nom de l'attribut à rechercher pour l'utilisateur. Ce filtre effectue une recherche simple où le nom d'utilisateur entré par l'utilisateur correspond à l'attribut spécifié.
- allow-empty-passwords
- Cet attribut détermine si un mot de passe vide est accepté. La valeur par défaut pour cet attribut est
false
. - Soit
username-filter
ouadvanced-filter
, devra être spécifié. - L'attribut
advanced-filter
contient une recherche par filtre dans la syntaxe standard LDP, par exemple :(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))
Exemple 5.11. XML représentant un domaine de sécurité activé-LDAP
- connection -
ldap_connection
- base-dn -
cn=users,dc=acme,dc=com
. - username-filter -
attribute="sambaAccountName"
<security-realm name="ldap_security_realm"> <authentication> <ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com"> <username-filter attribute="sambaAccountName" /> </ldap> </authentication> </security-realm>
Avertissement
Exemple 5.12. Ajout d'un domaine de sécurité LDAP
/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")
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 5.13. Ajouter le domaine de sécurité à l'interface HTTP
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
Exemple 5.14. Ajouter le domaine de sécurité à l'interface native
/host=master/core-service=management/management-interface=native-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
5.11.3. Utiliser la sortie LDAP avec SSL 2-ways dans l'interface de gestion et le CLI
- On doit créer un domaine de sécurité activé-LDAP. Voir Section 5.11.2, « Utiliser LDAP pour vous authentifier auprès des interfaces de gestion » pour obtenir des informations supplémentaires sur la façon de créer le domaine de sécurité.
Procédure 5.4. Configurer la sortie LDAP avec un SSL 2-way
- Configurer lekeystore et le truststore du domaine de sécurité. Le domaine de sécurité doit contenir un keystore configuré avec la clé que le serveur JBoss EAP 6 utilise pour s'authentifier auprès du serveur LDAP. Le domaine de sécurité doit également contenir un truststore configuré avec les certificats du serveur LDAP. Voir Section 5.9, « Authentification SSL 2-way dans l'Interface de gestion et dans le CLI » pour obtenir des instructions sur la façon de configurer les keystores et les truststores.
- Ajouter une connexion sortante dans le serveur LDAP, spécifiant le domaine de sécurité configuré :
/core-service=management/ldap-connection=LocalLdap:add(url="ldaps://LDAP_HOST:LDAP_PORT") /core-service=management/ldap-connection=LocalLdap:write-attribute(name=security-realm,value="LdapSSLRealm")
- Configurer l'authentification LDAP dans le domaine de sécurité et les interfaces de gestion comme indiqué dans Section 5.11.2, « Utiliser LDAP pour vous authentifier auprès des interfaces de gestion ».
Chapitre 6. Activer les interfaces de gestion par le contrôle d'accès basé rôle
6.1. Les RBAC (Role-Based Access Control)
6.2. Les RBAC (Role-Based Access Control) dans la console de gestion et le CLI
- La console de gestion
- Dans la console de gestion, certains contrôles et vues sont désactivés (en gris) ou invisibles selon les permissions du rôle assignées à l'utilisateur.Si vous n'avez pas de permission de lecture pour un attribut de ressource, cet attribut apparaîtra en blanc sur la console. Ainsi, la plupart des rôles ne peuvent pas lire les champs Nom d'utilisateur ou Mot de passe des sources de données.Si vous n'avez pas de permission d'écriture sur un attribut de ressource, cet attribut sera désactivé (grisé) dans le formulaire de modification de la ressource. Si vous n'avez pas de permission d'écriture sur la ressource, le bouton de modification de la ressource ne s'affichera pas.Si un utiliisateur ne possède pas les permissions nécessaires pour accéder à une ressource ou à un attribut (c'est « non adressable » ce pour rôle), ce n'apparaîtra pas dans la console. L'accès contrôle système lui-même uniquement visible par quelques rôles par défaut en est un exemple.
- l'interface CLI ou l'API
- Les utilisateurs de l'outil
jboss-cli.sh
ou de l'API rencontreront un comportement légèrement différent dans l'API lorsque RBAC est activé.Les ressources et les attributs qui ne peuvent être lus sont filtrés des résultats. Si les éléments filtrés sont adressables par le rôle, leurs noms seront répertoriés en tant quefiltered-attributes
dans la sectionresponse-headers
du résultat. Si une ressource ou un attribut n'est pas adressable par le rôle, il n'apparaîtra pas.Toute tentative d'accès à une ressource non adressable résultera par l'erreurresource not found
.Si un utilisateur tente d'écrire ou de lire une ressource qu'il peut adresser, mais qu'il n'a pas les permissions de lecture ou d'écriture qui conviennent, une erreurPermission Denied
apparaîtra.
6.3. Schémas d'authentification supportés
username/password
, client certificate
, et local user
.
- Username/Password
- Les utilisateurs sont authentifiés par une combinaison de nom d'utilisation et de mot de passe qui sont ensuite vérifiés par le fichier
mgmt-users.properties
, ou via un serveur LDAP. - Client Certificate
- Utilisation du Trust Store
- Local User
jboss-cli.sh
authentifie automatiquement en tant qu'utilisateur local si le serveur exécute sur la même machine. Par défaut, l'utilisateur local est un membre du groupeSuperUser
.
mgmt-users.properties
ou par un serveur LDAP, ces systèmes peuvent fournir des informations de groupes d'utilisateur. Cette information peut également servir à JBoss EAP pour attribuer des rôles aux utilisateurs.
6.4. Les rôles standard
- Monitor
- Les utilisateurs du rôle Monitor ont le plus petit nombre de permissions et ne peuvent lire que la configuration ou l'état du serveur en cours. Ce rôle est destiné aux utilisateurs qui ont besoin de vérifier et reporter la performance du serveur.Les Monitors ne peuvent pas modifier la configuration du serveur, et ne peuvent pas accéder aux données ou opérations confidentielles.
- Operator
- Le rôle Operator étend le rôle Monitor en ajoutant la possibilité de modifier l'état d'exécution du serveur. Cela signifie que les opérateurs peuvent recharger et arrêter le serveur, ainsi que suspendre et reprendre les destinations JMS. Le rôle Operator est idéal pour les utilisateurs responsables des hôtes physiques ou virtuels du serveur d'applications, puisqu'ils peuvent s'assurer ainsi que les serveurs puissent être arrêtés, redémarrés ou corrigés si nécessaire.Le opérateurs ne peuvent pas modifier la configuration du serveur ou accéder à des données ou opérations confidentielles.
- Maintainer
- Le rôle Maintainer a le droit de visualiser et modifier l'état d'exécution et toute la configuration à l'exception des données sensibles et des opérations. Le rôle du mainteneur est un rôle d'usage général qui n'a pas accès aux données sensibles et aux opérations. Le rôle Maintainer permet aux utilisateurs de bénéficier d'un accès presque total d'administration du serveur, sans donner à ces utilisateurs l'accès aux mots de passe ou autres informations sensibles.Le mainteneurs ne peuvent pas accéder à des données ou opérations sensibles.
- Administrator
- Le rôle Administrator a un accès illimité aux ressources et opérations sur le serveur sauf sur le système d'enregistrement d'audit. Le rôle d'administrateur a accès à des données sensibles et aux opérations. Ce rôle peut également configurer le système de contrôle d'accès. Le rôle Administrator n'est requis que lorsque vous manipulez des données sensibles ou configurez les utilisateurs et les rôles.Les administrateurs ne peuvent pas accéder au système de journalisation d'auditing et ne peuvent pas se changer eux-mêmes en rôles Auditor ou SuperUser.
- SuperUser
- Le rôle SuperUser a un accès illimité aux ressources et opérations sur le serveur, y compris au système d'enregistrement d'audit. Ce rôle est équivalent aux rôles d'utilisateurs administrateurs des versions plus anciennes de JBoss EAP 6 (6.0 et 6.1). Si RBAC est désactivé, tous les utilisateurs de management auront une permission équivalente à celle d'un rôle SuperUser.
- Deployer
- Le rôle Deployer a les mêmes permissions que Monitor, mais peut modifier la configuration et l'état des déploiements ou n'importe quel autre type de ressource activée en tant que ressource d'application.
- Auditor
- Le rôle Auditor possède toutes les permissions du rôle Monitor et peut également voir (mais pas modifier) les données sensibles. Il a aussi accès au système de journalisation de l'auditing. Le rôle Auditor est le seul rôle en dehors de SuperUser qui puisse accéder au système de journalisation de l'auditing.Les auditeurs ne peuvent pas modifier les données ou les ressources sensibles. Seul l'accès lecture est permis.
6.5. Les permissions de rôle
Tableau 6.1. Matrice de permissions de rôle
Monitor
|
Operator
|
Maintainer
|
Deployer
|
Auditor
|
Admin
|
SuperUser
| |
Lecture Config et État
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Lire Données sensibles [2]
|
X
|
X
|
X
| ||||
Modifier Données sensibles [2]
|
X
|
X
| |||||
Lire/Modifer Audit Log
|
X
|
X
| |||||
Modifier État Runtime
|
X
|
X
|
X[1]
|
X
|
X
| ||
Modifier Config persistante
|
X
|
X[1]
|
X
|
X
| |||
Lire/Modifier Contrôle d'accès
|
X
|
X
|
6.6. Contraintes
- Contraintes d'application
- Les contraintes d'application définissent des ensembles de ressources et d'attributs accessibles aux utilisateurs du rôle chargé du déploiement (rôle Deployer). Par défaut, la seule Contrainte d'application activée est la principale qui inclut des déploiements, et des superpositions de déploiement. Les contraintes d'application sont également incluses (mais pas activées par défaut) pour les sources de données, connexion, mail, messagerie, nommage, adaptateurs de ressources et sécurité. Ces contraintes permettent aux utilisateurs Deployer de non seulement de déployer des applications, mais également de configurer et de maintenir les ressources requises par ces applications.La configuration de contraintes d'applications se trouve dans l'API de gestion à l'adresse suivante :
/core-service=management/access=authorization/constraint=application-classification
. - Contraintes de sensibilité
- Les contraintes de confidentialité définissent des ressources considérées comme « sensibles ». Une ressource sensible est généralement de nature secrète, comme un mot de passe, ou une information pouvant avoir de graves répercussions sur le fonctionnement du serveur, comme le networking, la configuration de la JVM ou les propriétés système. Le système de contrôle d'accès lui-même est aussi considéré comme sensible.Les seuls rôles autorisés à écrire dans les ressources sensibles sont Administrateur et Superutilisateur. Le rôle Auditor est seulement capable de lire les ressources confidentielles. Aucun autre rôle ne peut avoir accès.La configuration de contraintes de sensibilité se trouve dans l'API de gestion à l'adresse suivante :
/core-service=management/access=authorization/constraint=sensitivity-classification
. - Contrainte d'expression d'archivage sécurisé
- Une contrainte d'expression d'archivage sécurisé détermine si la lecture ou l'écriture d'expressions d'archivage sécurisé est considéré comme une opération sensible. Par défaut, les deux sont sensibles.La configuration de contraintes d'expression d'archivage sécurisé se trouve dans l'API de gestion à l'adresse suivante :
/core-service=management/access=authorization/constraint=vault-expression
.
6.7. JMX et RBAC (Role-Based Access Control)
- L'API de gestion de JBoss EAP 6 est exposé comme JMX Management Beans. Ces Management Beans sont appelés « core mbeans » et leur accès est contrôlé et filtré exactement de la même façon que l'API de gestion sous-jacent lui-même.
- Le sous-système JMX est configuré avec des permissions d'écriture « sensibles ». Cela signifie que seuls les utilisateurs ayant pour rôle Administrateur et Superutilisateur peuvent apporter des modifications à ce sous-système. Les utilisateurs avec le rôle Auditeur peuvent aussi lire cette configuration du sous-système.
- Par défaut, les beans de gestion enregistrés par des applications déployées et des services (non-core mbeans) sont accessibles par tous les utilisateurs de gestion, mais seuls les utilisateurs ayant un rôle Maintenance, Opérateur, Administrateur, Superutilisateur peuvent écrire dessus.
6.8. Configurer le RBAC (Role-Based Access Control)
6.8.1. Aperçu des tâches de configuration RBAC
- Voir et configurer les rôles assignés (ou exclus) pour chaque utilisateur
- Voir et configurer les rôles assignés (ou exclus) pour chaque groupe
- Voir Appartenance Utilisateur et Groupe par Rôle.
- Configurer l'appartenance par défaut d'un rôle.
- Créer un scoped rôle
- Activer et désactiver RBAC
- Modifier la police de combinaison de permissions
- Configurer les contraintes de sensibilité des ressources et des ressources d'applications
6.8.2. Activer le RBAC (Role-Based Access Control)
simple
à rbac
. Cela peut être fait en utilisant l'outil jboss-cli.sh
, ou en modifiant la configuration du serveur XML du fichier si le serveur est hors ligne. Quand RBAC est désactivé ou activé sur un serveur en cours d'exécution, la configuration du serveur doit être rechargée avant de prendre effet.
jboss-cli.sh
est exécuté par le rôle SuperUser
s'il est exécuté dans la même machine que le serveur.
Procédure 6.1. Activer RBAC
- Pour activer RBAC avec
jboss-cli.sh
utiliser l'opérationwrite-attribute
de la ressource d'autorisation d'accès, pour définir la valeur de l'attribut provider àrbac
/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
[standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=rbac) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9999 /] /:reload { "outcome" => "success", "result" => undefined }
Procédure 6.2. Désactiver RBAC
- Pour désactiver RBAC avec
jboss-cli.sh
utiliser l'opérationwrite-attribute
de la ressource d'autorisation d'accès pour définir la valeur de l'attribut provider àsimple
/core-service=management/access=authorization:write-attribute(name=provider, value=simple)
[standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=simple) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9999 /] /:reload { "outcome" => "success", "result" => undefined }
provider
de l'élément de contrôle d'accès de l'élément access-control
. Définissez la valeur rbac
sur « activé » et simple
sur « désactivé ».
<management> <access-control provider="rbac"> <role-mapping> <role name="SuperUser"> <include> <user name="$local"/> </include> </role> </role-mapping> </access-control> </management>
6.8.3. Modifier la police de combinaison de permissions
permissive
ou rejecting
. La valeur par défaut est permissive
.
permissive
, si un rôle est assigné à l'utilisateur pour permettre une action, alors l'action sera autorisée.
rejecting
, si plusieurs rôles sont assignés à un utilissateur, alors aucune action ne sera requise. Lorsque la police est définie à rejecting
, chaque utilisateur se verra assigner un rôle unique. Les utilisateurs ayant des rôles multiples ne seront pas en mesure d'utiliser l'outil de gestion de console ou jboss-cli.sh
lorsque la police est définie sur rejecting
.
permission-combination-policy
soit permissive
ou rejecting
. Cela peut être fait par l'outil jboss-cli.sh
, ou en modifiant la configuration du serveur XML du fichier si le serveur est hors ligne.
Procédure 6.3. Définir la police de combinaison de permissions
- Effectuer l'opération
write-attribute
de la ressource d'autorisation d'accès pour définir l'attributpermission-combination-policy
au nom de la police requise./core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)
Les noms de police valide sont « rejecting » ou « permissive ».[standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
permission-combination-policy
de l'élément de contrôle d'accès.
<access-control provider="rbac" permission-combination-policy="rejecting"> <role-mapping> <role name="SuperUser"> <include> <user name="$local"/> </include> </role> </role-mapping> </access-control>
6.9. Gestion des rôles
6.9.1. Appartenance à un rôle
- L'utilisateur est :
- listé comme utilisateur à inclure dans le rôle, ou
- un membre d'un groupe qui est listé pour être inclus dans le rôle.
- L'utilisateur n'est pas :
- listé comme utilisateur à exclure du rôle, ou
- un membre d'un groupe qui est listé pour être exclus du rôle.
6.9.2. Configurer le rôle d'utilisateur 'Assignment' (attribution de rôles)
jboss-cli.sh
. Cette section explique uniquement comment utiliser la console de gestion à cet effet.
SuperUser
ou Administrator
peuvent effectuer cette configuration.
- Connectez-vous à la console de gestion.
- Cliquez sur l'onglet Administration.
- Déployez le menu Access Control et sélectionner Role Assignment.
- Sélectionnez l'onglet USERS.
Procédure 6.4. Créez une nouvelle attribution de rôle pour l'utilisateur
- Connexion à la console de gestion.
- Naviguez vers l'onglet Users (Utilisateurs) de la section Role Assignment (Attribution de rôles).
- Cliquez sur le bouton Add en haut et à droite de la liste d'utilisateur. Le dialogue Ajouter Utilisateur (Add User) apparaîtra.
Figure 6.1. Boîte de dialogue 'Add User' (Ajouter Utilisateur)
- Vous devez préciser un nom d'utilisateur, ou un domaine si possible.
- Définissez le type de menu à inclure ou à exclure.
- Cliquez la case des rôles à inclure ou à exclure. Vous pouvez utiliser la clé de contrôle (clé de commande OSX) pour cocher les divers items.
- Cliquez sur le bouton Save pour terminer.Si cela réussit, la boîte de dialogue 'Ajouter un utilisateur' (Add User) se ferme, et la liste des utilisateurs sera mise à jour pour refléter les modifications apportées. En cas d'échec, un message
Impossible d'enregistrer l'attribution de rôle
s'affichera.
Procédure 6.5. Mise à jour d'une attribution de rôle pour un utilisateur
- Connexion à la console de gestion.
- Naviguez vers l'onglet Users (Utilisateurs) de la section Role Assignment (Attribution de rôles).
- Sélectionnez un utilisateur dans la liste.
- Cliquez sur le bouton Edit. Le panneau de sélection est alors en mode Édit.
Figure 6.2. Sélectionnez Vue Édit
Vous pourrez ici ajouter ou supprimer les rôles assignés pour exclus pour l'utilisateur.- Pour ajouter un rôle assigné, sélectionnez le rôle requis de la liste de rôles disponibles sur la gauche et cliquez sur le bouton avec une flèche pointant sur la droite qui se trouve à côté de la liste de rôles assignés. Le rôle se déplacera alors depuis la liste de rôles disponibles vers la liste de rôles assignés.
- Pour supprimer un rôle assigné, sélectionnez le rôle requis de la liste de rôles assignés sur la droite et cliquez sur le bouton avec une flèche pointant sur la gauche qui se trouve à côté de la liste de rôles assignés. Le rôle se déplacera alors depuis la liste de rôles assignés vers la liste de rôles disponibles.
- Pour ajouter un rôle exclus, sélectionnez le rôle requis de la liste de rôles disponibles sur la gauche et cliquez sur le bouton avec une flèche pointant sur la droite qui se trouve à côté de la liste de rôles exclus. Le rôle se déplacera alors depuis la liste de rôles disponibles vers la liste de rôles exclus.
- Pour supprimer un rôle exclus, sélectionnez le rôle requis de la liste de rôles assignés sur la droite et cliquer sur le bouton avec une flèche pointant sur la gauche qui se trouve à côté de la liste de rôles exclus. Le rôle se déplacera alors depuis la liste de rôles exclus vers la liste de rôles disponibles.
- Cliquez sur le bouton Save pour terminer.Si cela réussit, la vue Édit se ferme, et la liste des utilisateurs sera mise à jour pour refléter les modifications apportées. En cas d'échec, un message
Impossible d'enregistrer l'attribution de rôle
s'affichera.
Procédure 6.6. Suppression d'une attribution de rôle pour un utilisateur
- Connexion à la console de gestion.
- Naviguez vers l'onglet Users de la section Attribution de rôles.
- Sélectionnez l'utilisateur dans la liste.
- Cliquez sur le bouton Remove. L'invite de confirmation Remove Role Assignment apparaîtra.
- Cliquez sur Confirm.Si cela réussit, l'utilisateur n'apparaîtra plus sur la liste d'attributions de rôle d'utilisateur.
Important
6.9.3. Configurer l'attribution de rôle utilisateur avec jboss-cli.sh
jboss-cli.sh
. Cette section explique uniquement comment utiliser jboss-cli.sh
.
/core-service=management/access=authorization
en tant qu'éléments role-mapping
.
Procédure 6.7. Affichage de la Configuration Attribution de rôles
- Utiliser l'opération :read-children-names pour obtenir une liste complète des rôles configurés :
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
[standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping) { "outcome" => "success", "result" => [ "ADMINISTRATOR", "DEPLOYER", "MAINTAINER", "MONITOR", "OPERATOR", "SuperUser" ] }
- Utiliser l'opération
read-resource
d'un mappage de rôle (role-mapping) pour obtenir toutes les informations sur un rôle particulier :/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
[standalone@localhost:9999 access=authorization] ./role-mapping=ADMINISTRATOR:read-resource(recursive=true) { "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => { "user-theboss" => { "name" => "theboss", "realm" => undefined, "type" => "USER" }, "user-harold" => { "name" => "harold", "realm" => undefined, "type" => "USER" }, "group-SysOps" => { "name" => "SysOps", "realm" => undefined, "type" => "GROUP" } } } } [standalone@localhost:9999 access=authorization]
Procédure 6.8. Ajouter un nouveau rôle
- Utiliser l'opération
add
pour ajouter une nouvelle configuration de rôle./core-service=management/access=authorization/role-mapping=ROLENAME:add
ROLENAME est le nom du rôle du nouveau mappage.[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR:add {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Procédure 6.9. Ajouter un Utilisateur comme inclus dans un rôle
- Utiliser l'opération
add
pour ajouter une entrée d'utilisateur dans la liste d'inclusions du rôle./core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
ROLENAME est le nom du rôle en cours de configuration.ALIAS
est un nom unique pour ce mappage. Red Hat conseille d'utiliser une convention de mappage pour tous les alias commeuser-USERNAME
.USERNAME est le nom de l'utilisateur entrain d'être ajouté à la liste des inclusions.[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=user-max:add(name=max, type=USER) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Procédure 6.10. Ajouter un Utilisateur comme exclus dans un rôle
- Utiliser l'opération
add
pour ajouter une entrée d'utilisateur dans la liste d'exclusions du rôle./core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
ROLENAME est le nom du rôle en cours de configuration.USERNAME est le nom de l'utilisateur ajouté à la liste des exclusions.ALIAS
est un nom unique pour ce mappage. Red Hat conseille d'utiliser une convention de mappage pour tous les alias commeuser-USERNAME
.[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=user-max:add(name=max, type=USER) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Procédure 6.11. Configuration pour la suppression d'un rôle d'utilisateur d'inclusion
- Utiliser l'opération
remove
pour supprimer la saisie./core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
ROLENAME est le nom du rôle en cours de configurationALIAS
est un nom unique pour ce mappage. Red Hat conseille d'utiliser une convention de mappage pour tous les alias commeuser-USERNAME
.[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=user-max:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Supprimer l'utilisateur de la liste d'inclusions ne permet pas de supprimer l'utilisateur du système, ni ne garantit que le rôle ne sera pas assigné à l'utilisateur. Le rôle peut être assigné sur la base de l'appartenance à un groupe.
Procédure 6.12. Configuration de la suppression d'un rôle d'utilisateur d'exclusion
- Utiliser l'opération
remove
pour supprimer la saisie./core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
ROLENAME est le nom du rôle en cours de configuration.ALIAS
est un nom unique pour ce mappage. Red Hat conseille d'utiliser une convention de mappage pour tous les alias commeuser-USERNAME
.[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=user-max:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Supprimer l'utilisateur de la liste d'exclusions ne permet pas de supprimer l'utilisateur du système, ni ne garantit que le rôle puisse être assigné à l'utilisateur. Les rôles peuvent être assignés sur la base de l'appartenance à un groupe.
6.9.4. Groupes Utilisateurs et Rôles
mgmt-users.properties
ou d'un serveur LDAP peuvent être membres des groupes d'utilisateurs. Un groupe d'utilisateurs est une étiquette arbitraire qui peut être assignée à un ou plusieurs utilisateurs.
mgmt-users.properties
, l'information groupe est stockée dans le fichier mgmt-groups.properties
. Lorsque vous utilisez LDAP, l'information groupe est stockée dans le serveur LDAP et est maintenue par les responsables du serveur LDAP.
6.9.5. Configurer l'attribution de rôles de groupe
jboss-cli.sh
. Cette section explique uniquement comment utiliser la console de gestion.
SuperUser
ou Administrator
peuvent effectuer cette configuration.
- Connectez-vous à la console de gestion.
- Cliquez sur l'onglet Administration.
- Déployez le menu Access Control et sélectionner Role Assignment.
- Sélectionnez l'onglet GROUPS.
Procédure 6.13. Créez une nouvelle attribution de rôle pour un groupe
- Connectez-vous à la console de gestion
- Naviguez vers l'onglet GROUPS de la section Role Assignment (Attribution de rôles).
- Cliquez sur le bouton Add en haut et à droite de la liste d'utilisateur. Le dialogue Ajouter Utilisateur (Add User) apparaîtra.
Figure 6.3. Ajouter le dialogue de groupe
- Vous devez préciser un nom de groupe, et le domaine si possible.
- Définissez le type de menu à inclure ou à exclure.
- Cliquez la case des rôles à inclure ou à exclure. Vous pouvez utiliser la clé de contrôle (clé de commande OSX) pour cocher les divers items.
- Cliquez sur le bouton Save pour terminer.Si cela réussit, la boîte de dialogue Ajouter un groupe (Add Group) se fermera, et la liste des utilisateurs sera mise à jour pour refléter les modifications apportées. En cas d'échec, un message
Impossible d'enregistrer l'attribution de rôle
s'affichera.
Procédure 6.14. Mise à jour d'une attribution de rôle pour un groupe
- Connexion à la console de gestion.
- Naviguez vers l'onglet GROUPS de la section Attribution de rôles.
- Sélectionnez un groupe dans la liste.
- Cliquez sur le bouton Édit. La vue de sélection est alors en mode Édit.
Figure 6.4. Sélection Vue Mode Édition
Vous pourrez ici ajouter ou supprimer les rôles assignés ou exclus du groupe :- Pour ajouter un rôle assigné, sélectionnez le rôle que vous souhaitez de la liste de rôles disponibles sur la gauche et cliquez sur le bouton ayant une flèche pointant sur la droite qui se trouve à côté de la liste de rôles assignés. Le rôle se déplacera alors depuis la liste de rôles disponibles vers la liste de rôles assignés.
- Pour supprimer un rôle assigné, sélectionnez le rôle requis de la liste de rôles assignés sur la droite et cliquez sur le bouton ayant une flèche pointant sur la gauche qui se trouve à côté de la liste de rôles assignés. Le rôle se déplacera alors depuis la liste de rôles assignés vers la liste de rôles disponibles.
- Pour ajouter un rôle exclus, sélectionnez le rôle requis de la liste de rôles disponibles sur la gauche et cliquez sur le bouton ayant une flèche pointant sur la droite qui se trouve à côté de la liste de rôles exclus. Le rôle se déplacera alors depuis la liste de rôles disponibles vers la liste de rôles exclus.
- Pour supprimer un rôle exclus, sélectionnez le rôle requis de la liste de rôles assignés sur la droite et cliquez sur le bouton ayant une flèche pointant sur la gauche qui se trouve à côté de la liste de rôles exclus. Le rôle se déplacera alors depuis la liste de rôles exclus vers la liste de rôles disponibles.
- Cliquez sur le bouton Save pour terminer.Si cela réussit, la vue Édit se fermera, et la liste des groupes sera mise à jour pour refléter les modifications apportées. En cas d'échec, un message Failed to save role assignment (Impossible d'enregistrer l'attribution de rôle) s'affichera.
Procédure 6.15. Supprimez une attribution de rôle pour un groupe
- Connexion à la console de gestion.
- Naviguez vers l'onglet GROUPS de la section Attribution de rôles (Role Assignment).
- Sélectionnez un groupe dans la liste.
- Cliquez sur le bouton Remove. L'invite de confirmation Remove Role Assignment apparaîtra.
- Cliquez sur Confirmer.Si cela réussit, le rôle n'apparaîtra plus sur la liste d'attributions de rôle de groupe.La suppression du groupe de la liste d'attribution de rôles ne retire pas l'utilisateur du système, ni ne garantit qu'aucun rôle ne sera assigné aux membres de ce groupe. Chaque membre du groupe peut encore avoir un rôle qui lui soit directement assigné.
6.9.6. Configurer l'attribution de rôles de groupe avec jboss-cli.sh
jboss-cli.sh
. Cette section explique uniquement comment utiliser l'outil jboss-cli.sh
.
/core-service=management/access=authorization
en tant qu'éléments de mappage.
Procédure 6.16. Affichage de la Configuration d'attribution de rôles de groupe
- Utiliser l'opération
read-children-names
pour obtenir une liste complète des rôles configurés :/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
[standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping) { "outcome" => "success", "result" => [ "ADMINISTRATOR", "DEPLOYER", "MAINTAINER", "MONITOR", "OPERATOR", "SuperUser" ] }
- Utiliser l'opération
read-resource
d'un mappage de rôle (role-mapping) pour obtenir toutes les informations sur un rôle particulier :/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
[standalone@localhost:9999 access=authorization] ./role-mapping=ADMINISTRATOR:read-resource(recursive=true) { "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => { "user-theboss" => { "name" => "theboss", "realm" => undefined, "type" => "USER" }, "user-harold" => { "name" => "harold", "realm" => undefined, "type" => "USER" }, "group-SysOps" => { "name" => "SysOps", "realm" => undefined, "type" => "GROUP" } } } } [standalone@localhost:9999 access=authorization]
Procédure 6.17. Ajouter un nouveau rôle
- Utiliser l'opération
add
pour ajouter une nouvelle configuration de rôle./core-service=management/access=authorization/role-mapping=ROLENAME:add
[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR:add {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Procédure 6.18. Ajouter un Groupe comme inclus dans un rôle
- Utiliser l'opération
add
pour ajouter une entrée de Groupe dans la liste d'inclusions du rôle./core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
ROLENAME est le nom du rôle en cours de configuration.GROUPNAME est le nom du groupe entrain d'être ajouté à la liste des inclusions.ALIAS
est un nom unique pour ce mappage. Red Hat recommande d'utiliser une convention de mappage pour tous les alias commegroup-GROUPNAME
.[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=group-investigators:add(name=investigators, type=GROUP) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Procédure 6.19. Ajouter un groupe comme exclus dans un rôle
- Utiliser l'opération
add
pour ajouter une entrée de Groupe dans la liste d'exclusions du rôle./core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
ROLENAME est le nom du rôle en cours de configurationGROUPNAME est le nom du groupe entrain d'être ajouté à la liste des inclusionsALIAS
est un nom unique pour ce mappage. Red Hat recommande d'utiliser une convention de mappage pour tous les alias commegroup-GROUPNAME
.[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=group-supervisors:add(name=supervisors, type=USER) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Procédure 6.20. Configuration de la suppression d'un rôle de groupe
- Utiliser l'opération
remove
pour supprimer la saisie./core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
ROLENAME est le nom du rôle en cours de configurationALIAS
est un nom unique pour ce mappage. Red Hat recommande d'utiliser une convention de mappage pour tous les alias commegroup-GROUPNAME
.[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=group-investigators:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Supprimer le groupe de la liste d'inclusions ne permet pas de supprimer le groupe du système, ni ne garantit que le rôle ne sera pas assigné à des utilisateurs de ce groupe. Le rôle peut être assigné à des utilisateurs du groupe individuellement.
Procédure 6.21. Supprimer une entrée d'exclusion de groupe d'utilisateurs
- Utiliser l'opération
remove
pour supprimer la saisie./core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
ROLENAME est le nom du rôle en cours de configuration.ALIAS
est un nom unique pour ce mappage. Red Hat recommande d'utiliser une convention de mappage pour tous les alias commegroup-GROUPNAME
.[standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=group-supervisors:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
Supprimer le groupe de la liste d'exclusions ne permet pas de supprimer le groupe du système, ni ne garantit que le rôle ne va pas être assigné à des membres du groupe. Les rôles peuvent être exclus sur la base de l'appartenance à un groupe.
6.9.7. Autorisation et Chargement de groupes avec LDAP
memberOf
; une entité du groupe peut mapper les utilisateurs lui appartenant par les attributs uniqueMember
; ou les deux mappages peuvent être maintenus dans le serveur LDAP.
force
est défini à «false». Quand force
est défini à true, la recherche a lieu à nouveau en cours d'autorisation (pendant le chargement des groupes). Cela est normalement effectué quand des serveurs différents effectuent l'authentification et l'autorisation.
<authorization> <ldap connection="..."> <!-- OPTIONAL --> <username-to-dn force="true"> <!-- Only one of the following. --> <username-is-dn /> <username-filter base-dn="..." recursive="..." user-dn-attribute="..." attribute="..." /> <advanced-filter base-dn="..." recursive="..." user-dn-attribute="..." filter="..." /> </username-to-dn> <group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." > <!-- One of the following --> <group-to-principal base-dn="..." recursive="..." search-by="..."> <membership-filter principal-attribute="..." /> </group-to-principal> <principal-to-group group-attribute="..." /> </group-search> </ldap> </authorization>
Important
force
. Il est requis, même quand défini à la valeur par défaut false
.
username-to-dn
username-to-dn
indique comment mapper le nom d'utilisateur au nom distinctif de son entrée dans le répertoire LDAP. Cet élément n'est requis que lorsque les deux énoncés suivants sont véréfiées :
- Les étapes d'authentification et d'autorisation sont effectués sur deux serveurs LDAP distincts.
- La recherche de groupe utilise un nom distinctif.
- 1:1 username-to-dn
- Ceci indique que le nom d'utilisateur saisi par l'utilisateur distant est le nom distinctif de l'utilisateur.
<username-to-dn force="false"> <username-is-dn /> </username-to-dn>
Ceci définit un mappage 1:1, et il n'y a pas de configuration supplémentaire possible. - username-filter
- La prochaine option est très semblable à la simple option décrite ci-dessus dans l'étape d'authentification. Un attribut est spécifié et on recherche une correspondance avec le nom d'utilisateur fourni.
<username-to-dn force="true"> <username-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" attribute="sn" user-dn-attribute="dn" /> </username-to-dn>
Les attributs pouvant être définis sont les suivants :base-dn
: le nom distinctif du contexte pour commencer la recherche.recursive
: indique si la recherche va s'étendre à des sous-contextes. La valeur par défaut estfalse
.attribute
: l'attribut de l'entrée de l'utilisateur à faire correspondre avec le nom d'utilisateur fourni. La valeur par défaut estuid
.user-dn-attribute
: l'attribut à lire pour obtenir les noms distinctifs d'utilisateurs. La valeur par défaut estdn
.
- advanced-filter
- L'option finale est de spécifier un filtre avancé. Comme dans la section authentification, c'est l'opportunité d'utiliser un filtre personnalisé pour trouver le nom unique de l'utilisateur.
<username-to-dn force="true"> <advanced-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" filter="sAMAccountName={0}" user-dn-attribute="dn" /> </username-to-dn>
Pour les attributs qui correspondent à ceux du username-filter, le sens et les valeurs par défaut sont les mêmes. Cela laisse un nouvel attribut :filter
: filtre personnalisé utilisé pour chercher une entrée d'utilisateur quand le nom d'utilisateur est substitué dans l'espace réservé{0}
Important
Le code XML doit rester valide une fois que le filtre est défini donc si des caractères spéciaux comme&
sont utilisés, assurez-vous que la forme qui convient soit utilisée. Par exemple,& amp ;
pour le caractère&
.
La recherche Groupe
Exemple 6.1. Principal à Groupe - Exemple LDIF
TestUserOne
, qui est membre de GroupOne
, et GroupOne
est à son tour membre de GroupFive
. L'appartenance au groupe est démontrée par l'utilisation d'un attribut memberOf
défini au nom unique du groupe dont l'utilisateur est membre.
memberOf
définis, un pour chaque groupe dont l'utilisateur est un membre direct.
dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org objectClass: extensibleObject objectClass: top objectClass: groupMember objectClass: inetOrgPerson objectClass: uidObject objectClass: person objectClass: organizationalPerson cn: Test User One sn: Test User One uid: TestUserOne distinguishedName: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org userPassword:: e1NTSEF9WFpURzhLVjc4WVZBQUJNbEI3Ym96UVAva0RTNlFNWUpLOTdTMUE9PQ== dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org objectClass: extensibleObject objectClass: top objectClass: groupMember objectClass: group objectClass: uidObject uid: GroupOne distinguishedName: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org dn: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org objectClass: extensibleObject objectClass: top objectClass: groupMember objectClass: group objectClass: uidObject uid: GroupFive distinguishedName: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
Exemple 6.2. Groupe à Principal - Exemple LDIF
TestUserOne
qui est un membre de GroupOne
, à son tour membre de GroupFive
- cependant dans ce cas, c'est un attribut uniqueMember
du groupe de l'utilisateur utilisé pour la référence croisée.
dn: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org objectClass: top objectClass: inetOrgPerson objectClass: uidObject objectClass: person objectClass: organizationalPerson cn: Test User One sn: Test User One uid: TestUserOne userPassword:: e1NTSEF9SjR0OTRDR1ltaHc1VVZQOEJvbXhUYjl1dkFVd1lQTmRLSEdzaWc9PQ== dn: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org objectClass: top objectClass: groupOfUniqueNames objectClass: uidObject cn: Group One uid: GroupOne uniqueMember: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org dn: uid=GroupFive,ou=subgroups,ou=groups,dc=group-to-principal,dc=example,dc=org objectClass: top objectClass: groupOfUniqueNames objectClass: uidObject cn: Group Five uid: GroupFive uniqueMember: uid=TestUserFive,ou=users,dc=group-to-principal,dc=example,dc=org uniqueMember: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org
Recherche de groupe standard
<group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." > ... </group-search>
group-name
: cet attribut est utilisé pour indiquer le formulaire qui doit être utilisé pour le nom de groupe retourné correspondant à la liste de groupes dont l'utilisateur est membre. Cela peut être sous la simple forme de nom du groupe ou de nom unique de groupe. Si le nom unique est nécessaire, cet attribut peut être défini àDISTINGUISHED_NAME
. Valeur par défautSIMPLE
.itérative
: cet attribut est utilisé pour indiquer si, après avoir identifié les groupes qui appartiennent à un utilisateur, on doit rechercher également de manière itérative basée sur les groupes afin d'identifier quels groupes appartiennent à quels groupes. Si la recherche itérative est activée, nous continuons jusqu'à ce que nous rejoignions un groupe qui ne soit pas membre si aucun autre groupe ou cycle n'est détecté. Par défaut,false
.
Important
group-dn-attribute
: sur une entrée pour un groupe dont l'attribut est son nom unique. La valeur par défaut estdn
.group-name-attribute
: sur une entrée pour un groupe dont l'attribut est son simple nom. La valeur par défaut estuid
.
Exemple 6.3. Configuration d'exemple de Principal à Groupe
memberOf
de l'utilisateur.
<authorization> <ldap connection="LocalLdap"> <username-to-dn> <username-filter base-dn="ou=users,dc=principal-to-group,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" /> </username-to-dn> <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid"> <principal-to-group group-attribute="memberOf" /> </group-search> </ldap> </authorization>
principal-to-group
a été ajouté avec un seul attribut.
group-attribute
: le nom de l'attribut sur l'entrée d'utilisateur qui correspond au nom unique du groupe qui appartient à l'utilisateur. La valeur par défaut estmemberOf
.
Exemple 6.4. Configuration d'exemple de Groupe à Principal
<authorization> <ldap connection="LocalLdap"> <username-to-dn> <username-filter base-dn="ou=users,dc=group-to-principal,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" /> </username-to-dn> <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid"> <group-to-principal base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org" recursive="true" search-by="DISTINGUISHED_NAME"> <membership-filter principal-attribute="uniqueMember" /> </group-to-principal> </group-search> </ldap> </authorization>
group-to-principal
est ajouté ici. Cet élément est utilisé pour définir comment les recherches de groupes qui référencent l'entrée de l'utilisateur seront exécutées. Les attributs suivants sont définis :
base-dn
: le nom unique du contexte à utiliser pour commencer la recherche.recursive
: indique si les sous-contextes peuvent également être recherchés. La valeur par défaut estfalse
.search-by
: Le forme du nom de rôle utilisé dans les recherches. Valeurs validesSIMPLE
etDISTINGUISHED_NAME
. Valeur par défautDISTINGUISHED_NAME
.
principal-attribute
: le nom de l'attribut d'entrée de groupe qui référence l'entrée utilisateur. La valeur par défaut estmember
.
6.9.8. Scoped rôles
- Un nom unique.
- Correspond aux rôles standards sur lesquels il est basé.
- S'il s'applique au Groupes de serveurs ou aux Hôtes
- La liste des groupes de serveurs ou hôtes auxquels il est limité.
- Si tous les utilisateurs sont inclus automatiquement. La valeur par défaut sera false.
- Rôles host-scoped
- Un rôle non host-scoped limite les permissions de ce rôle à un ou plusieurs hôtes. Cela signifie que l'accès est donné aux arborescences de ressources
/host=*/
qui conviennent, mais les ressources spécifiques à d'autres hôtes sont cachées. - Rôles server-group-scoped
- Un rôle server-group-scoped limite les permissions de ce rôle à un ou plusieurs groupes de serveurs. De plus, les permissions de rôle seront appliquées également au profil, groupe de liaison de socket, config du serveur et aux ressources de serveur associés avec les groupes de serveur spécifiés. Toutes les ressources secondaires à l'intérieur non liées de manière logique au groupe de serveurs ne seront pas visibles par l'utilisateur.
6.9.9. Création de rôles scoped
SuperUser
ou Administrator
peuvent effectuer cette configuration.
- Connectez-vous à la console de gestion
- Cliquez sur l'onglet Administration
- Déployez le menu Access Control et sélectionnez Role Assignment.
- Sélectionnez l'onglet ROLES, puis l'onglet Scoped Roles à l'intérieur.
Procédure 6.22. Ajouter un nouveau scoped role
- Connectez-vous à la console de gestion
- Naviguer dans la partie Scoped Roles de l'onglet Roles.
- Cliquer sur le bouton Add. Le dialogue Add Scoped Role apparaîtra.
- Indiquer les détails suivants :
- Name, le nom distinctif du nouveau scoped role.
- Base Role, le rôle sur lequel ce rôle basera sa permission.
- Type, indique si ce rôle est limité à des hôtes ou à des groupes de serveurs.
- Scope, la liste d'hôtes ou de groupes de serveurs auxquels le rôle est limité. Vous pouvez sélectionner plusieurs entrées.
- Include All, indique si le rôle doit automatiquement inclure tous les utilisateurs. La valeur par défaut est non.
- Cliquez sur le bouton de sauvegarde Save. La boîte de dialogue se fermera et le rôle nouvellement créé apparaîtra dans le tableau.
Procédure 6.23. Modifiez un scoped role.
- Connectez-vous à la console de gestion
- Naviguer dans la partie Scoped Roles de l'onglet Roles.
- Cliquez sur le scoped role que vous souhaitez modifier dans le tableau. Les détails de ce rôle apparaissent dans le panneau Selection qui se trouve sous le tableau.
- Cliquez sur Edit dans le panneau Selection. Le panneau Selection entre en mode d'édition.
- Mettre à jour les informations que vous souhaitez modifier et cliquez sur le bouton de sauvegarde Save. Le panneau Selection retournera à son état précédent. Le panneau de sélection Selection et le tableau afficheront les informations nouvellement mises à jour.
Procédure 6.24. Affichez les membres scoped role
- Connectez-vous à la console de gestion
- Naviguez dans la partie Scoped Roles de l'onglet Roles.
- Cliquez sur le scoped role du tableau dont vous souhaitez voir les Members, puis cliquez sur le bouton Members. La boîte de dialogue Members of role apparaîtra. Elle nous affichera les utilisateurs et les groupes qui sont inclus ou exclus du rôle.
- Cliquez sur le bouton Done (terminé) quand vous aurez fini de consulter cette information.
Procédure 6.25. Supprimez un scoped role.
Important
- Connectez-vous à la console de gestion
- Naviguer dans la partie Scoped Roles de l'onglet Roles.
- Sélectionnez le scoped role à supprimer du tableau.
- Cliquez sur le bouton Remove button. Le dialogue Remove Scoped Role apparaîtra.
- Cliquez sur le bouton Confirm (confirmer). La boîte de dialogue se fermera et le rôle sera supprimé.
6.10. Configurer les contraintes
6.10.1. Configurez les contraintes de sensibilité
/core-service=management/access=authorization/constraint=sensitivity-classification
.
classification
. Les classifications sont ensuite regroupées en types
. Il existe 39 catégories incluses qui sont regroupées en 13 types.
write-attribut
permet de paramétrer les attributs configured-requires-read
, configured-requires-write
, ou configured-requires-addressable
. Pour rendre ce type d'opération sensible, définir la valeur de l'attribut à true
, sinon, pour le rendre non sensible, le définir à la valeur false
. Par défaut, ces attributs ne sont pas définis et les valeurs default-requires-read
, default-requires-write
, et default-requires-addressable
seront utilisées. Une fois que l'attribut est configuré, ce sera cette valeur qui sera utilisée à la place de la valeur par défaut. Impossible de modifier les valeurs par défaut.
Exemple 6.5. Comment rendre les propriétés système des opérations sensibles.
[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property [domain@localhost:9999 classification=system-property] :write-attribute(name=configured-requires-read, value=true) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} } [domain@localhost:9999 classification=system-property] :read-resource { "outcome" => "success", "result" => { "configured-requires-addressable" => undefined, "configured-requires-read" => true, "configured-requires-write" => undefined, "default-requires-addressable" => false, "default-requires-read" => false, "default-requires-write" => true, "applies-to" => { "/host=master/system-property=*" => undefined, "/host=master/core-service=platform-mbean/type=runtime" => undefined, "/server-group=*/system-property=*" => undefined, "/host=master/server-config=*/system-property=*" => undefined, "/host=master" => undefined, "/system-property=*" => undefined, "/" => undefined } } } [domain@localhost:9999 classification=system-property]
Tableau 6.2. Résultats des configurations de contraintes de sensibilité
Valeur | requires-read | requires-write | requires-addressable |
---|---|---|---|
true
|
L'opération lecture est sensible.
Seuls les rôles
Auditor , Administrator , et SuperUser peuvent lire.
|
L'opération écriture est sensible.
Seuls les rôles
Administrator et SuperUser peuvent écrire.
|
L'opération Adressage est sensible.
Seuls les rôles d'
Auditor , Administrator , et SuperUser peuvent lire.
|
false
|
L'opération lecture n'est pas sensible.
Tous les utilisateurs de gestion peuvent lire.
|
L'opération écriture n'est pas sensible.
Les rôles
Maintainer , Administrator , et SuperUser peuvent écrire. Les rôles Deployers peuvent également écrire dans une ressource d'applications.
|
L'opération Adressage n'est pas sensible.
Tous les utilisateurs de gestion peuvent adresser.
|
6.10.2. Configurer les contraintes de ressources d'application
/core-service=management/access=authorization/constraint=application-classification/
.
classification
. Les classifications sont ensuite regroupées en types
. Il existe 14 catégories incluses qui sont regroupées en 8 types. Chaque classification comporte un élément applies-to
qui correspond à une liste de modèles de chemins d'accès de ressources s'appliquant à la configuration de la classification.
core
. Core inclut des déploiements, des superpositions de déploiement et des opérations de déploiement.
write-attribute
permet de définir l'attribut configured-application attribute
de la classification sur true
. Pour désactiver une ressource d'application, définir cet attribut sur false
. Par défaut, ces attributs ne sont pas définis et la valeur default-application attribute
sera utilisée. La valeur par défaut ne peut pas être modifiée.
Exemple 6.6. Activer la classification des ressources d'application logger-profile
[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile [domain@localhost:9999 classification=logging-profile] :write-attribute(name=configured-application, value=true) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} } [domain@localhost:9999 classification=logging-profile] :read-resource { "outcome" => "success", "result" => { "configured-application" => true, "default-application" => false, "applies-to" => {"/profile=*/subsystem=logging/logging-profile=*" => undefined} } } [domain@localhost:9999 classification=logging-profile]
Important
Deployer
d'accéder à une ressource de source de données mais pas à une autre. Si ce niveau de séparation est nécessaire, il est recommandé de configurer les ressources dans différents groupes de serveurs et de créer les rôles Deployer
d'étendue différente pour chaque groupe.
6.10.3. Configuration de contraintes d'expressions d'archivage sécurisé
/core-service=management/access=authorization/constraint=vault-expression
.
write-attribute
pour définir les attributs de configured-requires-write
et configured-requires-read
à true
ou false
. Par défaut, celles-ci ne sont pas définies et les valeurs default-requires-read
et default-requires-write
sont utilisées. Impossible de modifier les valeurs par défaut.
Exemple 6.7. Comment rendre l'écriture d'expressions d'archivage une opération non sensible
[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=vault-expression [domain@localhost:9999 constraint=vault-expression] :write-attribute(name=configured-requires-write, value=false) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} } [domain@localhost:9999 constraint=vault-expression] :read-resource { "outcome" => "success", "result" => { "configured-requires-read" => undefined, "configured-requires-write" => false, "default-requires-read" => true, "default-requires-write" => true } } [domain@localhost:9999 constraint=vault-expression]
Tableau 6.3. Résultats des configurations de contraintes d'expressions d'archivage sécurisé
Valeur | requires-read | requires-write |
---|---|---|
true
|
L'opération lecture est sensible.
Seuls les rôles d'
Auditor , Administrator , et SuperUser peuvent lire.
|
L'opération écriture est sensible.
Seuls les rôles
Administrator , et SuperUser peuvent écrire.
|
false
|
L'opération lecture n'est pas sensible.
Tous les utilisateurs de gestion peuvent lire.
|
L'opération d'écriture n'est pas sensible.
Les rôles
Monitor , Administrator , et SuperUser peuvent écrire. Les rôles Deployers peuvent également écrire si l'expression d'archivage de sécurité est dans une ressource d'application.
|
6.11. Références de contraintes
6.11.1. Références de contraintes de ressources d'application
Type: core
- Classification: deployment-overlay
- default: true
- PATH: /deployment-overlay=*
- PATH: /deployment=*
- PATH: /Opération :upload-deployment-stream, full-replace-deployment, upload-deployment-url, upload-deployment-bytes
Type: datasources
- Classification: datasource
- default: false
- PATH: /deployment=*/subdeployment=*/subsystem=datasources/data-source=*
- PATH: /subsystem=datasources/data-source=*
- PATH: /subsystem=datasources/data-source=ExampleDS
- PATH: /deployment=*/subsystem=datasources/data-source=*
- Classification: jdbc-driver
- default: false
- PATH: /subsystem=datasources/jdbc-driver=*
- Classification: xa-data-source
- default: false
- PATH: /subsystem=datasources/xa-data-source=*
- PATH: /deployment=*/subsystem=datasources/xa-data-source=*
- PATH: /deployment=*/subdeployment=*/subsystem=datasources/xa-data-source=*
Type: logging
- Classification: logger
- default: false
- PATH: /subsystem=logging/logger=*
- PATH: /subsystem=logging/logging-profile=*/logger=*
- Classification: logging-profile
- default: false
- PATH: /subsystem=logging/logging-profile=*
Type: mail
- Classification: mail-session
- default: false
- PATH: /subsystem=mail/mail-session=*
Type: naming
- Classification: binding
- default: false
- PATH: /subsystem=naming/binding=*
Type: resource-adapters
- Classification: resource-adapters
- default: false
- PATH: /subsystem=resource-adapters/resource-adapter=*
Type: security
- Classification: security-domain
- default: false
- PATH: /subsystem=security/security-domain=*
6.11.2. Références de contraintes de sensibilité
Type: core
- Classification: access-control
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /core-service=management/access=authorization
- PATH: /subsystem=jmx ATTRIBUTE: non-core-mbean-sensitivity
- Classification: credential
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=mail/mail-session=*/server=pop3 ATTRIBUTE: username , password
- PATH: /subsystem=mail/mail-session=*/server=imap ATTRIBUTE: username , password
- PATH: /subsystem=datasources/xa-data-source=* ATTRIBUTE: user-name, recovery-username, password, recovery-password
- PATH: /subsystem=mail/mail-session=*/custom=* ATTRIBUTE: username, password
- PATH: /subsystem=datasources/data-source=*" ATTRIBUTE: user-name, password
- PATH: /subsystem=remoting/remote-outbound-connection=*" ATTRIBUTE: username
- PATH: /subsystem=mail/mail-session=*/server=smtp ATTRIBUTE: username, password
- PATH: /subsystem=web/connector=*/configuration=ssl ATTRIBUTE: key-alias, password
- PATH: /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*" ATTRIBUTE: recovery-username, recovery-password
- Classification: domain-controller
- requires-addressable: false
- requires-read: false
- requires-write: true
- Classification: domain-names
- requires-addressable: false
- requires-read: false
- requires-write: true
- Classification: extensions
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /extension=*
- Classification: jvm
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=platform-mbean/type=runtime ATTRIBUTE: input-arguments, boot-class-path, class-path, boot-class-path-supported, library-path
- Classification: management-interfaces
- requires-addressable: false
- requires-read: false
- requires-write: true
- /core-service=management/management-interface=native-interface
- /core-service=management/management-interface=http-interface
- Classification: module-loading
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=module-loading
- Classification: patching
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=patching/addon=*
- PATH: /core-service=patching/layer=*"
- PATH: /core-service=patching
- Classification: read-whole-config
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: / OPERATION: read-config-as-xml
- Classification: security-domain
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /subsystem=security/security-domain=*
- Classification: security-domain-ref
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /subsystem=datasources/xa-data-source=* ATTRIBUTE: security-domain
- PATH: /subsystem=datasources/data-source=* ATTRIBUTE: security-domain
- PATH: /subsystem=ejb3 ATTRIBUTE: default-security-domain
- PATH: /subsystem=resource-adapters/resource-adapter=*/connection-definitions=* ATTRIBUTE: security-domain, recovery-security-domain, security-application, security-domain-and-application
- Classification: security-realm
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /core-service=management/security-realm=*
- Classification: security-realm-ref
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /subsystem=remoting/connector=* ATTRIBUTE: security-realm
- PATH: /core-service=management/management-interface=native-interface ATTRIBUTE: security-realm
- PATH: /core-service=management/management-interface=http-interface ATTRIBUTE: security-realm
- PATH: /subsystem=remoting/remote-outbound-connection=* ATTRIBUTE: security-realm
- Classification: security-vault
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=vault
- Classification: service-container
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=service-container
- Classification: snapshots
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: / ATTRIBUTE: take-snapshot, list-snapshots, delete-snapshot
- Classification: socket-binding-ref
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=mail/mail-session=*/server=pop3 ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=mail/mail-session=*/server=imap ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=remoting/connector=* ATTRIBUTE: socket-binding
- PATH: /subsystem=web/connector=* ATTRIBUTE: socket-binding
- PATH: /subsystem=remoting/local-outbound-connection=* ATTRIBUTE: outbound-socket-binding-ref
- PATH: /socket-binding-group=*/local-destination-outbound-socket-binding=* ATTRIBUTE: socket-binding-ref
- PATH: /subsystem=remoting/remote-outbound-connection=* ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=mail/mail-session=*/server=smtp ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=transactions ATTRIBUTE: process-id-socket-binding, status-socket-binding, socket-binding
- Classification: socket-config
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /interface=* OPERATION: resolve-internet-address
- PATH: /core-service=management/management-interface=native-interface ATTRIBUTE: port, interface, socket-binding
- PATH: /socket-binding-group=*
- PATH: /core-service=management/management-interface=http-interface ATTRIBUTE: port, secure-port, interface, secure-socket-binding, socket-binding
- PATH: / OPERATION: resolve-internet-address
- PATH: /subsystem=transactions ATTRIBUTE: process-id-socket-max-ports
- Classification: system-property
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=platform-mbean/type=runtime ATTRIBUTE: system-properties
- PATH: /system-property=*
- PATH: / OPERATION: resolve-expression
Type: datasources
- Classification: data-source-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=datasources/xa-data-source=* ATTRIBUTE: user-name, security-domain, password
- PATH: /subsystem=datasources/data-source=* ATTRIBUTE: user-name, security-domain, password
Type: jdr
- Classification: jdr
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /subsystem=jdr OPERATION: generate-jdr-report
Type: jmx
- Classification: jmx
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /subsystem=jmx
Type: mail
- Classification: mail-server-security
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /subsystem=mail/mail-session=*/server=pop3 ATTRIBUTE: username, tls, ssl, password
- PATH: /subsystem=mail/mail-session=*/server=imap ATTRIBUTE: username, tls, ssl, password
- PATH: /subsystem=mail/mail-session=*/custom=* ATTRIBUTE: username, tls, ssl, password
- PATH: /subsystem=mail/mail-session=*/server=smtp ATTRIBUTE: username, tls, ssl, password
Type: naming
- Classification: jndi-view
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=naming OPERATION: jndi-view
- Classification: naming-binding
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=naming/binding=*
Type: remoting
- Classification: remoting-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=remoting/connector=* ATTRIBUTE: authentication-provider, security-realm
- PATH: /subsystem=remoting/remote-outbound-connection=* ATTRIBUTE: username, security-realm
- PATH: /subsystem=remoting/connector=*/security=sasl
Type: resource-adapters
- Classification: resource-adapter-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=resource-adapters/resource-adapter=*/connection-definitions=* ATTRIBUTE: security-domain, recovery-username, recovery-security-domain, security-application, security-domain-and-application, recovery-password
Type: security
- Classification: misc-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=security ATTRIBUTE: deep-copy-subject-mode
Type: web
- Classification: web-access-log
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=web/virtual-server=*/configuration=access-log
- Classification: web-connector
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=web/connector=*
- Classification: web-ssl
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=web/connector=*/configuration=ssl
- Classification: web-sso
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=web/virtual-server=*/configuration=sso
- Classification: web-valve
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=web/valve=*
Chapitre 7. Sécuriser les mots de passe et les autres chaînes sensibles par un archivage sécurisé.
7.1. Système d'archivage sécurisé de mots de passe
7.2. Créer un Keystore Java pour stocker des strings sensibles
Pré-requis
- La commande
keytool
doit être disponible. Elle est fournie par le Java Runtime Environment (JRE). Chercher le chemin du fichier. Se trouve à l'emplacement suivant/usr/bin/keytool
dans Red Hat Enterprise Linux.
Avertissement
vault.keystore
à l'aide du keytool
du même fournisseur que le JDK que vous utilisez.
keytool
de JDK d'un fournisseur dans une instance EAP exécutant dans un JDK provenant d'un fournisseur différent, vous aurez l'exception suivante :
java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector
Procédure 7.1. Installation du Java Keystore
Créez un répertoire pour stocker votre keystore et autres informations cryptées.
Créez un répertoire qui contiendra votre keystore et autres informations pertinentes. Le reste de cette procédure assume que le répertoire estEAP_HOME/vault/
. Comme le répertoire devra contenir des informations sensibles, il devra être accessible à un nombre restraint d'utilisateurs. Au minimum, le compte d'utilisateur sous lequel JBoss EAP exécute requiert un accès en lecture-écriture.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. Dans cette procédure, l'exemple utilise
RSA
. 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. Dans cette procédure, l'exemple utilise
1024
. Pour plus d'informations sur les valeurs appropriées, voir la documentation distribuée aveckeytool
. - keystore
- Le keystore est une base de données qui contient des informations chiffrées et des informations sur la façon de décrypter. Si vous ne spécifiez pas de keystore, le keystore par défaut à utiliser est un fichier appelé
.keystore
qui se trouve dans 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 dukeytool
a plusieurs options. Consultez la documentation de votre JRE ou de votre système d'exploitation pour obtenir plus d'informations.Déterminez les réponses aux questions que la commande
keystore
vous demandera.Lekeystore
a besoin des informations suivantes pour remplir l'entrée du keytore :- Mot de passe du keystore
- Lorsque vous créez un keystore, vous devez définir un mot de passe. Pour pouvoir travailler dans le keystore dans le futur, vous devez fournir le mot de passe. Créez 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, ainsi que 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. Ne doit pas nécessairement correspondre à un nom, mais doit être composé de deux mots et doit être unique à une clé. L'exemple dans cette procédure utilise
Admninistrateur Comptabilité
. En terme de répertoires, cela devient le nom commun 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
, en fournissant les informations que vous avez collectées.Exemple 7.1. Exemple d'entrée et de sortie de la commande
keystore
$ keytool -genseckey -alias vault -storetype jceks -keyalg AES -keysize 128 -storepass vault22 -keypass vault22 -validity 730 -keystore
EAP_HOME/vault/
vault.keystore Enter keystore password: vault22 Re-enter new password:vault22 What is your first and last name? [Unknown]:Accounting Administrator
What is the name of your organizational unit? [Unknown]:AccountingServices
What is the name of your organization? [Unknown]:MyOrganization
What is the name of your City or Locality? [Unknown]:Raleigh
What is the name of your State or Province? [Unknown]:NC
What is the two-letter country code for this unit? [Unknown]:US
Is CN=Accounting Administrator, OU=AccountingServices, O=MyOrganization, L=Raleigh, ST=NC, C=US correct? [no]:yes
Enter key password for <vault> (RETURN if same as keystore password):
Un fichier nommé vault.keystore
est créé dans le répertoire EAP_HOME/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 EAP 6.
7.3. Masquer le mot de passe du keystore et initialiser le mot de passe de l'archivage de sécurité
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 accessible à des utilisateurs limités uniquement. Au minimum, le compte d'utilisateur sous lequel JBoss EAP exécute requiert un accès lecture-écriture. Si vous avez suivi Section 7.2, « Créer un Keystore Java pour stocker des strings sensibles », votre keystore se trouvera dans le répertoire nomméEAP_HOME/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 utiliseEAP_HOME/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 7.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.
Saisir2
pour sortir de la console interactive.
Votre mot de passe de keystore est masqué afin de pouvoir être utilisé dans les fichiers de configuration et de déploiement. De plus, votre archivage de sécurité est complètement configuré et prêt à l'utilisation.
7.4. Configurer JBoss EAP pour qu'il utilise l'archivage sécurisé des mots de passe
Avant de masquer les mots de passe et d'autres attributs sensibles dans les fichiers de configuration, vous devez sensibiliser JBoss EAP 6 à l'archivage sécurisé des mots de passe qui les stocke et les déchiffre. Suivez cette procédure pour activer cette fonctionnalité.
Pré-requis
Procédure 7.2. 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 7.2, « Créer un Keystore Java pour stocker des strings sensibles » et Section 7.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.keystore
KEYSTORE_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 configurezUtilisez l'interface CLI pour activer les mots de passe sécurisés.
Exécutez une des commandes suivantes, selon que vous utilisez 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.Note
Si vous utilisez Microsoft Windows Server, remplacez chaque caractère\
du chemin d'accès du répertoire par un caractère\
supplémentaire dans la commande CLI. Par exemple,C:\\data\\vault\\vault.keystore
. C'est parce qu'un simple caractère\
est utilisé comme caractère d'échappement.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/")])
JBoss EAP 6 est configuré 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 7.6, « Stocker et résoudre des strings sensibles cryptés du Keystore Java. ».
7.5. Configurer JBoss EAP pour qu'il utilise une implémentation d'archivage sécurisé personnalisé
Vous pouvez utiliser votre propre implémentation de SecurityVault
pour masquer les mots de passe, et les autres attributs sensibles dans les fichiers de configuration.
Procédure 7.3. Utilisez une implémentation sécurisée de l'archivage des mots de passe
- Créez une classe qui implémente l'interface
SecurityVault
. - Créez un module contenant la classe de l'étape précédente, et spécifiez une dépendance sur
org.picketbox
où l'interface estSecurityVault
. - Activez l'archivage de mots de passe sécurisé dans la configuration du serveur JBoss EAP en ajoutant l'élément d'archivage à l'aide des attributs suivants :
- code
- La nom complet de la classe qui implémente
SecurityVault
. - module
- Le nom du module qui contient la classe personnalisée.
Optionnellement, vous pouvez utiliser les paramètresvault-options
pour initialiser la classe personnalisée d'un archivage de mots de passe. Par exemple :/core-service=vault:add(code="custom.vault.implementation.CustomSecurityVault", module="custom.vault.module", 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")])
JBoss EAP 6 est configuré pour décrypter les chaînes masquées par l'intermédiaire d'une implémentation personnalisée de l'archivage des mots de passe.
7.6. Stocker et résoudre des strings sensibles cryptés du Keystore Java.
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 EAP 6 inclut la capacité à stocker et à utiliser les valeurs masquées dans les fichiers de configuration, et à utiliser ces valeurs masquées dans les fichiers de configuration.
Pré-requis
- L'application
EAP_HOME/bin/vault.sh
doit pouvoir être accessible via l'interface de ligne de commande.
Procédure 7.4. Installation du Java Keystore
Exécutez la commande
vault.sh
.ExécutezEAP_HOME/bin/vault.sh
. Démarrez une nouvelle session interactive en tapant0
.Saisir le nom du répertoire où les fichiers cryptés seront stockés.
Si vous suivez Section 7.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.Saisissez le nom de votre keystore.
Saisissez le nom complet vers le fichier de keystore. Cet exemple utilise/home/USER/vault/vault.keystore
.Saisissez 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é, saisissez le mot de passe du keystore, le nom de l'archivage sécurisé, salt, et le nombre d'itérations.Sélectionnez l'option de stockage d'un mot de passe.
Sélectionnez l'option0
de stockage d'un mot de passe ou autre string sensible.Saisissez la valeur.
Une fois que vous y êtes invité, saisissez la valeur à deux reprises. Si les valeurs ne correspondent pas, vous serez invité à essayer à nouveau.Saisissez le bloc d'archivage sécurisé.
Saisissez le bloc d'archivage sécurisé, qui correspond à un conteneur pour les attributs ayant trait à la même ressource. Un exemple de nom d'attribut pourrait êtreds_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.Saissez le nom de l'attribut.
Saisissez 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é.
La valeur d'attribut sécurisé est stockée dans l'archivage sécurisé.
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 Configuration should be done as follows: VAULT::ds_ExampleDS::password::1 ********************************************
Utilisez le string crypté dans votre configuration.
Utilisez 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 indiqué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::1}</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écutez 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, cherchez 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, utilisez la syntaxe suivante pour remplacer tout string en texte claire par un texte crypté.${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::ENCRYPTED_VALUE}
Voici un exemple de valeur réelle, où le bloc d'archivage sécurisé estds_ExampleDS
et l'attribut estpassword
.<password>${VAULT::ds_ExampleDS::password::1}</password>
7.7. Stocker et résoudre des strings sensibles de vos applications
Les éléments de configuration de la plate-forme JBoss EAP 6 prennent en charge la capacité à régler les chaînes cryptées en fonction des valeurs stockées dans Java Keystore, via le mécanisme Security Vault. Vous pouvez ajouter le support pour cette fonctionnalité à vos propres applications.
Avant d'effectuer cette procédure, assurez-vous que le répertoire utilisé pour stocker vos fichiers dans le Security Vault existe bien. Qu'importe où vous les placez, tant que l'utilisateur qui exécute JBoss EAP 6 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 7.2. Ajout du string de mot de passe au Security Vault
EAP_HOME/bin/vault.sh
. La série de commandes et de 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, les chemins d'accè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: Exit0
Starting an interactive session Enter directory to store encrypted files:/home/user/vault/
Enter Keystore URL:/home/user/vault/vault.keystore
Enter Keystore password:...
Enter Keystore password again:...
Values match Enter 8 character salt:12345678
Enter iteration count as a number (Eg: 44):25
Enter Keystore Alias:vault
Vault is initialized and ready for use Handshake with Vault complete Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit0
Task: Store a password Please enter attribute value:sa
Please enter attribute value again:sa
Values match Enter Vault Block:DS
Enter Attribute Name:thePass
Secured attribute value has been stored in vault. Please make note of the following: ******************************************** Vault Block:DS Attribute Name:thePass Configuration should be done as follows: VAULT::DS::thePass::1 ******************************************** Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit2
VAULT
.
Exemple 7.3. Servlet qui utilise un mot de passe d'archivage sécurisé.
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::1", 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) + ""); } }
Chapitre 8. Web, Connecteurs HTTP, et HTTP Clustering
8.1. Configurer un nœud de worker de mod_cluster
Un worker node en cluster_mode est un serveur d'applications qui participe à l'équilibrage des charges dans un cluster. Les requêtes utilisateurs sont reçues par un serveur web, qui redirige ces requêtes vers un pool de noeuds de workers mod_cluster. Un noeud de workers peut faire partie d'un groupe de serveurs d'un domaine géré, ou d'un serveur autonome. Pour obtenir des informations sur l'équilibrage des charges, voir Overview of HTTP Connectors dans le guide Administration and Configuration Guide.
mod_cluster
. Pour configurer le sous-système mod_cluster
, reportez-vous à Configure the mod_cluster Subsystem dans Administration and Configuration Guide.
Configuration d'un nœud de worker
- Un serveur autonome devra démarrer avec le profil
standalone-ha
oustandalone-full-ha
. - Un groupe de serveurs de domaine géré devra utiliser le profil
ha
oufull-ha
, et le groupe de liaisons de socketsha-sockets
oufull-ha-sockets
. JBoss EAP 6 est fourni avec un groupe de serveurs à clusterisation activée, nomméother-server-group
qui remplit ces prérequis.
Note
/profile=full-ha
des commandes.
Procédure 8.1. Configurez un nœud de worker
Configurez les interfaces de réseau
Les interfaces de réseau ont toutes la valeur127.0.0.1
par 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 d'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 EAP 6, 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 CLI se fie à une adresse de gestion stable.Suivez ces étapes pour changer l'adresse IP sur chaque serveur de votre cluster par votre adresse IP publique de master.- Démarrez le serveur JBoss EAP en utilisant le profil décrit plus haut dans cette section.
- Lancez la Management CLI, avec la commande
EAP_HOME/bin/jboss-cli.sh
dans Linux ou bien la commandeEAP_HOME\bin\jboss-cli.bat
dans le serveur Microsoft Windows. Saisissez la commandeconnect
pour connecter le contrôleur de domaine sur l'hôte local, ouconnect IP_ADDRESS
pour vous connecter à un contrôleur de domaines sur un serveur éloigné. - Modifier l'adresse IP externe des interfaces
management
,public
etunsecure
en saisissant les commandes suivantes. Veillez bien à remplacerEXTERNAL_IP_ADDRESS
qui se trouve dans la commande, par l'adresse IP externe de l'hôte.
Vous devriez voir le résultat suivant pour chaque commande./interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:EXTERNAL_IP_ADDRESS}"
/interface=public:write-attribute(name=inet-address,value="${jboss.bind.address.public:EXTERNAL_IP_ADDRESS}"
/interface=unsecure:write-attribute(name=inet-address,value="${jboss.bind.address.unsecure:EXTERNAL_IP_ADDRESS}"
:reload
"outcome" => "success"
- Pour les hôtes qui participent à un domaine géré, mais qui ne sont pas master, vous devrez modifiez le nom d'hôte du
master
par un nom unique. Ce nom devra être unique (parmi les noms d'esclave) et sera utilisé par l'esclave pour s'authentifier au cluster, donc notez bien le nom que vous utilisez.- Démarrer l'hôte esclave JBoss EAP à l'aide de la syntaxe suivante :
Par exemple :bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
bin/domain.sh --host-config=host-slave01.xml
- Lancer l'interface CLI.
- Utiliser la syntaxe suivante pour remplacer le nom d'hôte :
Par exemple :/host=master:write-attribute(name="name",value=UNIQUE_HOST_SLAVE_NAME)
Vous devriez voir apparaître le résultat suivant./host=master:write-attribute(name="name",value="host-slave01")
"outcome" => "success"
Cela modifie le XML du fichierhost-slave01.xml
comme suit :<host name="host-slave01" xmlns="urn:jboss:domain:1.6">
- Pour les hôtes nouvellement configurés qui ont besoin de rejoindre un domaine géré, cherchez l'élément
local
et ajoutez l'attributhost
de l'élementremote
qui pointe en direction du contrôleur de domaine. Cette étape ne s'applique pas à un serveur autonome.- Démarrer l'hôte esclave JBoss EAP à l'aide de la syntaxe suivante :
Par exemple :bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
bin/domain.sh --host-config=host-slave01.xml
- Lancer l'interface CLI.
- Utilisez la syntaxe suivante en spécifiant le contrôleur de domaine :
Par exemple :/host=UNIQUE_HOST_SLAVE_NAME/:write-remote-domain-controller(host=DOMAIN_CONTROLLER_IP_ADDRESS,port=${jboss.domain.master.port:9999},security-realm="ManagementRealm")
Vous devriez voir apparaître le résultat suivant./host=host-slave01/:write-remote-domain-controller(host="192.168.1.200",port=${jboss.domain.master.port:9999},security-realm="ManagementRealm")
"outcome" => "success"
Cela modifie le XML du fichierhost-slave01.xml
comme suit :<domain-controller> <remote host="192.168.1.200" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> </domain-controller>
Configurez l'authentification pour chaque serveur esclave.
Chaque serveur esclave a besoin d'un nom d'utilisateur et d'un mot de passe créé dans leManagementRealm
du contrôleur de domaine ou du master autonome. Sur le contrôleur de domaine ou sur le master autonome, exécutez la commandeEAP_HOME/bin/add-user.sh
. Ajoutez 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):
a
Enter the details of the new user to add. Realm (ManagementRealm) : Username :slave1
Password :changeme
Re-enter Password :changeme
About to add user 'slave1' for realm 'ManagementRealm' Is this correct yes/no?yes
Added 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=" />Copiez 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, copiez l'élément<secret>
à partir de la dernière ligne de la sortieadd-user.sh
car vous en aurez besoin à l'étape suivante.Modifiez le domaine de sécurité de l'hôte esclave pour la nouvelle authentification.
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 du serveur par le CLI.
- Lancez la Management CLI, avec la commande
EAP_HOME/bin/jboss-cli.sh
dans Linux ou bien la commandeEAP_HOME\bin\jboss-cli.bat
dans le serveur Microsoft Windows. Saisissez la commandeconnect
pour connecter le contrôleur de domaine sur l'hôte local, ouconnect IP_ADDRESS
pour vous connecter à un contrôleur de domaines sur un serveur éloigné. - Spécifiez la valeur secrète en saisissant la commande suivante. Veillez bien à remplacer
SECRET_VALUE
par la valeur secrète retournée de la sortieadd-user.sh
lors de l'étape précédente.
Vous devriez voir le résultat suivant pour chaque commande./core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="SECRET_VALUE")
:reload
"outcome" => "success"
Configurez l'hôte pour obtenir un mot de passe de l'archivage sécurisé.
- Utilisez le script
vault.sh
pour générer un mot de passe masqué. Cela génèrera une chaîne comme la suivante :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 7.1, « Système d'archivage sécurisé de mots de passe ». - Lancez la Management CLI, avec la commande
EAP_HOME/bin/jboss-cli.sh
dans Linux ou bien la commandeEAP_HOME\bin\jboss-cli.bat
dans le serveur Microsoft Windows. Saisissez la commandeconnect
pour connecter le contrôleur de domaine sur l'hôte local, ouconnect IP_ADDRESS
pour vous connecter à un contrôleur de domaines sur un serveur éloigné. - Spécifiez la valeur secrète en saisissant la commande suivante. Veillez bien à remplacer
SECRET_VALUE
par le mot de passe masqué généré lors de l'étape précédente.
Vous devriez voir le résultat suivant pour chaque commande./core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${VAULT::secret::password::SECRET_VALUE}")
:reload
"outcome" => "success"
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écifiez le mot de passe en tant que propriété système.
Les exemples suivants utilisentserver.identity.password
comme nom de propriété de système pour le mot de passe.- Spécifiez la propriété système pour le mot de passe dans le fichier de configuration du serveur par le CLI.
- Lancez la Management CLI, avec la commande
EAP_HOME/bin/jboss-cli.sh
dans Linux ou bien la commandeEAP_HOME\bin\jboss-cli.bat
dans le serveur Microsoft Windows. Saisissez la commandeconnect
pour connecter le contrôleur de domaine sur l'hôte local, ouconnect IP_ADDRESS
pour vous connecter à un contrôleur de domaines sur un serveur éloigné. - Saisissez la commande suivante pour configurer l'identité secrète pour utiliser la propriété système.
Vous devriez voir le résultat suivant pour chaque commande./core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${server.identity.password}")
:reload
"outcome" => "success"
- 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émarrez 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 passez l'URL du fichier de propriétés sous forme d'argument de ligne de commande.
- Ajoutez la paire clé/valeur à un fichier de propriétés. Par exemple :
server.identity.password=changeme
- Démarrez le serveur par les arguments de ligne de commande
--properties=URL_TO_PROPERTIES_FILE
.
Redémarrez 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 mot de passe.
Votre serveur autonome, ou les serveurs au sein d'un groupe de serveurs d'un domaine géré, sont désormais configurés en tant que od_cluster Worker Node. Si vous déployez une application en cluster, ses sessions sont répliquées sur tous les nœuds de cluster de basculement, et il peut accepter les demandes provenant d'un serveur Web externe ou d'un équilibreur de charge. Chaque nœud du cluster détecte les autres nœuds à l'aide de découverte automatique, par défaut. Pour configurer la détection automatique et les autres paramètres spécifiques du sous-système mod_cluster
, reportez-vous à Configure the mod_cluster Subsystem dans le guide Administration and Configuration Guide. Pour configurer le serveur Apache HTTP, reportez-vous à Use an External Web as the Web Front-end for JBoss EAP 6 Applications dans Administration and Configuration Guide.
Chapitre 9. Installation de correctif
9.1. Correctifs et Mises à jour
9.2. Mécanismes de correction
Important
- Mises à jour asynchrônes : correctifs ponctuels publiés en dehors d'un cycle de mise à jour normal du produit existant. Ces mises à jour peuvent inclure des correctifs de sécurité, ainsi que d'autres correctifs ponctuels fournis par GSS (Red Hat Global Support Services) pour résoudre ces problèmes particuliers.
- Mises à jour prévues : comprennent les correctifs cumulatifs, ainsi que les mises à niveau mineures ou majeures d'un produit existant. Les correctifs cumulatifs incluent toutes les mises à jour déjà développées pour cette version du produit.
Important
EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE
. Les fichiers d'origine sont laissés en EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE
. Le mécanisme de correction paralyse les fichiers jar d'origine pour des raisons de sécurité. Cela signifie que si vous appliquez un correctif qui met à jour un module, les fichiers jar du module d'origine seront modifiés afin de devenir inutilisables. Si le correctif est renversé, les fichiers d'origine reviennent dans à un état utilisable. Il faut également que la procédure appropriée soit utilisée pour renverser l'action de tout correctif appliqué. Voir Section 9.4.3, « Annulation d'un correctif sous forme zip par le système de gestion des correctifs » pour la procédure de rollback qui convient.
9.3. Abonnez-vous aux listes de diffusion de correctifs (Patch Mailing Lists)
L'équipe JBoss de Red Hat maintient une liste de diffusion pour les annonces de sécurité pour les produits Red Hat JBoss Middleware. Cette section couvre ce que vous devez faire pour vous abonner à cette liste.
Pré-requis
- Aucun
Procédure 9.1. Abonnez-vous à JBoss Watch List
- Cliquez sur le lien suivant pour vous rendre sur la page de la liste de diffusion JBoss Watch : JBoss Watch Mailing List.
- Saisissez votre adresse email dans la section Subscribing to Jboss-watch-list.
- [Vous pourrez aussi saisir votre nom et sélectionner un mot de passe. En option, mais recommandé.]
- Cliquez sur le bouton Subscribe (s'abonner) 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.
Après la confirmation de votre adresse email, vous serez abonné aux communiqués de sécurité sur la liste de diffusion des correctifs de JBoss.
9.4. Installer des correctifs en Zip
9.4.1. Le Patch Management System (système de gestion des correctifs)
patch
. Le système de gestion de correctifs ne permet pas de corriger automatiquement les instances du serveur JBoss EAP 6 sur un domaine géré, mais les instances de serveur individuel d'un domaine géré peuvent être corrigées indépendamment.
Important
Note
patch
.
Tableau 9.1. Arguments et Options de commande patch
Argument ou Option | Description |
---|---|
apply | Applique un correctif |
--override-all | S'il y a un conflit, l'opération de correctif va remplacer toutes les modifications utilisateur. |
--override-modules | Si le conflit résulte de la modification d'un module, cette option remplacera ces modifications par le contenu de l'opération de correctif. |
--override=path(,path) | Pour les divers fichiers spécifiés uniquement, cela remplacera les fichiers modifiés en conflit par les fichiers de l'opération de correctif. |
--preserve=path(,path) | Pour les divers fichiers spécifiés uniquement, cela préservera les fichiers modifiés en conflit. |
--host=HOST_NAME | Disponible en mode de domaine, indique l'hôte sur lequel l'opération de correction aura lieu. |
info | Renvoie l'information sur les correctifs actuellement installés. |
history | Renvoie l'information sur l'historique des correctifs. |
rollback | Opération de restauration suite à l'application d'un correctif. |
--patch-id=PATCH_ID | Requis pour la suppression, l'ID du correctif à restaurer. |
--reset-configuration=TRUE|FALSE | Dans le cadre d'une restauration, cela indique si on doit restaurer les fichiers de configuration du serveur. |
--rollback-to | Si le correctif à supprimer est un correctif isolé (une seule fois), en utilisant cet argument, vous spécifiez que l'opération de restauration s'appliquera à tous les autres correctifs isolés appliqués au dessus du correctif spécifié. |
9.4.2. Installation des correctifs sous forme zip par le Patch Management System (système de gestion des correctifs)
Les correctifs qui sont en format zip peuvent être installés en utilisant le système de gestion de JBoss EAP 6 patch via l'interface de gestion CLI ou la console de gestion.
Important
Pré-requis
- Accès valide et abonnement au portail clients de Red Hat.
- Un abonnement en cours à un produit JBoss installé en format zip.
- Accédez à l'interface CLI ou à la console de gestion pour mettre à jour le serveur de JBoss EAP 6. Voir la section Launch the Management CLI ou Log in to the Management Console du guide Administration and Configuration Guide.
Avertissement
Procédure 9.2. Appliquez un correctif zip à une instance de serveur JBoss EAP 6 par l'interface de gestion CLI
- Téléchargez le fichier zip de correctif à partir du portail clients à partir de https://access.redhat.com/downloads/
- À l'aide du CLI, appliquez le correctif par la commande suivante et le chemin qui convient pour le fichier de correction :
[standalone@localhost:9999 /]
patch apply /path/to/downloaded-patch.zip
L'outilpatch
avertira s'il y a conflit de tentative d'application de correctif. Consultez Section 9.4.1, « Le Patch Management System (système de gestion des correctifs) » pour voir les options d'exécution à ajouter quand vous lancerez la commandepatch
à nouveau pour résoudre les conflits. - Démarrez à nouveau le serveur JBoss EAP 6 pour que le correctif puisse prendre effet :
[standalone@localhost:9999 /]
shutdown --restart=true
Procédure 9.3. Appliquez un correctif zip à une instance de serveur JBoss EAP 6 par le biais de la console de gestion
- Téléchargez le fichier zip de correctif à partir du portail clients à partir de https://access.redhat.com/downloads/
- Dans la console de gestion :
- Pour un serveur autonome : cliquez sur l'onglet Runtime (exécution) en haut de l'écran, puis cliquez sur Patch Management (gestion des correctifs).
- Pour un domaine géré : cliquez sur l'onglet Domain en haut de l'écran, puis cliquez sur le menu déroulant Host (hôte), puis cliquez sur Patch Management (gestion des correctifs).
- Cliquez sur Apply a New Patch (appliquer un nouveau correctif).
- Si vous corrigez un hôte de domaine géré, sélectionnez si vous devez arrêter des serveurs sur l'hôte sur le prochain écran, puis cliquez sur Next (suite).
- Cliquez sur le bouton de navigation Browse, puis sélectionnez le correctif téléchargé que vous souhaitez appliquer, puis cliquez sur Next.
- S'il existe des conflits lors du processus d'application du correctif, un message d'avertissement s'affichera. Cliquez sur View error details pour voir le détail des conflits. S'il y a un conflit, vous pouvez annuler l'opération, ou bien, activez la case à cocher Override all conflicts (supprimer tous les conflits) et cliquez sur le bouton Next. La suppression des conflits se traduira par le contenu du patch prévalant sur toute modification de l'utilisateur.
- Une fois que le correctif aura été appliqué, sélectionnez s'il faut redémarrer le serveur JBoss EAP 6 dès maintenant pour que le correctif prenne effet, puis cliquez sur Finish.
L'instance de serveur JBoss EAP 6 est corrigée avec la dernière mise à jour.
9.4.3. Annulation d'un correctif sous forme zip par le système de gestion des correctifs
Le système de gestion de correctifs de JBoss EAP 6 permet d'annuler l'application d'un correctif zip précédemment appliqué, via l'interface CLI ou par la console de gestion.
Avertissement
Important
Pré-requis
- Un correctif ayant déjà été appliqué par le système de gestion des correctifs de JBoss EAP 6.
- Accédez à l'interface CLI ou à la console de gestion pour le serveur de JBoss EAP 6. Voir la section Launch the Management CLI ou Log in to the Management Console du guide Administration and Configuration Guide.
Avertissement
Reset Configuration
.
TRUE
, en retirant le correctif, vous restaurerez également les fichiers de configuration du serveur JBoss EAP 6 à leur état d'avant correctif. Tout changement qui aura lieu sur les fichiers de configuration du serveur JBoss EAP 6 à la suite de ce correctif sera perdu.
FALSE
, les fichiers de configuration ne seront pas supprimés. Dans un tel cas, il est possible que le serveur ne démarre pas à nouveau après l'opération de restauration, car il y a pu avoir des altérations de configuration comme des altérations d'espace-nom, qui ne seront plus valides et qui devront être réparées manuellement.
Procédure 9.4. Supprimer un correctif zip à une instance de serveur JBoss EAP 6 par l'interface de gestion CLI
- Avec l'interface CLI, appliquez la commande
patch info
pour trouver l'ID du patch à retirer.- Avec les correctifs cumulatifs, l'ID du correctif correspond à la première valeur
cumulative-patch-id
qui apparaît dans la sortiepatch info
. - Les ID de correctifs de bogues ou de sécurité spontanés sont listés comme valeur des premiers
patches
(correctifs) qui apparaissent dans la sortiepatch info
, avec le correctif spontané listé en premier.
- Avec l'interface CLI, retirez le correctif avec l'ID de correctif de l'étape précédente.
[standalone@localhost:9999 /]
patch rollback --patch-id=PATCH_ID --reset-configuration=TRUE
L'outilpatch
avertira s'il y a conflit pour la tentative de suppression de correctif. Consultez Section 9.4.1, « Le Patch Management System (système de gestion des correctifs) » pour voir les options disponibles d'exécution à nouveau de la commandepatch
pour résoudre les conflits. - Démarrez à nouveau le serveur JBoss EAP 6 pour que la suppression de correctif puisse prendre effet :
[standalone@localhost:9999 /]
shutdown --restart=true
Procédure 9.5. Supprimer un correctif zip à une instance de serveur JBoss EAP 6 par la console de gestion.
- Dans la console de gestion :
- Pour un serveur autonome : cliquez sur l'onglet Runtime (exécution) en haut de l'écran, puis cliquez sur Patch Management (gestion des correctifs).
- Pour un domaine géré : cliquez sur l'onglet Domain en haut de l'écran, puis sélectionnez l'hôte qui convient sur le menu déroulant Host (hôte), puis cliquez sur Patch Management (gestion des correctifs).
- Dans le tableau Recent Patch History (historique récent des correctifs), sélectionnez le correctif que vous souhaitez supprimer, puis cliquez sur Rollback.
- Pour un hôte de domaine géré, sélectionnez si vous devez arrêter des serveurs sur l'hôte, sur le prochain écran, puis cliquez sur Next (suite).
- Sélectionner vos options pour le processus de suppression, puis cliquez sur Next.
- Confirmez vos options et le correctif à supprimer, puis cliquez sur Next.
- Si l'option Override all n'est pas sélectionnée, et qu'il n'y a pas de conflit lors du processus d'application du correctif, un message d'avertissement s'affichera. Cliquez sur View error details pour voir le détail des conflits. S'il y a un conflit, vous pouvez annuler l'opération, ou bien, cliquez sur Choose Options et essayez l'opération à nouveau avec la case Override all sélectionnée. La suppression des conflits se traduira par l'annulation du correctif prévalant sur toute modification de l'utilisateur.
- Une fois que le correctif aura été supprimé, sélectionnez s'il faut redémarrer le serveur JBoss EAP 6 dès maintenant pour que les changements prennent effet, puis cliquez sur Finish.
Le correctif, et parfois aussi les fichiers de configuration du serveur sont retirés de l'instance de serveur de JBoss EAP 6.
9.5. Correctifs d'installation RPM
Les correctifs 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 d'installation des correctifs en format RPM.
Pré-requis
- Un abonnement RHN valide.
- Un abonnement en cours à un produit JBoss installé via un package RPM.
Procédure 9.6. Appliquer un correctif à un produit JBoss via méthode RPM
yum
.
Avertissement
- Recevez vos notifications de correctifs de sécurité, soit en tant qu'abonné de la liste de diffusion JBoss watch, ou bien en parcourant les archives de la liste de diffusion de JBoss watch.
- Lire l'errata du correctif de sécurité et confirmez 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
pour installer le correctif.yum update
Important
Quand vous mettez une installation RPM à jour, votre produit JBoss sera mis à jour de façon cumulative avec tous les correctifs sortis-RPM.
Le produit JBoss est corrigé par la dernière mise à jour en format RPM.
9.6. Évaluation de la gravité et de l'impact des correctifs JBoss Security
Tableau 9.2. Système d'évaluation de gravité de JBoss Security Patches (correctifs de JBoss Security)
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é pouvant être exploités par des vers informatiques. Il s'agit de failles nécessitant un utilisateur distant authentifié, un utilisateur local ou une configuration peu probable et elles ne sont pas classées comme ayant un 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é 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é 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é qui semblent liés à des circonstances improbables pour pouvoir être exploitées, ou dans les cas où l'exploitation de la faille puisse avoir des conséquences minimes.
|
Exemple 9.1. Score d'impact CVSS v2
C:N/I:P/A:C
9.7. Gérer les mises à jour de sécurité pour les dépendances groupées au sein d'applications déployées dans JBoss EAP
Outils et Sources de données
- Listes de diffusion pour le patch JBoss
- S'abonner aux listes de diffusion de patch de JBoss vous tiendra informé au sujet des failles de sécurité qui ont été corrigées dans les produits JBoss, et vous permettra de vérifier si vos applications déployées regroupent des versions vulnérables des composants concernés.
- Page consultative de sécurité pour les composants regroupés.
- De nombreux composants open source ont leur propre page consultative de sécurité. Par exemple, Struts 2 est un composant couramment utilisé pour de nombreux problèmes de sécurité connus, qui n'est pas fourni dans la distribution de JBoss EAP. Le projet Struts 2 tient à jour une page consultative de sécurité en amont, qui doit être surveillée si vos applications déployées sont regroupées avec Struts 2. De nombreux composants fournis commercialement maintiennent également des pages consultatives de sécurité.
- Scannez régulièrement votre applications déployées pour les vulnerabilités connues
- Il existe plusieurs outils commerciaux disponibles pour ce faire. Il y a également un outil open source appelé Victims, qui est développé par les employés de Red Hat, mais qui est livré sans appui, ni garantie. Victims fournit des plugins pour plusieurs outils de génération et d'intégration, qui analysent automatiquement les applications pour les regroupements connus pour leur vulnérabilité aux dépendances. Il existe des plugins Maven, Ant et Jenkins. Pour plus d'informations sur l'outil Victims, voir https://victi.ms/about.html.
Voir également :
Partie III. Développement d'applications sécurisées
Chapitre 10. Aperçu Sécurité
10.1. La sécurité des applications
10.2. Sécurité déclarative
10.2.1. Sécurité déclarative Java EE
ejb-jar.xml
et web.xml
.
10.2.2. Références de sécurité

Figure 10.1. Modèle de référence de rôles de sécurité
role-nameType
de l'élément <role-name> comme argument de la méthode isCallerInRole(String)
. En utilisant la méthode isCallerInRole
, un composant est en mesure de vérifier si l'invocateur est dans un rôle qui a été déclaré avec un élément <security-role-ref> ou <role-name>. La valeur de l'élément <role-name> doit être reliée à un élément <security-role> par l'élément <role-link>. L'utilisation typique de isCallerInRole
est de procéder à un contrôle de sécurité qui ne puisse pas être défini en utilisant les éléments <method-permissions> basé-rôle.
Exemple 10.1. fragment de descripteur ejb-jar.xml
<!-- A sample ejb-jar.xml fragment --> <ejb-jar> <enterprise-beans> <session> <ejb-name>ASessionBean</ejb-name> ... <security-role-ref> <role-name>TheRoleICheck<role-name> <role-link>TheApplicationRole</role-link> </security-role-ref> </session> </enterprise-beans> ... </ejb-jar>
Note
Exemple 10.2. fragment de descripteur web.xml
<web-app> <servlet> <servlet-name>AServlet</servlet-name> ... <security-role-ref> <role-name>TheServletRole</role-name> <role-link>TheApplicationRole</role-link> </security-role-ref> </servlet> ... </web-app>
10.2.3. Identité Sécurité

Figure 10.2. Modèle Java EE Security Identity Data Model
EJBContext.getCallerPrincipal()
. À la place, les rôles de sécurité de l'appelant sont définis par l'élément <run-as> ou <role-name>.
<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> </enterprise-beans> <!-- ... --> </ejb-jar>
anonymous
est attribué à tous les appels sortants. Si vous voulez un autre principal à associer à l'appel, vous devez associer un <run-as-principal> au bean du fichier jboss-ejb3.xml
. Le fragment suivant associe un principal nommé internal
avec RunAsBean
de l'exemple précédent.
<session> <ejb-name>RunAsBean</ejb-name> <security-identity> <run-as-principal>internal</run-as-principal> </security-identity> </session>
web.xml
. L'exemple suivant montre comment assigner le rôle InternalRole
à un servlet :
<servlet> <servlet-name>AServlet</servlet-name> <!-- ... --> <run-as> <role-name>InternalRole</role-name> </run-as> </servlet>
principal
«anonymous». L'élément <run-as-principal> se trouve dans le fichier jboss-web.xml
pour assigner un principal spécifique qui puisse correspondre à un rôle run-as
. Le fragment suivant montre comment associer un principal nommé internal
au serveur ci-dessus.
<servlet> <servlet-name>AServlet</servlet-name> <run-as-principal>internal</run-as-principal> </servlet>
10.2.4. Rôles de sécurité
security-role-ref
ou élément de security-identity
doit mapper à un des rôles déclarés de l'application. Un assembleur d'applications définit les rôles de sécurité logique en déclarant les éléments security-role
. La valeur de role-name
est un nom de rôle d'application logique comme Administrateur, Architecte, ResponsableVentes, etc.
security-role
est seulement utilisé pour mapper les valeurs de security-role-ref/role-name
au rôle logique qui fait référence au rôle du composant. Les rôles assignés à l'utilisateur représentent une fonction dynamique du gestionnaire de sécurité de l'application. JBoss n'a as besoin de la définition des éléments de security-role
pour déclarer des permissions de méthode. Toutefois, la spécification d'éléments de security-role
est toujours une pratique conseillée pour assurer la portabilité entre les serveurs d'applications et la maintenance du descripteur de déploiement.
Exemple 10.3. Un fragment de descripteur ejb-jar.xml qui illustre l'utilisation de l'élément security-role.
<!-- A sample ejb-jar.xml fragment --> <ejb-jar> <assembly-descriptor> <security-role> <description>The single application role</description> <role-name>TheApplicationRole</role-name> </security-role> </assembly-descriptor> </ejb-jar>
Exemple 10.4. Un exemple web.xml qui illustre l'utilisation de l'élément security-role.
<!-- A sample web.xml fragment --> <web-app> <security-role> <description>The single application role</description> <role-name>TheApplicationRole</role-name> </security-role> </web-app>
10.2.5. Permissions de méthodes EJB

Figure 10.3. Élément de Permission de méthode Java EE
method-permission
contient un ou plusieurs éléments enfants role-name qui définissent les rôles logiques autorisés à accéder aux méthodes EJB identifiées par les éléments enfants de la méthode. Vous pouvez également spécifier un élément unchecked
à la place de l'élément role-name
pour déclarer que tout utilisateur authentifié peut accéder aux méthodes identifiées par les éléments enfants de méthode. De plus, vous pouvez déclarer que personne ne devrait avoir accès à une méthode qui comporte l'élément de la exclude-list
(liste d'exclusion). Si un EJB a des méthodes qui n'ont pas été déclarées comme accessibles par un rôle à l'aide d'un élément de method-permission
, la valeur par défaut des méthodes EJB sera exclusion d'utilisation. Cela revient à rendre les méthodes par défaut à exclude-list
.

Figure 10.4. Élément de méthode Java EE
<method> <ejb-name>EJBNAME</ejb-name> <method-name>*</method-name> </method>
<method> <ejb-name>EJBNAME</ejb-name> <method-name>METHOD</method-name> </method>
<method> <ejb-name>EJBNAME</ejb-name> <method-name>METHOD</method-name> <method-params> <method-param>PARAMETER_1</method-param> <!-- ... --> <method-param>PARAMETER_N</method-param> </method-params> </method>
method-intf
peut être utilisé pour différencier des méthodes qui ont le même nom ou signature définis à la fois dans les interfaces d'accueil ou éloignées d'un bean enterprise.
method-permission
.
Exemple 10.5. Un fragment de descripteur ejb-jar.xml qui illustre l'utilisation de l'élément 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 AardvarkPayroll bean </description> <role-name>employee</role-name> <method> <ejb-name>AardvarkPayroll</ejb-name> <method-name>findByPrimaryKey</method-name> </method> <method> <ejb-name>AardvarkPayroll</ejb-name> <method-name>getEmployeeInfo</method-name> </method> <method> <ejb-name>AardvarkPayroll</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>
10.2.6. Annotations de sécurité de Beans Enterprise
@DeclareRoles
- Déclare chaque rôle de sécurité déclaré dans le code. Pour plus d'informations sur la configuration des rôles, voir Java EE 6 Tutorial Specifying Authorized Users by Declaring Security Roles.
@RolesAllowed
,@PermitAll
, and@DenyAll
- Indique les permissions de méthodes pour les annotations. Pour plus d'informations sur la configuration des permissions de méthodes d'annotations, voir Java EE 56 Tutorial Specifying Authorized Users by Declaring Security Roles.
@RunAs
- Configure l'identité de sécurité propagée d'un composant. Pour plus d'informations sur la façon de configurer les identités de sécurité propagées par des annotations, voir Java EE 6 Tutorial Propagating a Security Identity (Run-As).
10.2.7. Contraintes de sécurité de contenu web
web.xml
security-constraint.

Figure 10.5. Contraintes de sécurité de contenu web
NONE
, INTEGRAL
, et CONFIDENTIAL
. Une valeur NONE
signifie que l'application n'a pas besoin de garantie de transport. Une valeur INTEGRAL
signifie que l'application requiert que les données envoyées entre le client et le serveur soient envoyées de telle sorte qu'elles ne puissent pas être modifiées en transit. Une valeur CONFIDENTIAL
signifie que l'application requiert que les données soient transmises d'une manière qui empêche les autres entités d'observer le contenu de la transmission. Dans la plupart des cas, la présence de INTEGRAL
ou CONFIDENTIAL
indique qu'il faut utiliser SSL.

Figure 10.6. Configuration de connexion web
BASIC
, DIGEST
, FORM
, SPNEGO
, et CLIENT-CERT
. L'élément enfant <realm-name> spécifie le nom de domaine à utiliser en HTTP de base et l'autorisation digest. L'élément enfant <form-login-config> spécifie le log in et les pages d'erreur devant être utilisées pour le log in basé-formulaire. Si la valeur <auth-method> n'est pas FORM
, alors form-login-config
et ses éléments enfants seront ignorés.
/restriction
de l'application web requiert un rôle AuthorizedUser
. Il n'y a aucune garantie de transport nécessaire et la méthode d'authentification utilisée pour obtenir l'identité de l'utilisateur est l'authentification HTTP BASIC.
Exemple 10.6. Fragment de descripteur web.xml
<web-app> <security-constraint> <web-resource-collection> <web-resource-name>Secure Content</web-resource-name> <url-pattern>/restricted/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>AuthorizedUser</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <!-- ... --> <login-config> <auth-method>BASIC</auth-method> <realm-name>The Restricted Zone</realm-name> </login-config> <!-- ... --> <security-role> <description>The role required to access restricted content </description> <role-name>AuthorizedUser</role-name> </security-role> </web-app>
10.2.8. Activer l'authentification basée formulaire
<auth-method>FORM</auth-method>
dans l'élément <login-config> du descripteur de déploiement, web.xml
. La connexion et les pages d'erreur sont également définies dans <login-config>, comme suit :
<login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.html</form-login-page> <form-error-page>/error.html</form-error-page> </form-login-config> </login-config>
FormAuthenticator
pour diriger les utilisateurs vers la page appropriée. JBoss EAP gère un pool de session afin que les informations d'authentification n'aient pas besoin d'être présentes pour chaque demande. Lorsque FormAuthenticator
reçoit une demande, il interroge org.apache.catalina.session.Manager
pour savoir s'il y a une session existante. Si aucune session n'existe, une nouvelle session sera créée. FormAuthenticator
vérifie alors les informations d'identification de la session.
Note
/dev/urandom
(Linux) par défaut et hachées avec MD5. Les vérifications sont effectuées lors de la création de l'ID de session pour s'assurer que l'ID créé soit unique.
JSESSIONID
. Sa valeur est une chaîne hexadécimale de l'ID de session. Ce cookie est configuré pour être non persistant. Cela signifie que du côté client, il sera supprimé lorsque le navigateur se fermera. Côté serveur, les sessions expirent après 30 minutes d'inactivité, quand les objets session et leurs informations d'identification seront supprimés.
FormAuthenticator
met en cache la demande, crée une nouvelle session si nécessaire et redirige l'utilisateur vers la page de connexion définie dans login-config
. Dans l'exemple de code précédent, la page de connexion est login.html
. L'utilisateur entre alors son nom d'utilisateur et son mot de passe dans le formulaire HTML fourni. Les nom d'utilisateur et mot de passe sont passés à FormAuthenticator
par l'intermédiaire de l'action de formulaire j_security_check
.
FormAuthenticator
authentifie alors le nom d'utilisateur et le mot de passe par rapport au domaine attaché au contexte de l'application web. Dans JBoss Enterprise Application Platform, le domaine est JBossWebRealm
. Lorsque l'authentification réussit, FormAuthenticator
récupère la requête enregistrée à partir du cache et redirige l'utilisateur vers sa requête initiale.
Note
/j_security_check
et que les paramètres j_username
et j_password
existent.
10.2.9. Activation de la Sécurité déclarative
Voir également :
Chapitre 11. Sécurité des applications
11.1. Sécurité des bases de données
11.1.1. Sécurité des bases de données
- Domaines de sécurité : Section 12.3.3.1, « Les domaines de sécurité ».
- Mots de passe : Section 7.1, « Système d'archivage sécurisé de mots de passe ».
Exemple 11.1. Exemple de domaine de sécurité
<security-domain name="DsRealm" cache-type="default"> <authentication> <login-module code="ConfiguredIdentity" flag="required"> <module-option name="userName" value="sa"/> <module-option name="principal" value="sa"/> <module-option name="password" value="sa"/> </login-module> </authentication> </security-domain>
<datasources> <datasource jndi-name="java:jboss/datasources/securityDs" pool-name="securityDs"> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url> <driver>h2</driver> <new-connection-sql>select current_user()</new-connection-sql> <security> <security-domain>DsRealm</security-domain> </security> </datasource> </datasources>
Exemple 11.2. Exemple de mots de passe
<security> <user-name>admin</user-name> <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password> </security>
11.2. Sécurité des applications EJB
11.2.1. Identité Sécurité
11.2.1.1. L'identité de sécurité EJB
11.2.1.2. Définir l'identité de sécurité d'un EJB
<security-identity>
dans la configuration de la sécurité.
<security-identity>
n'est présente - l'identité de l'appelant de l'EJB sera utilisée.
Exemple 11.3. Définir l'identité de sécurité d'un EJB pour que ce soit la même que celle de l'appelant
<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 11.4. Définir l'idendité de sécurité d'un EJB à un rôle spécifique
<run-as>
et les balises <role-name>
dans 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>
<run-as>
, un principal nommé anonymous
est assigné aux appels sortants. 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
<run-as>
et <run-as-principal>
à l'intérieur d'un élément de servlet.
Voir également :
11.2.2. Permissions de méthodes EJB
11.2.2.1. Permissions de méthodes EJB
<method-permisison>
définit les rôles qui peuvent 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é
11.2.2.2. Utilisation des permissions de méthodes EJB
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>
.
Exemple 11.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 11.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 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>
Exemple 11.7. Permet à n'importe quel utilisateur authentifié d'accéder aux méthodes des EJB
<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 11.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 11.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>
11.2.3. Annotations de sécurité EJB
11.2.3.1. Les annotations de sécurité EJB
javax.annotation.security
sont définies dans JSR250.
- @DeclareRoles
- Déclare quels rôles sont disponibles.
- @RunAs
- Configure l'identification de sécurité propagée d'un composant.
11.2.3.2. Utilisation des annotations de sécurité EJB
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 11.2.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éfinir dans quels rôles vérifier les permissions. Si aucun @DeclareRoles n'est présent, la liste sera créée automatiquement avec l'annotation @RolesAllowed. Pour plus d'informations sur la configuration des rôles, voir Java EE 6 Tutorial Specifying Authorized Users by Declaring Security Roles.
- @RolesAllowed, @PermitAll, @DenyAll
- Utiliser
@RolesAllowed
pour lister les rôles qui peuvent accéder à une méthode ou à des méthodes. Utiliser@PermitAll
ou@DenyAll
pour autoriser ou empêcher à des rôles d'utiliser une méthode ou des méthodes. Pour plus d'informations sur la configuration des permissions de méthode d'annotation, consultez Java EE 6 Tutorial Specifying Authorized Users by Declaring Security Roles. - @RunAs
- Utiliser
@RunAs
pour spécifier un rôle utilisé par une méthode quand elle lance des appels à partir d'une méthode annotée. Pour plus d'informations sur la façon de configurer les identités de sécurité propagées par des annotations, voir Java EE 6 Tutorial Propagating a Security Identity (Run-As).
Exemple 11.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 GoodbyeAdmin(String msg) { return "See you later, " + msg; } }
WelcomeEveryone
. La méthode GoodBye
exécute sous la forme du rôle tempemployee
pour les appels. Seul le rôle admin
peut accéder à la méthode GoodbyeAdmin
, ou à toute autre méthode sans annotation de sécurité.
11.2.4. Accès à distance aux EJB
11.2.4.1. Remote Method Access
Types de services pris en charge
- Socket / Secure Socket
- RMI / RMI sur SSL
- HTTP / HTTPS
- Servlet / Secure Servlet
- Bisocket / Secure Bisocket
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.
Lorsque vous créez une application cliente qui utilise Remoting, vous indiquez à votre application de communiquer 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.
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.
11.2.4.2. Remoting Callbacks
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 que le client a demandé. C'est peut-être une réponse directe à une demande ou à une notification d'événement.
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.
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».
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()
.
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
.
11.2.4.3. Remoting Server Detection
11.2.4.4. Configurer le sous-système de JBoss Remoting
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 liens 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
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.
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
remoting
est l'interfaceunsecure
définie dansdomain/configuration/domain.xml
ou dansstandalone/configuration/standalone.xml
.<interfaces> <interface name="management"/> <interface name="public"/> <interface name="unsecure"/> </interfaces>
La définition par-hôte de l'interfaceunsecure
est définie danshost.xml
dans le même répertoire quedomain.xml
oustandalone.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
remoting
se lie au port TCP 4777. Reportez-vous à la documentation sur les liaisons de socket et de groupes de liaisons de 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 EAP 6 qui utilisent Remoting, tels que les fournisseur JMS, EJB et ORB exigent des interfaces sécurisées par défaut.
Avertissement
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 11.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)
|
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 EAP 6. 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 11.2. Attributs de connecteur
Attribut | Description | Commande CLI |
---|---|---|
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 EAP 6 par défaut.
| /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=security-realm,value=ApplicationRealm)
|
Tableau 11.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
|
propriétés |
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)
|
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é.
<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é) pour l'autorisation.
Tableau 11.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 un domaine de sécurité.
| /profile=default/subsystem=remoting/remote-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting,username=myUser,security-realm=ApplicationRealm)
|
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
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.
|
/profile=default/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-anonymous,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) |
propriétés |
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 11.11. Exemples de configurations
<subsystem xmlns="urn:jboss:domain:remoting:1.1"> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/> </subsystem>
<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="http://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
11.2.4.5. Utilisation des domaines de sécurité avec les clients EJB distants
- Ajoutez un nouveau domaine de sécurité au contrôleur 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éfaut
par les autres paramètres qui se trouvent dans le fichier.remote.connection.default.username=appuser remote.connection.default.password=apppassword
- Créez un connecteur Remoting personnalisé sur le domaine ou sur le serveur autonome qui utilise le nouveau domaine de sécurité.
- Déployez 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é.
11.2.4.6. Ajout d'un domaine de sécurité
Exécuter l'interface CLI
Démarrez par la commandejboss-cli.sh
oujboss-cli.bat
et 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éMyDomainRealm
sur 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écutez 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.sh
etadd-user.bat
inclus. Il devra être administré en externe./host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
Votre nouveau domaine de sécurité sera 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.
11.2.4.7. Ajout d'un utilisateur à un domaine de sécurité
Éxécuter la commande
add-user.sh
ouadd-user.bat
.Ouvrez un terminal (shell) et 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
.Choisir d'ajouter un utilisateur de gestion ou un utilisateur d'application.
Pour cette procédure, saisirb
pour 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
, ouno
pour annuler les changements. Les changements sont inscrits dans les fichiers de propriétés du domaine de sécurité.
11.2.4.8. Accès EJB à distance utilisant le cryptage SSL
11.3. Sécurité des applications JAX-RS
11.3.1. Activez la sécurité basée-rôle pour RESTEasy JAX-RS Web Service
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
Procédure 11.1. Activez la sécurité basée-rôle pour RESTEasy JAX-RS Web Service
- Ouvrir le fichier
web.xml
de l'application dans un éditeur de texte. - Ajoutez 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éclarez 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>
- Autorisez 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>
La sécurité basée rôle à été activée dans l'application, avec un certain nombre de rôles définis.
Exemple 11.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>
11.3.2. Sécuriser un service JAX-RS Web par des annotations
Cette rubrique couvre les étapes à parcourir pour sécuriser un service JAX-RS Web par les annotations de sécurité supportées.
Procédure 11.2. Sécuriser un service JAX-RS Web par des annotations de sécurité supportées.
- Activez la sécurité basée-rôle. Pour plus d'informations, voir Section 11.3.1, « Activez la sécurité basée-rôle pour RESTEasy JAX-RS Web Service ».
- Ajoutez 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.
Chapitre 12. Le sous-système de sécurité
12.1. La sécurité du sous-système
sécurité
fournit l'infrastructure de sécurité pour les applications. Le sous-système utilise un contexte de sécurité associé à la demande en cours pour exposer les fonctionnalités du gestionnaire d'authentification, du gestionnaire d'autorisations, du gestionnaire d'auditing et du gestionnaire de mappage (mises en correspondance) pour le conteneur approprié.
security
est préconfiguré par défaut, donc les éléments de sécurité ont rarement besoin d'être changés. Le seul élément de sécurité qui ait besoin d'être changé est pour savoir si on doit utiliser deep-copy-subject-mode. Dans la plupart des cas, les administrateurs se concentreront sur la configuration des security domains.
Voir Section 12.3.2.1, « Mode de sujet Deep Copy » pour obtenir des détails supplémentaires sur le mode de sujet Deep Copy.
Un domaine de sécurité est un ensemble de configurations 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 et le mapping. 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. Voir Section 13.9, « Utiliser un domaine de sécurité dans votre application » pour obtenir des détails sur le domaine de sécurité.
12.2. Structure du sous-système de sécurité
Exemple 12.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>
<security-management>
, <subject-factory>
et <security-properties>
ne sont pas présents dans la configuration par défaut. Les éléments <subject-factory>
et <security-properties>
ont été désapprouvés sur JBoss EAP 6.1 et versions ultérieures.
12.3. Configurer le sous-système de sécurité
12.3.1. Configurer le sous-système de sécurité
- <security-management>
- Cette section remplace les comportements 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 Indique si l'on doit copier ou lier les tokens de sécurité pour la sécurité des threads.authentication-manager-class-name Indique un nom de classe d'implémentation AthentificationManager alternatif à utiliser.authorization-manager-class-name Indique un nom de classe d'implémentation AthorizationManager alternatif à utiliser.audit-manager-class-name Indique un nom de classe d'implémentation Audit Manager alternatif à utiliser.identity-trust-manager-class-name Indique un nom de classe d'implémentation IdentityTrustManager alternatif à utiliser.mapping-manager-class-name Indique le nom de classe d'implémentation MappingManager à utiliser. - <subject-factory>
- La fabrique 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 la fabrique 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
12.3.2. Gestion de la sécurité
12.3.2.1. Mode de sujet Deep Copy
12.3.2.2. Activer le Mode de sujet Deep Copy
Procédure 12.1. Activez le mode de sécurité Deep Copy à partir de la console de gestion
Connectez-vous à la console de management.
Pour obtenir plus d'informations, voir la section intitulée The Management Console dans le guide Administration and Configuration Guide de la plateforme JBoss Enterprise Application 6.x qui se situe sur le portail clients à l'adresse suivante https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.Domaine géré : sélectionnez le profil qui convient.
Dans un domaine géré, le sous-système de sécurité est configuré par profil, ou vous pouvez activer ou désactiver le mode de sécurité Deep Copy de manière indépendante dans chaque profil.Pour sélectionner un profil, cliquez sur Configuration en haut et à droite de l'écran, puis sélectionnez un profil à partir du menu déroulant Profile en haut et à gauche.Ouvrir le menu de configuration Security Subsystem.
Étendre l'item de menu Security, puis cliquez sur le lien Security Subsystem.Activez le mode Deep Copy Subject.
Cliquez sur Edit. Cochez la case qui se trouve à côté de Deep Copy Subjects pour activer le mode Copier Sujet (copy subject).
Si vous préférez utiliser l'interface CLI pour activer cette option, utilisez une des commandes suivantes.
Exemple 12.2. Domaine géré
/profile=full/subsystem=security/:write-attribute(name=deep-copy-subject-mode,value=TRUE)
Exemple 12.3. Serveur autonome
/subsystem=security/:write-attribute(name=deep-copy-subject-mode,value=TRUE)
12.3.3. Domaines de sécurité
12.3.3.1. Les domaines de sécurité
12.3.3.2. Opérations de CLI liées aux domaines de sécurité
Exemple 12.4. flush-cache
/subsystem=security/security-domain=other:read-operation-description(name=flush-cache)
Exemple 12.5. list-cached-principals
/subsystem=security/security-domain=other:read-operation-description(name=list-cached-principals)
Chapitre 13. Authentification et Autorisation
13.1. Intégration Kerberos et SPNEGO
13.1.1. Intégration Kerberos et SPNEGO
Dans une installation normale, l'utilisateur se connecte à un ordinateur de bureau qui est régi par le domaine Active Directory. L'utilisateur utilise ensuite le navigateur web, Firefox ou Internet Explorer pour accéder à une application web qui utilise la négociation de JBoss Negociation sur JBoss EAP. Le navigateur web transfère l'information de sign on de bureau à l'application web. JBoss EAP utilise les messages GSS d'arrière-plan avec Active Directory ou n'importe quel serveur Kerberos pour valider l'utilisateur. Cela permet à l'utilisateur d"effectuer un SSO sans faille dans l'application web
13.1.2. Desktop SSO using SPNEGO
- Domaine de sécurité
- Propriétés système
- Application Web
Procédure 13.1. Configurer Desktop SSO utilisant SPNEGO
Configurer Domaine de sécurité
Configurer les domaines de sécurité pour qu'il représentent l'identité du serveur et pour sécuriser l'application web.Exemple 13.1. Configuration du domaine de sécurité
<security-domains> <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> <security-domain name="SPNEGO" cache-type="default"> <authentication> <login-module code="SPNEGO" flag="requisite"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="host"/> </login-module> <!-- Login Module For Roles Search --> </security-domain>
Configuration des propriétés système
Si nécessaire, les propriétés système peuvent être configurées dans le modèle de domaine.Exemple 13.2. Configurer les propriétés système
<system-properties> <property name="java.security.krb5.kdc" value="mykdc.mydomain"/> <property name="java.security.krb5.realm" value="MY_REALM"/> </system-properties>
Configurer Application Web
Il n'est pas possible de remplacer les authentificateurs, mais il est possible d'ajouter leNegotiationAuthenticator
comme valve à votre jboss-web.xml pour configurer l'application web.Note
La valve a besoin d'avoirsecurity-constraint
etlogin-config
définis dans le fichier web.xml car c'est utilisé pour décider quelles sources sont sécurisées. Cependant, l'auth-method
est remplacée par cet authenticateur.Exemple 13.3. Configurer Application Web
<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.4//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd"> <jboss-web> <security-domain>SPNEGO</security-domain> <valve> <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> </valve> </jboss-web>
L'application web exige aussi qu'une dépendance soit définie dansMETA-INF/MANIFEST.MF
pour trouver les classes de JBoss Negotiation.Exemple 13.4. Définir la dépendance dans
META-INF/MANIFEST.MF
Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.jboss.security.negotiation
13.1.3. Configurer JBoss Negociation sur un domaine Microsoft Windows.
{hostname}
, {realm}
, le domaine {domain}
et le serveur hébergeant l'instance de JBoss EAP est dénommé {machine_name}
.
Procédure 13.2. Configurer JBoss Negociation sur un domaine Microsoft Windows.
Supprimer les mappages principaux du service existant
Dans un réseau Microsoft Windows, certains mappages sont créés automatiquement. Supprimez les mappages créés automatiquement pour mapper l'identité du serveur avec le service principal pour que la négociation se déroule correctement. Le mappage permet au navigateur web de l'ordinateur client de faire confiance au serveur et d'essayer SPNEGO. L'ordinateur client vérifie avec le contrôleur de domaine un mappage de la formeHTTP {hostname}
Voici les étapes nécessaires pour supprimer les mappages existants :- Listez les mappages enregistrés dans le domaine de l'ordinateur qui utilise la commande
setspn -L {machine_name}
. - Supprimez les mappages existants par les commandes,
setspn -D HTTP/{hostname} {machine_name}
etsetspn -D host/{hostname} {machine_name}
.
- Créez un compte d'utilisateur hôte.
Note
Veillez à ce que le nom d'utilisateur hôte soit différent de{machine_name}
.Dans le reste de la section, le nom d'utilisateur hôte est{user_name}
. Définir le mappage entre
{user_name}
et{hostname}
.- Exécutez la commande suivante pour configurer le mappage pricipal du service,
ktpass -princ HTTP/{hostname}@{realm} -pass * -mapuser {domain}\{user_name}
. - Saisir le mot de passe du nom d'utilisateur quand vous y serez invité.
Note
Réinitialisez le mot de passe de l'utilisateur comme prérequis d'exportation du keytab. - Vérifiez le mappage en exécutant la commande suivante,
setspn -L {user_name}
Exportez le keytab de l'utilisateur dans le serveur sur lequel EAP est installé.
Exécutez la commande suivante pour exporter le keytab,ktab -k service.keytab -a HTTP/{hostname}@{realm}
.Note
Cette commande exporte le ticket duHTTP/{hostname} principal dans le fichier keytabservice.keytab
, qui est utilisé pour configurer le domaine de sécurité hôte sur JBoss.- Définir le principal dans le domaine de sécurité comme suit :
<module-option name="principal">HTTP/{hostname}@{realm}</module-option>
13.1.4. Authentifiction Kerberos pour IDP PicketLink
Procédure 13.3. Installez JBoss EAP 6 et configurer Kerberos
- Télécharger et installer JBoss EAP 6. Voir les instructions dans Installation Guide.
- Que vous utilisiez Oracle Java ou IBM Java, utilisez JCE illimité. Sans JCE illimité, le serveur JBoss ne peut pas négocier sur un type de mécanisme SPNEGO qui convient (en utilisant 1.3.6.1.5.2.5, qui est
GSS_IAKERB_MECHANISM
). - Utilisez l'exemple ci-dessous pour configurer JBoss à utiliser la version Java qui vous convienne.
export JAVA_HOME=JDK/JRE_directory
Procédure 13.4. Tester votre installation Kerberos avec le JBoss Negotiation Toolkit
- Utiliser le JBoss Negotiation Toolkit se trouvant Github
- Modifier les fichiers de configuration et utiliser la commande
mvn clean install
pour créer le projet. - Copier le fichier
jboss-negotiation-toolkit/target/jboss-negotiation-toolkit.war
dans$JBOSS_HOME/standalone/deployments/
. - Vérifier que les trois sections passent par le JBoss Negotiation Toolkit
Procédure 13.5. Configurer PicketLink IDP
idp.war
L'exemple fourni utilise les archives idp.war
et employee.war
, qui se trouvent dans le référentiel PicketLink Quickstarts. Modifier les fichiers dans idp.war
comme décrit ci-dessous.
- Ajouter le module
org.jboss.security.negotiation
à$JBOSS_HOME/standalone/deployments/idp.war/META-INF/jboss-deployment-structure.xml
car IDP utilise le module JBoss Negotiation.<jboss-deployment-structure> <deployment> <!-- Add picketlink module dependency --> <dependencies> <module name="org.picketlink" /> <module name="org.jboss.security.negotiation" /> </dependencies> </deployment> </jboss-deployment-structure>
- Ajouter une valve supplémentaire
org.jboss.security.negotiation.NegotiationAuthenticator
à SPNEGO pour$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/jboss-web.xml
. - Modifier
security-domain
deidp
versSPNEGO
dans$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/jboss-web.xml
comme suit :<jboss-web> <security-domain>SPNEGO</security-domain> <context-root>idp</context-root> <valve> <class-name>org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve</class-name> <param> <param-name>passUserPrincipalToAttributeManager</param-name> <param-value>true</param-value> </param> </valve> <valve> <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> </valve> </jboss-web>
- Ajouter et modifier le security-role ajouté à votre principal par l'installatiion du serveur Kerberos en
$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/web.xml
. - Modifier le fichier
$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/picketlink.xml
comme suit :<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1"> <IdentityURL>${idp.url::http://localhost:8080/idp/}</IdentityURL> <Trust> <Domains>redhat.com,localhost,amazonaws.com</Domains> </Trust> </PicketLinkIDP> <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> </Handlers> <!-- The configuration bellow defines a token timeout and a clock skew. Both configurations will be used during the SAML Assertion creation. This configuration is optional. It is defined only to show you how to set the token timeout and clock skew configuration. --> <PicketLinkSTS xmlns="urn:picketlink:identity-federation:config:1.0" TokenTimeout="5000" ClockSkew="0"> <TokenProviders> <TokenProvider ProviderClass="org.picketlink.identity.federation.core.saml.v1.providers.SAML11AssertionTokenProvider" TokenType="urn:oasis:names:tc:SAML:1.0:assertion" TokenElement="Assertion" TokenElementNS="urn:oasis:names:tc:SAML:1.0:assertion" /> <TokenProvider ProviderClass="org.picketlink.identity.federation.core.saml.v2.providers.SAML20AssertionTokenProvider" TokenType="urn:oasis:names:tc:SAML:2.0:assertion" TokenElement="Assertion" TokenElementNS="urn:oasis:names:tc:SAML:2.0:assertion" /> </TokenProviders> </PicketLinkSTS> </PicketLink>
- Modifier
IdentityURL
pour qu'il corresponde au nom d'hôte du serveur sur lequel vous exécutez IDP. - Modifier
Trust
pour qu'il contienne les noms de domaine autorisés par le fournisseur d'identité. - Modifiez le
employee.war
. Ajoutez et modifiez le security-role ajouté à votre principal par l'installatiion du serveur Kerberos en$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/web.xml
. - Modifiez la configuration
security domain
dans le fichier$JBOSS_HOME/standalone/configuration/standalone.xml
. La configuration de mappage des rôles est la même que celle qui existe dans les configurations de domaine de sécurité.<security-domain name="host" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="principal" value="HTTP/something.com@yourdomain.COM"/> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="doNotPrompt" value="true"/> <module-option name="keyTab" value="/root/keytab"/> </login-module> </authentication> </security-domain> <security-domain name="SPNEGO" cache-type="default"> <authentication> <login-module code="SPNEGO" flag="required"> <module-option name="serverSecurityDomain" value="host"/> </login-module> </authentication> </security-domain> <security-domain name="sp" cache-type="default"> <authentication> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule" flag="required" /> </authentication> </security-domain>
Note
jboss.security.disable.secdomain.option
à true
. Voir Section 13.2.2, « Configurer l'authentification dans un domaine de sécurité » pour obtenir des détails supplémentaires. Mettre le module de connexion à jour ainsi :
<login-module code="Kerberos" flag="required"> <module-option name="principal" value="HTTP/something.com@yourdomain.COM"/> <module-option name="credsType" value="acceptor"/> <module-option name="useKeytab" value="file:///root/keytab"/> </login-module>
Procédure 13.6. Vérifiez la configuration d'authentification Kerberos dans PicketLink IDP
- Démarrez le serveur JBoss EAP par la commande
$JBOSS_HOME/bin/standalone.sh
. - Configurez votre navigateur, comme Firefox, pour qu'il utilise Kerberos. Suivre les instructions fournies ici : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/sso-config-firefox.html
- Vérifiez de pouvoir accéder à
http://YOUR_DOMAIN:8080/employee
à partir de Firefox configuré comme mentionné ci-dessus.
13.1.5. Se connecter par un certificat avec PicketLink IDP
Vous pouvez configurer IDP PicketLink pour prendre en charge SSL. La procédure suivante est un exemple qui montre comment configurer une application web en tant qu'IDP supportant l'authentification client SSL. Il y a deux façons de configurer l'IDP pour authentifier les utilisateurs :
- Si SSL est utilisé, le serveur demandera au client un certificat et utilisera ce certificat pour authentifier l'utilisateur.
- Si aucun certificat n'est fourni par le client, une authentification basée formulaire sera effectuée.
13.1.5.1. Configuration SSL JBoss EAP 6.3
Procédure 13.7. Créez le certificat, le keystore et le truststore pour votre serveur.
Créez un certificat pour votre serveur.
Utilisez la commande suivante pour créer un certificat pour votre serveur :keytool -genkey -alias server -keyalg RSA -keystore server.keystore -storepass change_it -validity 365
Le système vous demande des informations supplémentaires. Vous devez fournir les valeurs selon les besoins. Le nom CN du certificat doit être le même que le nom de votre serveur DNS. Par exemple, dans le cas de localhost, vous pouvez utiliser la commande suivante :keytool -genkey -alias server -keystore server.keystore -storepass change_it -keypass password -dname "CN=localhost,OU=QE,O=example.com,L=Brno,C=CZ"
Créez un certificat de client
Vous utiliserez ce certificat de client pour vous authentifier auprès du serveur quand vous accéderez à une ressource via SSL.keytool -genkey -alias client -keystore client.keystore -storepass change_it -validity 365 -keyalg RSA -keysize 2048 -storetype pkcs12
Créez le truststore
Exportez le certificat du client et créer un truststore en important ce certificat :keytool -exportcert -keystore client.keystore -storetype pkcs12 -storepass change_it -alias client -keypass change_it -file client.keystore keytool -import -file client.keystore -alias client -keystore client.truststore
Modifiez l'installation du serveur JBoss EAP 6.3 pour activer SSL
Ajoutez le connecteur suivant au sous-système web pour activer SSL :<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" enable-lookups="false" secure="true"> <ssl name="localhost-ssl" key-alias="server" password="change_it" certificate-key-file="${jboss.server.config.dir}/server.keystore" protocol="TLSv1" verify-client="want" ca-certificate-file="${jboss.server.config.dir}/client.truststore"/> </connector>
Relancez le serveur
Redémarrez le serveur et vérifiez qu'il répond sur : https://localhost:8443Acceptation du certificat
On vous invitera à approuver le certificat du serveur.
Avant d'accéder à l'application, vous devez importer le client.keystore
dans votre navigateur. Ce fichier contient le certificat client. Quand vous accédez à l'application, le navigateur vous invite à sélectionner le certificat dont vous avez besoin pour vous authentifier auprès du serveur. Sélectionnez le certificat désiré.
Ajoutez le domaine de sécurité à votre installation de serveur. Si vous êtes en mode autonome, vous devrez l'ajouter au JBOSS_HOME/standalone/configuration/standalone.xml
:
<security-domain name="idp" cache-type="default"> <authentication> <login-module code="CertificateRoles" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="securityDomain" value="idp"/> <module-option name="verifier" value="org.jboss.security.auth.certs.AnyCertVerifier"/> </login-module> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.RegExUserNameLoginModule" flag="optional"> <module-option name="regex" value="CN=(.*?),"/> </login-module> <login-module code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value="users.properties"/> <module-option name="rolesProperties" value="roles.properties"/> </login-module> </authentication> <jsse keystore-password="change_it" keystore-url="${jboss.server.config.dir}" truststore-password="change_it" truststore-url="${jboss.server.config.dir}" client-auth="true"/> </security-domain>L'exemple de configuration ci-dessus validifie tout certificat déjà fourni. Si aucun certificat n'est produit ou si l'authentification vient à échouer, la procédure revient à nouveau à l'authentification basée utilisateur/mot de passe.
Le module de connexion de nom d'utilisation d'expression régulière peut être utilisé à la suite des modules de connexion de certificats pour extraire un nom d'utilisateur, un UID ou un autre champ du nom de principal pour que les rôles puissent être obtenus à partir de LDAP. Le module contient une option nommée regex
qui spécifie l'expression régulière à appliquer au nom du principal. Le résultat est passé au module de connexion suivant.
UID=007, EMAILADDRESS=something@something, CN=James Bond, O=SpyAgency
aura pour résultat UID=007
.
Exemple 13.5. Exemple de module de connexion de nom d'utilisation d'expression régulière
<login-module code="org.picketlink.identity.federation.bindings.jboss.auth.RegExUserNameLoginModule" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="regex" value="UID=(.*?),"/> </login-module>
java.util.regex.Pattern
à l'adresse suivante http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html.
13.2. Authentification
13.2.1. Authentification
13.2.2. Configurer l'authentification dans un domaine de sécurité
Procédure 13.8. Configurez l'authentification dans un domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité.
- Cliquez sur l'étiquette Configuration qui se trouve en haut de la console de gestion.
- Sélectionnez le profil à modifier à partir du menu de sélection Profile qui se trouve en haut et à gauche de la vue 'Profile'.
- Étendre l'item de menu Security, puis sélectionnez Security Domains.
- Cliquez sur le lien View pour obtenir le domaine de sécurité que vous voulez modifier.
Naviguez dans la configuration du sous-système d'authentification.
Sélectionnez l'étiquette Authentification 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 : 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.Ajoutez un module de connexion
Cliquez sur le bouton Add pour ajouter un module d'authentification JAAS. Remplissez les informations pour votre module.Le Code est le nom de classe de votre module. Les Flags controlent 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. Consultez 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.Modifiez les paramètres d'authentification
Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Flags (indicateurs) en cliquant Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Option : ajouter ou supprimer un module
Pour ajouter des options à votre module, cliquez sur leurs entrées dans la liste Login Modules, et sélectionnez l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquez sur le bouton Add, et fournir la clé et la valeur de l'option. Utilisez le bouton Remove pour supprimer l'option.
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é.
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'un d'entre eux.
true
en démarrant la plate-forme JBoss EAP 6. Ajoutez ce qui suit pour démarrer les paramètres.
-Djboss.security.disable.secdomain.option=true
13.3. Java Authentication et Authorization Service (JAAS)
13.3.1. JAAS
13.3.2. Classes JAAS principales
Subject
(javax.security.auth.Subject
)
Configuration
(javax.security.auth.login.Configuration
)LoginContext
(javax.security.auth.login.LoginContext
)
Principal
(java.security.Principal
)Callback
(javax.security.auth.callback.Callback
)CallbackHandler
(javax.security.auth.callback.CallbackHandler
)LoginModule
(javax.security.auth.spi.LoginModule
)
13.3.3. Classes Subject et Principal
Subject
est la classe centrale dans JAAS. Un Subject
représente les informations d'une seule entité, comme une personne ou un service. Elle englobe les principaux de l'entité, les informations d'authentification publiques et privées. L'API JAAS utilise l'interface Java 2 java.security.Principal
pour représenter un principal, qui est essentiellement un nom dactylographié.
public Set getPrincipals() {...} public Set getPrincipals(Class c) {...}
getPrincipals()
renvoie tous les principaux contenus dans le subject. getPrincipals(Class c)
renvoie uniquement les principaux qui sont des instances de la classe c
ou d'une de ses sous-classes. Un ensemble vide sera renvoyé si le sujet n'a pas de principal correspondant.
java.security.acl.Group
est une sous-interface de java.security.Principal
, donc une instance de l'ensemble des principaux peut représenter un groupement logique d'autres principaux ou groupes de principaux.
13.3.4. Authentification du Subject
- Une application instancie un
LoginContext
et passe le nom de la configuration de la connexion et unCallbackHandler
pour remplir les objetsCallback
, selon la configurationLoginModule
. - Le
LoginContext
consulte uneConfiguration
pour charger tous lesLoginModules
inclus dans la configuration de connexion nommée. Si aucune configuration nommée existe, la configurationother
sera utilisée par défaut. - L'application invoque la méthode
LoginContext.login
. - La méthode login appelle chaque
LoginModule
téléchargé. Comme chaqueLoginModule
tente d'authentifier l'objet, il appelle la méthode handle sur leCallbackHandler
associé pour obtenir les informations requises par le processus d'authentification. L'information requise est passée à la méthode handle sous la forme d'un tableau d'objetsCallback
. En cas de réussite, leLoginModule
associe les principaux et les informations d'identification pertinents avec le subject. - Le
LoginContext
renvoie le statut d'authentification à l'application. Le renvoi par la méthode de connexion indique un succès. L'échec se traduit par une LoginException lancée par la méthode de connexion. - Si l'authentification réussit, l'application extrait le Subject authentifié par la méthode
LoginContext.getSubject
. - Une fois l'étendue de l'authentification de l'objet terminée, tous les principaux et informations connexes associées au subject par la méthode de
connexion
s'éliminent par la méthodeLoginContext.logout
.
LoginContext
fournit les méthodes de base d'authentification des subjects et offre un moyen de développer une application qui est indépendante de la technologie sous-jacente de l'authentification. Le LoginContext
consulte une Configuration
pour déterminer les services d'authentification configurés pour une application particulière. Les classes LoginModule
représentent les services d'authentification. Par conséquent, vous pouvez brancher des modules de connexion différents dans une application sans modifier l'application. Le code suivant illustre les étapes requises par une application pour authentifier un subject.
CallbackHandler handler = new MyHandler(); LoginContext lc = new LoginContext("some-config", handler); try { lc.login(); Subject subject = lc.getSubject(); } catch(LoginException e) { System.out.println("authentication failed"); e.printStackTrace(); } // Perform work as authenticated Subject // ... // Scope of work complete, logout to remove authentication info try { lc.logout(); } catch(LoginException e) { System.out.println("logout failed"); e.printStackTrace(); } // A sample MyHandler class class MyHandler implements CallbackHandler { public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException { for (int i = 0; i < callbacks.length; i++) { if (callbacks[i] instanceof NameCallback) { NameCallback nc = (NameCallback)callbacks[i]; nc.setName(username); } else if (callbacks[i] instanceof PasswordCallback) { PasswordCallback pc = (PasswordCallback)callbacks[i]; pc.setPassword(password); } else { throw new UnsupportedCallbackException(callbacks[i], "Unrecognized Callback"); } } } }
LoginModule
. Cela permet à un administrateur d'ajouter des technologies d'authentification différentes dans une application. Vous pouvez enchaîner ensemble de multiples LoginModule
afin de permettre à plus d'une technologie d'authentification de participer au processus d'authentification. Par exemple, un LoginModule
peut effectuer une authentification par nom/mot de passe, tandis que l'autre peut créer une interface avec des périphériques matériels tels que des lecteurs de cartes ou des identificateurs biométriques.
LoginModule
est motivé par l'objet LoginContext
avec lequel le client crée et publie la méthode login. Le processus se compose de deux phases. Les étapes du processus sont les suivantes :
- Le
LoginContext
crée chaqueLoginModule
en utilisant son constructeur public no-arg. - Chaque
LoginModule
est initialisé par un appel à sa méthode d'initialisation. L'argumentSubject
est garanti d'être non-null. La signature de la méthode d'initialisation est :public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options)
- La méthode
login
est appelée pour démarrer le processus d'authentification. Par exemple, une implémentation de la méthode peut inviter l'utilisateur à un nom d'utilisateur et à un mot de passe, et puis vérifiez les informations sur les données stockées dans un service d'attribution de noms comme NIS ou LDAP. Des implémentations alternatives pourraient créer des interfaces avec les cartes à puce et des dispositifs biométriques, ou simplement extraire les informations de l'utilisateur du système d'exploitation sous-jacent. La validation de l'identité de l'utilisateur par chaqueLoginModule
est considérée comme la phase 1 d'authentification JAAS. La signature de la méthodelogin
estboolean login() throws LoginException
. UneLoginException
indique un échec. Une valeur retour true indique que la méthode a réussi, tandis qu'une valeur false indique que le module de login doit être ignoré. - Si la méthode d'authentification générale de
LoginContext
réussit,commit
sera invoqué sur chaqueLoginModule
. Si la phase 1 réussit pour un moduleLoginModule
, alors la méthode de validation continue en phase 2 et associe les principaux qui conviennent, les informations d'authentification publiques, et/ou les informations d'authentification privées au sujet. Si la phase 1 échoue pourLoginModule
, alorscommit
retirera tout état d'authentification stocké auparavant, comme les noms d'utilisateur et les mots de passe. La signature de la méthodecommit
est :boolean commit() throws LoginException
. Tout manquement de la phase de validation (commit) se traduit par l'exceptionLoginException
. Un renvoi true indique que la méthode a réussi, alors qu'un renvoi false indique que le module de connexion doit être ignoré. - Si l'authentification globale du
LoginContext
échoue, la méthodeabort
sera appelée sur chaqueLoginModule
. La méthodeabort
supprime ou détruit tout état d'authentification créé par les méthodes de connexion ou d'initialisation. La signature de la méthodeabort
estboolean abort() throws LoginException
. En cas d'impossibilité d'achever la phased'abandon
est indiquée en jetant uneLoginException
. Un retour de true indique que la méthode a réussi, alors qu'un retour de false indique que le module de connexion doit être ignoré. - Pour supprimer l'état d'authentification après une connexion réussie, l'application appelle
logout
sur leLoginContext
. Il en résulte un appel de méthodelogout
sur chaqueLoginModule
. La méthodelogout
supprime les principaux et les informations d'identification associées initialement au sujet au cours de l'opérationcommit
(validation). Les informations d'identification doivent être détruites après le retrait. La signature de la méthodelogout
est :boolean logout() throws LoginException
. L'impossibilité d'achever le processus de déconnexion est indiquée par l'exceptionLoginException
. Un renvoi true indique que la méthode a réussi, alors qu'un renvoi false indique que le module de connexion doit être ignoré.
LoginModule
doit communiquer avec l'utilisateur pour obtenir des informations d'authentification, il utilise un objet CallbackHandler
. Les applications implémentent l'interface CallbackHandler et le font passer au LoginContext
, lequel envoie les informations d'authentification directement sur les modules de connexion sous-jacents.
CallbackHandler
à la fois pour recueillir les entrées d'utilisateurs, comme un mot de passe ou un PIN de smartcard, afin de fournir des informations aux utilisateurs, comme les informations d'état. En permettant à l'application de spécifier les CallbackHandler
, les LoginModule
sous-jacents restent indépendants des différentes façons dont les applications interagissent avec les utilisateurs. Par exemple, une implémentation de CallbackHandler
d'une application GUI peut afficher une fenêtre pour solliciter une action d'utilisateur. En revanche, une implémentation CallbackHandler
pour un environnement non graphique, comme un serveur d'applications, pourrait simplement obtenir des informations d'identification en utilisant un serveur d'application API. L'interface CallbackHandler dispose d'une méthode d'implémentation :
void handle(Callback[] callbacks) throws java.io.IOException, UnsupportedCallbackException;
Callback
est la dernière classe d'authentification que nous allons regarder. Il s'agit d'une interface de marquage pour laquelle plusieurs implémentations par défaut sont fournies, y compris le NameCallback
et le PasswordCallback
utilisés dans un exemple précédent. Un LoginModule
utilise un Callback
pour demander des informations requises par le mécanisme d'authentification. Les LoginModule
passent un tableau de Callback
directement à la méthode CallbackHandler.handle
au cours de la phase d'ouverture de session d'authentification. Si un callbackhandler
ne comprend pas comment utiliser un objet Callback
passé dans la méthode handle, il lancera une exception UnsupportedCallbackException
pour annuler l'appel d'ouverture de session.
13.4. Java Authentication SPI for Containers (JASPI)
13.4.1. Sécurité Java Authentication SPI pour Conteneurs (JASPI)
13.4.2. Configuration de la sécurité Java Authentication SPI pour conteneurs (JASPI)
<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 13.6. 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>
EAP_HOME/domain/configuration/domain.xml
ou dans le fichier EAP_HOME/standalone/configuration/standalone.xml
.
13.5. Autorisation
13.5.1. L'autorisation
13.5.2. Configurer l'autorisation pour un domaine de sécurité
Procédure 13.9. Configurez l'autorisation pour un domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité.
- Cliquez sur l'étiquette Configuration qui se trouve en haut de la console de gestion.
- Sélectionnez le profil à modifier à partir du menu déroulant Profile en haut et à gauche.
- Étendre l'item de menu Security, puis sélectionnez Security Domains.
- Cliquez sur le lien View pour obtenir le domaine de sécurité que vous voulez modifier.
Naviguez dans la configuration du sous-système d'autorisation.
Sélectionnez l'étiquette Authorisation en haut de l'écran.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.Ajoutez une police.
Cliquez sur Add pour ajouter un module de police d'authentification JAAS. Remplissez les informations pour votre module.Le Code est le nom de classe de votre module. Les Flags controlent 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. Consultez 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.Modifier les paramètres d'authorisation
Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Flags (indicateurs) en cliquant Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Option : ajouter ou supprimer un module
Pour ajouter des options à votre module, cliquez sur leurs entrées dans la liste Policies, et sélectionnez l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquez sur Add, et fournir la clé et la valeur de l'option. Utilisez le bouton Remove pour supprimer l'option.
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é.
13.6. Java Authorization Contract for Containers (JACC)
13.6.1. Java Authorization Contract for Containers (JACC)
13.6.2. Configurer la sécurité JACC (Java Authorization Contract for Containers)
jboss-web.xml
pour y inclure les paramètres qu'il faut.
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 requis
. 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>
Le fichier jboss-web.xml
se trouve dans 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>
La façon de configurer les EJB à utiliser un domaine de sécurité et JACC différe en fonction des application Web. Pour un EJB, vous pouvez déclarer des method permissions 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 roles JACC. Voir l'exemple de configuration pour plus d'informations. La classe EJBMethodPermission
fait partie de Java Enterprise Edition 6 API, et est documentée dans http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html.
Exemple 13.7. Exemple de permissions de méthode JACC dans un EJB
<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> </assembly-descriptor> </ejb-jar>
jboss-ejb3.xml
qui se trouve dans l'élément enfant <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 13.8. Exemple de déclaration de domaine de sécurité dans un EJB
<ejb-jar> <assembly-descriptor> <security> <ejb-name>*</ejb-name> <security-domain>myDomain</security-domain> <run-as-principal>myPrincipal</run-as-principal> </security> </assembly-descriptor> </ejb-jar>
13.6.3. Autorisation affinée par XACML
13.6.3.1. Autorisation affinée et XACML
- PERMIT - Accès approuvé.
- DENY - Accès non autorisé.
- INDETERMINATE - Erreur dans le PDP.
- NOTAPPLICABLE - Il y a des attributs manquants dans la requête, ou bien, il n'y a pas de politique correspondante.
- Bibliothèque Oasis XACML v2.0
- Modèle d'objet basé JAXB v2.0
- Intégration ExistDB pour stocker/extraire des Polices et Attributs XACML
13.6.3.2. Configurer XACML pour autorisation affinée
Procédure 13.10. Configurer XACML
- Télécharger la bibliothèque qui correspond à un simple fichier jar.
Créer un ou plusieurs fichiers de stratégies pour XACML
- Sous
WEB-INF/classes
, créer un répertoirepolicies
pour sauvegarder toutes vos stratégies. - Créer un
policyConfig.xml
sous le répertoireWEB-INF/classes
.Il existe deux types d'ensembles de stratégies que l'on puisse définir :- Role Permission Policy Sets (RPS)
- Permission Policy Sets (PPS)
Exemple 13.9. Role Permission Policy Sets (RPS)
Employé<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicySetId="RPS:employee:role" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">employee</AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> </SubjectMatch> </Subject> </Subjects> </Target> <!-- Use permissions associated with the employee role --> <PolicySetIdReference>PPS:employee:role</PolicySetIdReference> </PolicySet>
Gestionnaire<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicySetId="RPS:manager:role" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">manager</AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> </SubjectMatch> </Subject> </Subjects> </Target> <!-- Use permissions associated with the manager role --> <PolicySetIdReference>PPS:manager:role</PolicySetIdReference> </PolicySet>
Exemple 13.10. Permission Policy Sets (PPS)
Employé<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicySetId="PPS:employee:role" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> <Target /> <!-- Permissions specifically for the employee role --> <Policy PolicyId="Permissions:specifically:for:the:employee:role" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <Target /> <!-- Permission to create a purchase order --> <Rule RuleId="Permission:to:create:a:purchase:order" Effect="Permit"> <Target> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">purchase order </AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">create</AttributeValue> <ActionAttributeDesignator AttributeId="urn:action-id" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy> <!-- HasPrivilegesOfRole Policy for employee role --> <Policy PolicyId="Permission:to:have:employee:role:permissions" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <Target /> <!-- Permission to have employee role permissions --> <Rule RuleId="Permission:to:have:employee:permissions" Effect="Permit"> <Condition> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">employee</AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0:actions:hasPrivilegesOfRole </AttributeValue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> </Apply> </Apply> </Condition> </Rule> </Policy> </PolicySet>
Gestionnaire<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicySetId="PPS:manager:role" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> <Target /> <!-- Permissions specifically for the manager role --> <Policy PolicyId="Permissions:specifically:for:the:manager:role" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <Target /> <!-- Permission to sign a purchase order --> <Rule RuleId="Permission:to:sign:a:purchase:order" Effect="Permit"> <Target> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">purchase order </AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">sign</AttributeValue> <ActionAttributeDesignator AttributeId="urn:action-id" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy> <!-- HasPrivilegesOfRole Policy for manager role --> <Policy PolicyId="Permission:to:have:manager:role:permissions" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <Target /> <!-- Permission to have manager role permissions --> <Rule RuleId="Permission:to:have:manager:permissions" Effect="Permit"> <Condition> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">manager</AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0:actions:hasPrivilegesOfRole </AttributeValue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> </Apply> </Apply> </Condition> </Rule> </Policy> <!-- Include permissions associated with employee role --> <PolicySetIdReference>PPS:employee:role</PolicySetIdReference> </PolicySet>
Créer un fichier de configuration pour XACML engine.
Un fichier de configuration est créé pour configurer les localisateurs et pour indiquer les répertoires où les stratégies sont sauvegardées.Exemple 13.11. Fichier de configuration
Fichier de configuration uniquement qui indique le répertoire de fichiers de stratégies.<ns:jbosspdp xmlns:ns="urn:jboss:xacml:2.0"> <ns:Policies> <ns:PolicySet> <ns:Location>test/policies/rbac/</ns:Location> </ns:PolicySet> </ns:Policies> <ns:Locators> <ns:Locator Name="org.jboss.security.xacml.locators.JBossRBACPolicySetLocator"/> </ns:Locators> </ns:jbosspdp>
Fichier de configuration indiquant un ensemble de stratégies.<ns:jbosspdp xmlns:ns="urn:jboss:xacml:2.0"> <ns:Policies> <ns:PolicySet> <ns:Location>test/policies/rbac/employee-PPS-policyset.xml</ns:Location> </ns:PolicySet> <ns:PolicySet> <ns:Location>test/policies/rbac/manager-PPS-policyset.xml</ns:Location> </ns:PolicySet> <ns:PolicySet> <ns:Location>test/policies/rbac/employee-RPS-policyset.xml</ns:Location> </ns:PolicySet> <ns:PolicySet> <ns:Location>test/policies/rbac/manager-RPS-policyset.xml</ns:Location> </ns:PolicySet> </ns:Policies> <ns:Locators> <ns:Locator Name="org.jboss.security.xacml.locators.JBossRBACPolicySetLocator"/> </ns:Locators> </ns:jbosspdp>
- Créer un PDP (Policy Decision Point) et le passer dans un fichier de configuration.
- Dans le PEP (Policy Enforcement Point), créer une demande XACML basée sur le contexte. Passer la requête XACML au PDP pour obtenir une des décisions d'accès suivantes :
- Permission
- Refuser
- Indéterminé
- Non Applicable
Exemple 13.12. Décisions d'accès
Condition de permission<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os access_control-xacml-2.0-context-schema-os.xsd"> <Subject> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>Anne</AttributeValue> </Attribute> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>manager</AttributeValue> </Attribute> </Subject> <Resource> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>manager</AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>urn:oasis:names:tc:xacml:2.0:actions:hasPrivilegesOfRole</AttributeValue> </Attribute> </Action> </Request>
Déni de permission<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os access_control-xacml-2.0-context-schema-os.xsd"> <Subject> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>Anne</AttributeValue> </Attribute> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>manager</AttributeValue> </Attribute> </Subject> <Resource> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>manager</AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>urn:nobody</AttributeValue> </Attribute> </Action> </Request>
13.7. Security Auditing
13.7.1. Security Auditing
13.7.2. Configurer Security Auditing
Procédure 13.11. Configurez Security Auditing pour un domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité.
- Cliquez sur Configuration qui se trouve en haut de l'écran.
- Dans un domaine géré, sélectionnez le profil à modifier à partir du menu déroulant Profile en haut et à gauche.
- Étendre le menu Security, puis sélectionnez Security Domains.
- Cliquez sur View pour obtenir le domaine de sécurité que vous voulez modifier.
Naviguez dans la configuration du sous-système Auditing.
Sélectionnez l'onglet Audit qui se trouve en haut et à droite.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.Ajoutez un module de fournisseur.
Cliquez sur Add. Remplir la section Code avec le nom de classe du module du fournisseur.Vérifiez 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 EAP 6 inclut le moduleLogAuditProvider
par 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.log
qui se situe dans le sous-dossierlog
du 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érifiez 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
Pour ajouter des options à votre module, cliquez sur leurs entrées dans la liste Modules, et sélectionnez l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquez sur Add, et fournir la clé et la valeur de l'option.Pour modifier une option déjà existante, cliquez sur Remove pour la supprimer, et cliquez sur Add pour l'ajouter à nouveau avec les options qui conviennent.
Votre module d'audit 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é.
13.7.3. Nouvelles propriétés de sécurité
Tableau 13.1. Nouvelles propriétés de sécurité
Nom | Description | Valeurs possibles | Comportement | Par défaut |
---|---|---|---|---|
org.jboss.security.web.audit | Cette propriété contrôle la granularité de l'auditing de sécurité des requêtes web. | off , headers , cookies , parameters , attributes | Tout composant (ou groupe de composants séparés par des virgules) spécifié sera audité à partir des requêtes web. | headers,parameters |
org.jboss.security.web.audit.mask | Cette propriété peut être utilisée pour indiquer une liste de chaînes qui puissent correspondre à des en-tête, des paramètres, des cookies, et des attributs de requêtes web. Tout élément correspondant aux masques indiqués sera exclus de la journalisation d'audit de sécurité. | Toute chaîne séparée par des virgules utilisant des en-tête de clé, des paramètre, des cookies ou des attributs. | Actuellement, la mise en correspondance des masques est vague, non précise. Ainsi, un masque d' authorization masquera à la fois l'en-tête nommé authorization et le paramètre nommé custom_authorization. Il est possible qu'il y ait des masques plus stricts (précis) dans une version à venir. | j_password,authorization |
13.8. Mappage de sécurité
13.8.1. Mappage de sécurité
13.8.2. Configurer le mappage de sécurité dans un domaine de sécurité
Procédure 13.12. Configurer le Mappage de sécurité pour un Domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité.
- Cliquez sur l'étiquette Configuration qui se trouve en haut de la console de gestion.
- Dans un domaine géré, sélectionnez le profil à partir du menu déroulant Profile en haut et à gauche.
- Étendre l'item de menu Security, puis sélectionnez Security Domains.
- Cliquez sur View pour obtenir le domaine de sécurité que vous voulez modifier.
Naviguez dans la configuration du sous-système de mappage.
Sélectionnez l'étiquette Mapping en haut de l'écran.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 de mappage de sécurité.
Cliquez sur Ajouter.Remplissez les informations de 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, role, attribut ou identifiant.Modifier un module de mappage de sécurité
Une fois que vous aurez ajouté votre module, vous pourrez modifer son Code ou son Type.- Sélectionnez l'onglet Attributes.
- Cliquez sur Edit dans le champ Details de cet écran.
Option : ajouter, éditer ou supprimer un module
Pour ajouter des options à votre module, cliquez sur leurs entrées dans la liste Modules, et sélectionnez l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquez sur Add, et fournir la clé et la valeur de l'option.Pour modifier une option déjà existante, cliquez sur Remove pour la supprimer, et cliquez sur add pour l'ajouter à nouveau avec la nouvelle valeur.Utilisez Remove pour supprimer une option.
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é.
13.9. Utiliser un domaine de sécurité dans votre application
Pour utiliser un domaine de sécurité dans votre application, vous devez tout d'abord définir le domaine dans le fichier de configuration du serveur, puis vous devez l'activer pour une application dans le descripteur de déploiement de l'application. Ensuite, vous devez ajouter les annotations requises à l'EJB qui les utilise. Cette rubrique décrit les étapes requises pour utiliser un domaine de sécurité dans votre application.
Avertissement
Procédure 13.13. Configurez votre application pour qu'elle puisse utiliser un domaine de sécurité
Définir le domaine de sécurité
Vous devez définir le domaine de sécurité dans le fichier de configuration du serveur, puis l'activer pour une application dans le fichier du descripteur de l'application.Configurez le domaine de sécurité dans le fichier de configuration du serveur
Le domaine de sécurité est configuré dans le sous-système desécurité
du fichier de configuration du serveur. Si l'instance de JBoss EAP 6 s'exécute dans un domaine géré, il s'agira du fichierdomain/configuration/domain.xml
. Si l'instance de JBoss EAP 6 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-policy
sont fournis par défaut dans JBoss EAP 6. L'exemple XML suivant a été copié à partir du sous-système desécurité
dans le fichier de configuration du serveur.L'attributcach-type
d'un domaine de sécurité spécifie un cache pour pouvoir effectuer des contrôles d'authentification plus rapides. Les valeur autorisées sont les valeur pardéfaut
en cas de simile map comme cache ouinfinispan
pour un cache Infinispan.<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 l'interface CLI.Activer 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.xml
de 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
.
Ajoutez l'annotation requise à l'EJB.
Vous pouvez configurer la sécurité dans EJB par les annotations@SecurityDomain
et@RolesAllowed
. L'exemple de code EJB suivant limite l'accès au domaine de sécuritéother
aux 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-security
Quickstart dans le package JBoss EAP 6 Quickstarts disponible à partir du Portail Clients Red Hat.
Chapitre 14. Single Sign On (SSO)
14.1. SSO (Single Sign On) pour les applications web
Single Sign On (SSO) autorise l'authentification à une ressource, en vue d'autoriser implicitement l'accès à d'autres ressources.
SSO Non-clusterisée 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ésistantes au basculement. De plus, SSO clusterisée est capable de recevoir des demandes d'un équilibreur de charges.
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.
14.2. SSO (Single Sign On) clusterisées pour les applications web
jboss-Web.xml
de l'application.
- Apache Tomcat ClusteredSingleSignOn
- Apache Tomcat IDPWebBrowserSSOValve
- SSO basée-SPNEGO de PicketLink
14.3. Choisir l'implémentation SSO qui vous convient
web.xml
. Une SSO clusterisée permet la réplication des informations d'identité et de contexte de sécurité, indépendamment du fait de savoir si les applications sont elles-mêmes clusterisées. Bien que ces technologies peuvent être utilisées conjointement, elles repésentent des concepts distincts.
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 EAP 6.
Si vous exécutez un certain nombre d'applications sur une seule instance et que vous ayiez besoin d'activer une réplication de session SSO pour ces applications, la SSO non clusterisée sera la solution indiquée.
Si vous exécutez une ou plusieurs applications dans un cluster et que vous ayiez besoin d'activer une réplication de session SSO pour toutes ces applications, la SSO clusterisée sera la solution indiquée.
14.4. Utilisation de SSO (Single Sign On) pour les applications web
Les fonctionnalités SSO (Single Sign On) sont fournies par les sous-systèmes web et Infinispan. Utilisez 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
infinispan
est présent dans le profilfull-ha
d'un domaine géré, ou en utilisant la configurationstandalone-full-ha.xml
dans un serveur autonome. - Le
web
cache-conteneur
et 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 profilha
d'un domaine géré. Vous pouvez modifier les commandes pour utiliser un profil différent, ou supprimer la portion/profile=ha
de la commande, pour un serveur autonome.Exemple 14.1. Vérifier le cache-conteneur
web
Les profils et les configurations mentionnées ci-dessus incluent le cache-conteneurweb
par 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 14.2. Ajouter le cache-conteneur
web
Utilisez les trois commandes suivantes pour activer le cache-conteneurweb
à votre configuration. Modifiez 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 14.3. Vérifier le cache-conteneur
SSO
Éxécutez 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)
Cherchez une sortie qui ressemble à ceci :"sso" => {
Si vous ne la trouvez pas, le cache-conteneur ne sera pas présent dans votre configuration.Exemple 14.4. Ajoutez le cache-conteneur
SSO
/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)
- Le sous-système
web
doit être configuré pour utiliser SSO. La commande suivante active SSO sur le serveur virtuel appelédefault-host
et 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.xml
et le même Realm dans son fichier de configurationweb.xml
.
Configurer sso
sous le sous-système web dans le profil utilisateur. La version ClusteredSingleSignOn
est utilisée quand l'attribut cache-container
est présent, sinon la classe SingleSignOn
sera utilisée.
Exemple 14.5. Exemple de configuration SSO clusterisée
/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")
Exemple 14.6. Exemple de configuration SSO non clusterisée
/subsystem=web/virtual-server=default-host/sso=configuration:add(reauthenticate="false")
Une application peut rendre invalide une session en invoquant la méthode javax.servlet.http.HttpSession.invalidate()
.
14.5. Kerberos
14.6. SPNEGO
14.7. Microsoft Active Directory
- LDAP (Lightweight Directory Access Protocol) stocke les informations utilisateurs, ordinateurs, mots de passe et autres ressources.
- Kerberos procure une authentification sécurisée sur le réseau.
- DNS (Domain Service Name) fournit des mappages entre les adresses IP, les noms d'hôtes et les ordinateurs ou autres périphériques du réseau.
14.8. Configuration de Kerberos ou Microsoft Active Directory Desktop SSO pour les applications web
Pour authentifier vos applications web ou EJB à l'aide de l'authentification basée Kerberos existante de votre organisation et de votre infrastructure d'autorisation, comme Microsoft Active Directory, vous pouvez utiliser les fonctionnalités de JBoss Negotiation intégrées dans JBoss EAP 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.
Il existe des différences notables entre la plateforme JBoss EAP 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.xml
oujboss-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.xml
afin 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 substituée par la valve NegotiationAuthenticator du fichierjboss-web.xml
. - Les attributs
CODE
des 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 14.1. Codes de modules de connexion et Noms de classes
Nom simple | Nom de classe | But |
---|---|---|
Kerberos |
com.sun.security.auth.module.Krb5LoginModule
com.ibm.security.auth.module.Krb5LoginModule
|
Module de connexion Kerberos quand on utilise le JDK d'Oracle.
Module de connexion Kerberos quand on utilise le JDK d'IBM.
|
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
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 14.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 l'interface 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="UsersRoles" 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.xml
Le descripteurweb.xml
contient 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.xml
de 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.xml
si 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>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.MF
de 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.MF
du 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
- Sinon, ajouter une dépendance à votre application en modifiant le fichier
META-INF/jboss-deployment-structure.xml
:<?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure> <deployment> <dependencies> <module name='org.jboss.security.negotiation'/> </dependencies> </deployment> </jboss-deployment-structure>
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 n'aura pas besoin d'authentification, et les fonctionnalités SSO seront opérationnelles.
14.9. Configurer SPNEGO avec un renvoi à l'authentification Form
Procédure 14.2. Sécurité SPNEGO avec renvoi à l'authentification Form
Configurer SPNEGO
Voir la procédure décrite dans Section 14.8, « Configuration de Kerberos ou Microsoft Active Directory Desktop SSO pour les applications web »Modifier le fichier
web.xml
Ajouter un élémentlogin-config
à votre application et configurer les pages de connexion et d'erreurs dans le fichier web.xml :<login-config> <auth-method>SPNEGO</auth-method> <realm-name>SPNEGO</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> </login-config>
Ajouter un contenu web
Ajouter des references delogin.html
et deerror.html
àweb.xml
. Ces fichiers sont ajoutés à l'archive d'application web à l'emplacement spécifié dans la configurationform-login-config
. Pour obtenir des informations, voir la section Enable Form-based Authentication du Security Guide de JBoss EAP 6. Un fichierlogin.html
typique ressemble à ceci :<html> <head> <title>Vault Form Authentication</title> </head> <body> <h1>Vault Login Page</h1> <p> <form method="post" action="j_security_check"> <table> <tr> <td>Username</td><td>-</td> <td><input type="text" name="j_username"></td> </tr> <tr> <td>Password</td><td>-</td> <td><input type="password" name="j_password"></td> </tr> <tr> <td colspan="2"><input type="submit"></td> </tr> </table> </form> </p> <hr> </body> </html>
Note
Chapitre 15. SSO (Single Sign On) dans SAML
15.1. Security Token Service (STS)
- Type de requête, Issue, Renew, etc.
- Type de jeton
- Durée de vie du jeton donné
- Informations sur le fournisseur de services qui a demandé le jeton
- Informations utilisées pour crypter le jeton créé.
Note
provider
. La valeur spécifiée est passée aux appels KeyStore.getInstance("PKCS11")
pertinents; la clé et le key store sont initialisés.
java.security
. Le document Oracle Java PKCs #11 Guide de référence peut être une ressource utile d'information à ce sujet.
RequestSecurityToken
. L'exemple de requête contient deux autres éléments WS-Trust : RequestType
qui précise que cette requête est une requête d'émission et TokenType
qui spécifie le type du jeton qui sera attribué.
Exemple 15.1. Message de requête de jeton de sécurité WS-Trust
<S11:Envelope xmlns:S11=".." xmlns:wsu=".." xmlns:wst=".."> <S11:Header> ... </S11:Header> <S11:Body wsu:Id="body"> <wst:RequestSecurityToken Context="context"> <wst:TokenType>http://www.tokens.org/SpecialToken</wst:TokenType> <wst:RequestType> http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> </wst:RequestSecurityToken> </S11:Body> </S11:Envelope>
Exemple 15.2. Message de réponse de jeton de sécurité
<wst:RequestSecurityTokenResponse Context="context" xmlns:wst=".." xmlns:wsu=".."> <wst:TokenType>http://www.tokens.org/SpecialToken</wst:TokenType> <wst:RequestedSecurityToken> <token:SpecialToken xmlns:token="..."> ARhjefhE2FEjneovi&@FHfeoveq3 </token:SpecialToken> </wst:RequestedSecurityToken> <wst:Lifetime> <wsu:Created>...</wsu:Created> <wsu:Expires>...</wsu:Expires> </wst:Lifetime> </wst:RequestSecurityTokenResponse>
TokenType
spécifie le type du jeton émis, alors que l'élément RequestedSecurityToken
contient le jeton lui-même. Le format du jeton dépend du type du jeton. L'élément de Lifetime
spécifie quand le jeton a été créé et quand il expire.
Voici les étapes de traitement d'une requête de jeton de sécurité :
- Un client envoie une requête de jeton de sécurité à
PicketLinkSTS
.
PicketLinkSTS
analyse le message de requête, et génère un modèle d'objet JAXB.
PicketLinkSTS
lit le fichier de configuration et crée l'objetSTSConfiguration
, si nécessaire. Ensuite, il obtient une référence auWSTrustRequestHandler
de la configuration et délègue le traitement de la requête à l'instance du gestionnaire de la demande.
- Le gestionnaire de requêtes utilise
STSConfiguration
pour définir les valeurs par défaut si nécessaire (par exemple, lorsque la demande ne spécifie pas une valeur de durée de vie de jeton)
- Le
WSTrustRequestHandler
crée unWSTrustRequestContext
, définissant l'objet de la requêteJAXB
et le principal de l'appelant reçu dePicketLinkSTS
.
- Le
WSTrustRequestHandler
utilise laSTSConfiguration
pour obtenir leSecurityTokenProvider
qui doit être utilisé pour traiter la requête selon le type du jeton qui est demandé. Ensuite, il appelle le fournisseur, en passant leWSTrustRequestContext
en tant que paramètre.
- L'instance
SecurityTokenProvider
traite la demande de jeton et stocke le jeton à produire dans le contexte de demande.
- Le
WSTrustRequestHandler
obtient le jeton du contexte, le crypte si nécessaire, et construit l'objet de réponse WS-Trust contenu dans le jeton de sécurité.
PicketLinkSTS
dicte la réponse générée par le gestionnaire de requêtes et la renvoie au client.
15.2. Configuration des Security Token Service (STS)
picketlink.xml
, qui appartient au répertoire WEB-INF
de l'application déployée. Voici les éléments qui peuvent être configurés dans le fichier picketlink.xml
Note
PicketLinkSTS
: élément root. Définit des propriétés qui permettent à l'administrateur STS de définir les valeurs par défaut suivantes :STSName
: chaîne représentant le nom du service de jeton de sécurité. Si non spécifié, la valeurPicketLinkSTS
par défaut sera utilisée.TokenTimeout
: la valeur de durée de vie du jeton en secondes. Si non spécifié, la valeur par défaut 3600 (une heure) sera utilisée.EncryptToken
: valeur booléenne spécifiant si les jetons émis doivent être cryptés ou non. La valeur par défaut est false.
KeyProvider
: cet élément et tous ses sous-éléments sont utilisés pour configurer le keystore utilisé par PicketLink STS pour signer et crypter les jetons. Les propriétés comme l'emplacement du keystore, son mot de passe et l'alias de signature (clé privée) et mot de passe sont tous configurés dans cette section.RequestHandler
: cet élément spécifie le nom qualifié complet de l'implémentation deWSTrustRequestHandler
à utiliser. Si non spécifié, la valeur par défautorg.picketlink.identity.federation.core.wstrust.StandardRequestHandler
sera utilisée.TokenProvider
: cette section spécifie les implémentations deTokenProvider
qui doivent être utilisées pour gérer chaque type de token de sécurité. Dans l'exemple, nous avons deux fournisseurs - un qui gère les tokens de typeSpecialToken
et un autre qui gère les tokens de typeSAMLV2.0
. LeWSTrustRequestHandler
appelle la méthodegetProviderForTokenType
(String type) deSTSConfiguration
pour obtenir une référence pour leTokenProvider
qui convient.TokenTimeout
: ceci est utilisé par leWSTrustRequestHandler
quand aucune durée de vie n'a été spécifiée dans la requête de WS-Trust. Il crée une instance de durée de vie qui a l'heure actuelle comme heure de création et expire après un nombre indiqué de secondes.ServiceProviders
: cette section spécifie les types de jetons qui doivent être utilisés pour chaque fournisseur de service (le service Web qui requiert un jeton de sécurité). Lorsqu'une demande WS-Trust ne contient pas le type de jeton, leWSTrustRequestHandler
doit utiliser le point de terminaison du fournisseur de service pour déterminer le type du jeton qui doit être délivré.EncryptToken
: ceci est utilisé par leWSTrustRequestHandler
pour décider si le jeton émis doit être crypté ou non. Si true, le certificat de clé publique (PKC) du prestataire de services sera utilisé pour crypter le jeton
Exemple 15.3. Configuration STS
<PicketLinkSTS xmlns="urn:picketlink:identity-federation:config:1.0" STSName="Test STS" TokenTimeout="7200" EncryptToken="true"> <KeyProvider ClassName="org.picketlink.identity.federation.bindings.tomcat.KeyStoreKeyManager"> <Auth Key="KeyStoreURL" Value="keystore/sts_keystore.jks"/> <Auth Key="KeyStorePass" Value="testpass"/> <Auth Key="SigningKeyAlias" Value="sts"/> <Auth Key="SigningKeyPass" Value="keypass"/> <ValidatingAlias Key="http://services.testcorp.org/provider1" Value="service1"/> <ValidatingAlias Key="http://services.testcorp.org/provider2" Value="service2"/> </KeyProvider> <RequestHandler>org.picketlink.identity.federation.core.wstrust.StandardRequestHandler</RequestHandler> <TokenProviders> <TokenProvider ProviderClass="org.picketlink.test.identity.federation.bindings.wstrust.SpecialTokenProvider" TokenType="http://www.tokens.org/SpecialToken"/> <TokenProvider ProviderClass="org.picketlink.identity.federation.api.wstrust.plugins.saml.SAML20TokenProvider" TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/> </TokenProviders> <ServiceProviders> <ServiceProvider Endpoint="http://services.testcorp.org/provider1" TokenType="http://www.tokens.org/SpecialToken" TruststoreAlias="service1"/> <ServiceProvider Endpoint="http://services.testcorp.org/provider2" TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0" TruststoreAlias="service2"/> </ServiceProviders> </PicketLinkSTS>
15.3. Modules de connexion de PicketLink STS
Voici les différents types de modules de connexion STS.
STSIssuingLoginModule
- Appelle le STS configuré et demande un jeton de sécurité. Dès la réception du jeton
RequestedSecurityToken
, l'authentification est considérée comme un succès. - Un appel à STS exige normalement une authentification. Ce module de connexion utilise les informations d'authentificaition d'une des sources suivantes :
- Son fichier de propriétés, si l'option de module
useOptionsCredentials
est définie àtrue
. - Anciennes informations d'authentification de module de connexion si l'option de module
password-stacking
est définie àuseFirstPass
. - Du
CallbackHandler
configuré en donnant un nom et un mot de passe de Callback.
- Après une authentification réussie, le
SamlCredential
est inséré dans les informations d'authentification du sujet si une même Assertion n'est pas déjà présente.
STSValidatingLoginModule
- Appelle le STS configuré et valide un token de sécurité disponible.
- Un appel à STS exige normalement une authentification. Ce module de connexion utilise les informations d'authentificaition d'une des sources suivantes :
- Son fichier de propriétés, si l'option de module
useOptionsCredentials
est définie àtrue
. - Anciennes informations d'authentification de module de connexion si l'option de module
password-stacking
est définie àuseFirstPass
. - Du
CallbackHandler
configuré en donnant un nom et un mot de passe de Callback.
- Après une authentification réussie, SamlCredential est inséré dans les informations d'authentification du sujet si une même Assertion n'est pas déjà présente.
SAML2STSLoginModule
- Ce module de connexion fournit un
ObjectCallback
auCallbackHandler
configuré et attend un objetSamlCredential
retour. L'assertion est validée en rapport au STS configuré. - Si un ID utilisateur ou un jeton SAML sont partagés, ce module de connexion contournera la validation. S'il sont empilés l'un sur l'autre, connectez-vous au module qui est authentifié.
- Après une authentification réussie, le
SamlCredential
est inspecté pour trouver unNameID
et un attribut de rôle à valeur multiples qui est défini respectivement comme ID et rôles de l'utilisateur.
SAML2LoginModule
- Ce module de connexion est utilisé en conjonction avec d'autres composants pour l'authentification SAML et ne réalise aucune authentification.
SPRedirectFormAuthenticator
utilise ce module de connexion pour l'implémentation PicketLink du profil de redirection SAML v2 HTTP.- La valve d'authentificateur Tomcat effectue un authentification en redirigeant vers le fournisseur d'identité et en obtenant une assertion SAML.
- Ce module de connexion est utilisé pour faire passer l'ID utilisateur et les rôles au JBoss Security Framework dans le sujet JAAS.
15.4. Configurer STSIssuingLoginModule
STSIssuingLoginModule
utilise un nom d'utilisateur et un mot de passe pour authentifier l'utilisateur par un STS en extrayant un jeton.
Exemple 15.4. Configurer STSIssuingLoginModule
<security-domain name="saml-issue-token"> <authentication> <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule" flag="required"> <module-option name="configFile">./picketlink-sts-client.properties</module-option> <module-option name="endpointURI">http://security_saml/endpoint</module-option> </login-module> </authentication> <mapping> <mapping-module code="org.picketlink.identity.federation.bindings.jboss.auth.mapping.STSPrincipalMappingProvider" type="principal" /> <mapping-module code="org.picketlink.identity.federation.bindings.jboss.auth.mapping.STSGroupMappingProvider" type="role" /> </mapping> </security-domain>
- modifiant leur security-domain déclaré
- spécifiant un fournisseur de mappage Principal
- spécifiant un fournisseur de mappage RoleGroup
15.5. Configurer STSValidatingLoginModule
Exemple 15.5. Configurer STSValidatingLoginModule
<security-domain name="saml-validate-token"> <authentication> <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required"> <module-option name="configFile">./picketlink-sts-client.properties</module-option> <module-option name="endpointURI">http://security_saml/endpoint</module-option> </login-module> </authentication> <mapping> <mapping-module code="org.picketlink.identity.federation.bindings.jboss.auth.mapping.STSPrincipalMappingProvider" type="principal" /> <mapping-module code="org.picketlink.identity.federation.bindings.jboss.auth.mapping.STSGroupMappingProvider" type="role" /> </mapping> </security-domain>
15.6. Mise en pool de clients STS
- org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
- org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule
- org.picketlink.trust.jbossws.jaas.JBWSTokenIssuingLoginModule
initialNumberOfClients
.
org.picketlink.identity.federation.bindings.stspool.STSClientPoolFactory
fournit une fonctionnalité de mise en pool de clients aux applications.
Utilisation de STSClientPoolFactory
final STSClientPool pool = STSClientPoolFactory.getPoolInstance(); pool.createPool(20, stsClientConfig); final STSClient client = pool.getClient(stsClientConfig);
pool.returnClient();
if (! pool.configExists(stsClientConfig) { pool.createPool(stsClientConfig); }
pool.destroyPool(stsClientConfig);
15.7. Navigateur Web SAML basé SSO
15.7.1. SAML Web Browser Basé SSO
Important
15.7.2. Installation de Web SSO basé SAML v2
- Identity Provider: le fournisseur d'identité est l'entité faisant autorité responsable de l'authentification d'un utilisateur final et qui affirme l'identité de cet utilisateur de façon fiable à des partenaires de confiance.
- Service Provider: Le fournisseur de Service s'appuie sur le fournisseur d'identité pour affirmer des informations sur un utilisateur via une information d'identification de l'utilisateur électronique, laissant le prestataire de services gérer le contrôle d'accès et de diffusion sur la base d'un ensemble fiable d'affirmations d'identification utilisateur.
15.7.3. Configurer le fournisseur d'identités
Procédure 15.1. Configurer le fournisseur d'identités IDP
Configurer la sécurité de l'application web pour l'IDP
Configurer une application web comme fournisseur d'identité.Note
L'utilisation de la sécurité d'application web basée FORM est conseillée car elle donne la possibilité de personnaliser une page de connexion.Ce qui suit est un exemple de configurationweb.xml
Exemple 15.6. Configuration
web.xml
dans IDP<display-name>IDP</display-name> <description>IDP</description> <!-- Define a security constraint that gives unlimited access to images --> <security-constraint> <web-resource-collection> <web-resource-name>Images</web-resource-name> <url-pattern>/images/*</url-pattern> </web-resource-collection> </security-constraint> <!-- Define a Security Constraint on this Application --> <security-constraint> <web-resource-collection> <web-resource-name>IDP</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>manager</role-name> </auth-constraint> </security-constraint> <!-- Define the Login Configuration for this Application --> <login-config> <auth-method>FORM</auth-method> <realm-name>IDP Application</realm-name> <form-login-config> <form-login-page>/jsp/login.jsp</form-login-page> <form-error-page>/jsp/loginerror.jsp</form-error-page> </form-login-config> </login-config> <!-- Security roles referenced by this web application --> <security-role> <description> The role that is required to log in to the IDP Application </description> <role-name>manager</role-name> </security-role> </web-app>
Créer un domaine de sécurité pour IDP
Créer un domaine de sécurité avec des mécanismes d'authentification et d'autorisation définis pour IDP. Voir Section 13.9, « Utiliser un domaine de sécurité dans votre application » pour obtenir des informations supplémentaires.Configurer les Valves IDP
Créer un fichierjboss-web.xml
dans le répertoireWEB-INF
de votre application web IDP pour configurer les valves de l'IDP. Ce qui suit est un exemple du fichierjboss-web.xml
.Exemple 15.7. Configuration de fichier
jboss-web.xml
pour les valves IDP<jboss-web> <security-domain>idp</security-domain> <context-root>idp</context-root> <valve> <class-name>org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve</class-name> </valve> </jboss-web>
Configurer le fichier de configuration PicketLink (
picketlink.xml
)Voici un exemple de configurationpicketlink-idfed.xml
. Dans ce fichier de configuration, vous fournissez l'URL ajouté comme émetteur dans les assertions SAML2 sortantes pour les fournisseurs de services et l'IDP.Exemple 15.8. Configuration
picketlink.xml
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1"> <IdentityURL>http://localhost:8080/idp/</IdentityURL> </PicketLinkIDP> <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> </Handlers> </PicketLink>
Par défaut,picketlink.xml
se situe dans le répertoireWEB-INF
de votre application web IDP. Cependant, vous pourrez configurer un chemin personnalisé vers unpicketlink.xml
externe à l'application :Option : configurer un chemin personnalisé vers
picketlink.xml
Ajouter deux paramètres à l'élément valve duWEB-INF/jboss-web.xml
de votre application :configFile
indiquant le chemin verspicketlink.xml
, ettimerInterval
qui indique l'intervalle qu'il faut pour charger la configuration en millisecondes. Par exemple :<valve> <class-name>...</class-name> <param> <param-name>timerInterval</param-name> <param-value>5000</param-value> </param> <param> <param-name>configFile</param-name> <param-value>path-to/picketlink.xml</param-value> </param> </valve>
Déclare les dépendances sur le module PicketLink (
META-INF/MANIFEST.MF
, oujboss-deployment-structure.xml
)L'application web exige aussi qu'une dépendance soit définie dansMETA-INF/MANIFEST.MF
ou dansjboss-deployment-structure.xml
pour trouver les classes de PicketLink puissent être localisées.Exemple 15.9. Définir la dépendance dans
META-INF/MANIFEST.MF
Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.picketlink
Exemple 15.10. Définir la dépendance dans
META-INF/jboss-deployment-structure.xml
<jboss-deployment-structure> <deployment> <dependencies> <module name="org.picketlink" /> </dependencies> </deployment> </jboss-deployment-structure>
15.7.4. Configuration du fournisseur de services (SP) qui utilise la liaison HTTP/POST
Procédure 15.2. Configuration du fournisseur de services (SP)
Configurer la sécurité de l'application web pour le SP
L'application web à configurer en tant que SP doit avoir une sécurité basée FORM activée dans son fichierweb.xml
.Exemple 15.11. Configuration
web.xml
dans SP<display-name>SP</display-name> <description>SP</description> <!-- Define a security constraint that gives unlimited access to images --> <security-constraint> <web-resource-collection> <web-resource-name>Images</web-resource-name> <url-pattern>/images/*</url-pattern> </web-resource-collection> </security-constraint> <!-- Define a Security Constraint on this Application --> <security-constraint> <web-resource-collection> <web-resource-name>SP</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>manager</role-name> </auth-constraint> </security-constraint> <!-- Define the Login Configuration for this Application --> <login-config> <auth-method>FORM</auth-method> <realm-name>SP Application</realm-name> <form-login-config> <form-login-page>/jsp/login.jsp</form-login-page> <form-error-page>/jsp/loginerror.jsp</form-error-page> </form-login-config> </login-config> <!-- Security roles referenced by this web application --> <security-role> <description> The role that is required to log in to the SP Application </description> <role-name>manager</role-name> </security-role> </web-app>
Créer un domaine de sécurité pour SP
Créer un domaine de sécurité qui utiliseSAML2LoginModule
. Voici un exemple de configuration :<security-domain name="sp" cache-type="default"> <authentication> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule" flag="required"/> </authentication> </security-domain>
Configurer la valve SP
Pour configurer la valve du SP, créer un fichierjboss-web.xml
dans le répertoireWEB-INF
de votre application web SP.Exemple 15.12. Configuration de fichier
jboss-web.xml
pour les valves SP<jboss-web> <security-domain>sp</security-domain> <context-root>sales-post</context-root> <valve> <class-name>org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator</class-name> </valve> </jboss-web>
Configurer le fichier de configuration PicketLink (
picketlink.xml
)Voici un exemple de configurationpicketlink-idfed.xml
pour le SP. Dans ce fichier de configuration, vous fournissez l'URL pour le SP et l'IDP, avec les handlers correspondants pour le SP.Exemple 15.13. Configuration
picketlink.xml
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:2.1" ServerEnvironment="tomcat" BindingType="REDIRECT"> <IdentityURL>${idp.url::http://localhost:8080/idp/}</IdentityURL> <ServiceURL>${sales-post.url::http://localhost:8080/sales-post/}</ServiceURL> </PicketLinkSP> <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> </Handlers> </PicketLink>
Par défaut,picketlink.xml
se situe dans le répertoireWEB-INF
de votre application. Cependant, vous pourrez configurer un chemin personnalisé vers unpicketlink.xml
externe à l'application :Option : configurer un chemin personnalisé vers
picketlink.xml
Ajouter deux paramètres à l'élément valve duWEB-INF/jboss-web.xml
de votre application :configFile
indiquant le chemin verspicketlink.xml
, ettimerInterval
qui indique l'intervalle qu'il faut pour charger la configuration en millisecondes. Par exemple :<valve> <class-name>...</class-name> <param> <param-name>timerInterval</param-name> <param-value>5000</param-value> </param> <param> <param-name>configFile</param-name> <param-value>path-to/picketlink.xml</param-value> </param> </valve>
Déclare les dépendances sur le module PicketLink (
META-INF/MANIFEST.MF
, oujboss-deployment-structure.xml
)L'application web exige aussi qu'une dépendance soit définie dansMETA-INF/MANIFEST.MF
ou dansjboss-deployment-structure.xml
. pour trouver les classes de PicketLink puissent être localisées.Exemple 15.14. Définir la dépendance dans
META-INF/MANIFEST.MF
Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.picketlink
Exemple 15.15. Définir la dépendance dans
META-INF/jboss-deployment-structure.xml
<jboss-deployment-structure> <deployment> <dependencies> <module name="org.picketlink" /> </dependencies> </deployment> </jboss-deployment-structure>
15.7.5. Installation de Web SSO basé SAML v2 avec HTTP/POST Binding
Procédure 15.3. Installation de Web SSO basé SAML v2 avec HTTP/POST Binding
Configurer le fournisseur d'identités (IDP).
Les étapes de configuration d'IDP pour HTTP/POST Binding sont les mêmes que pour HTTP/Redirect Binding. Pour plus d'informations sur la façon de configurer l'IDP, voir Section 15.7.2, « Installation de Web SSO basé SAML v2 »Configuration du fournisseur de services (SP)
Les étapes de configuration de SP pour HTTP/POST Binding sont les mêmes que pour HTTP/Redirect Binding, excepté la variation qui existe dans le fichierpicketlink.xml
du SP. ModifiezBindingType="REDIRECT"
enBindingType="POST"
.Pour plus d'informations sur la configuration du SP, voir Section 15.7.4, « Configuration du fournisseur de services (SP) qui utilise la liaison HTTP/POST ».
15.7.6. Configurer un sélecteur de comptes dynamiques (Dynamic Account Chooser) auprès d'un fournisseur de services
Conditions préalables :
Procédure 15.4. Configurer un sélecteur de comptes dynamiques (Dynamic Account Chooser) auprès d'un fournisseur de services
- Configurer la valve
jboss-web.xml
dans le répertoireWEB-INF
de votre application web SP.Exemple 15.16. Configuration de fichier
jboss-web.xml
pour les Sélecteurs de comptes SP<jboss-web> <security-domain>sp</security-domain> <context-root>accountchooser</context-root> <valve> <class-name>org.picketlink.identity.federation.bindings.tomcat.sp.AccountChooserValve</class-name> </valve> <valve> <class-name>org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator</class-name> </valve> </jboss-web>
AccountChooserValve
a les options de configuration suivantes :- DomainName
- Le nom de domaine à utiliser par le cookie envoyé dans le navigateur de l'utilisateur.
- CookieExpiry
- La durée d'expiration du cookie en secondes. La valeur par défaut est
-1
, ce qui veut dire que le cookie expire quand le navigateur est fermé. - AccountIDPMapProvider
- Le nom complet de l'implémentation d'IDP Mapping. La valeur par défaut correspond à un fichier de propriétés
idpmap.properties
qui se trouve dans le répertoireWEB-INF
directory of de votre application web SP. Cette implementation doit implémenterorg.picketlink.identity.federation.bindings.tomcat.sp.AbstractAccountChooserValve.AccountIDPMapProvider
. - AccountChooserPage
- Le nom de la page HTML/JSP qui liste les divers comptes IDP. La valeur par défaut est
/accountChooser.html
.
- Définir le mappage des IDP. Il s'agit par défaut d'un fichier de propriétés
idpmap.properties
qui se trouve dans le répertoireWEB-INF
de votre application web SP.Exemple 15.17. Configuration
idpmap.properties
DomainA=http://localhost:8080/idp1/ DomainB=http://localhost:8080/idp2/
- Créer une page HTML dans votre application web de SP pour que l'utilisateur puisque choisir l'IDP. Par défaut, ce fichier est
accountChooser.html
. L'URL de chacun des IDP doit avoir le paramètreidp
qui spécifie le nom de l'IDP répertorié dansidpmap.properties
.Exemple 15.18.
accountChooser.html
Configuration<html> ... <a href="?idp=DomainA">DomainA</a> <hr/> <a href="?idp=DomainB">DomainB</a> ... </html>
15.7.7. Configuration d'un SSO initié par IDP
Conditions préalables :
Procédure
- L'utilisateur accède à l'IDP.
- L'IDP qui s'aperçoit qu'il n'y a aucune requête, ni aucune réponse SAML assume qu'il s'agit d'un premier scénario IDP utilisant SAML.
- L'IDP challenge l'utilisateur de s'authentifier.
- Une fois authentifié, l'IDP montre la section hébergée où l'utlisateur obtient une page qu'il relie à toutes les applications SP.
- L'utilisateur sélectionne une application SP.
- L'IDP redirige l'utilisateur vers le fournisseur de services par l'intermédiaire d'une assertion SAML dans le paramètre de requête, réponse SAML.
- Le SP vérifie l'assertion SAML et fournit l'accès.
Aucune configuration spéciale n'est requise la prise en charge des Réponses non sollicitées, donc vous pouvez configurer votre IDP et vos SP comme d'habitude. Pour obtenir plus d'informations sur la façon de configurer IDP et SP, consulter :
Une fois que l'utilisateur est authentifié, l'IDP montrera une page contenant les liens menant à toutes les applications du fournisseur. Un lien devrait ressembler à ce qui suit :
<a href="http://localhost:8080/idp?SAML_VERSION=2.0&TARGET=http://localhost:8080/sales-post/">Sales</a>Notez que le lien ci-dessus redirige l'utilisateur vers l'IDP en passant le paramètre de requête CIBLE, dont la valeur correspond à l'URL de l'application SP cible. Une fois que l'utilisateur clique sur le lien ci-dessus, l'IDP extrait le paramètre CIBLE de la requête, génère une réponse SAML v2.0 et redirige l'utilisateur vers l'URL cible. Lorsque l'utilisateur accède au SP, il est automatiquement authentifié.
15.8. Configuration du Profil SAML Global Logout
Note
Procédure 15.5. Configuration du Global Logout
Configurer picketlink-handlers.xml
Ajouter leSAML2LogOutHandler
dans le picketlink-handlers.xml.Configurer la page web du fournisseur de services
AjouterGLO=true
au lien qui se trouve en bas de votre page web de fournisseur de service.Exemple 15.19. Créer un lien vers Global Logout
<a href="?GLO=true">Click to Globally LogOut</a>
Créer une page
logout.jsp
Dans le cadre du processus de déconnexion, PicketLink redirigera l'utilisateur vers une pagelogout.jsp
qui se trouve dans le répertoire root de votre application de Service Provider. Veillez à ce que cette page soit bien créée.