Contraintes de conception

En général, les deux contraintes d'architecture les plus importantes à prendre en considération sont les suivantes :

• Aucune instance de l'application utilisateur ne peut servir (rechercher/interroger, ajouter des utilisateurs à, etc.) plus d'un conteneur utilisateur. En outre, lorsqu'un conteneur utilisateur a été associé à l'application, cette association est censée être permanente.

• Aucun pilote d'application utilisateur ne peut être associé à plusieurs applications utilisateur, sauf lorsque ces dernières sont installées sur les noeuds frères de la même grappe JBoss. En d'autres termes, l'assignation « un à plusieurs » des pilotes aux applications utilisateur n'est pas prise en charge.

La première contrainte implique un degré élevé d'encapsulation dans la conception de l'application utilisateur.

Supposons que votre structure organisationnelle soit la suivante :

Au cours de l'installation de l'application utilisateur, vous êtes invité à spécifier le conteneur utilisateur de niveau supérieur que votre installation recherchera dans le coffre-fort d'identité. Dans ce cas, vous pouvez spécifier ou=Marketing,o=ACME ou (autre possibilité) ou=Finance,o=ACME.

Vous ne pouvez pas spécifier les deux. L'étendue de toutes les recherches et requêtes de l'application utilisateur (et logins de l'administrateur) sera limitée au conteneur que vous spécifiez.

Remarque :En théorie, vous pouvez spécifier une étendue de o=ACME pour englober le Marketing et la Finance. Dans une organisation de grande dimension, avec potentiellement de nombreux conteneurs ou (plutôt que simplement deux associés au Marketing et à la Finance), par contre, cela risque de ne pas être pratique.

Il est possible, bien entendu, de créer deux installations indépendantes de l'application utilisateur (ne partageant aucune ressource en commun), l'une pour le Marketing et l'autre pour la Finance. Chaque installation doit avoir sa propre base de données, son propre pilote d'application utilisateur

correctement configuré. Chaque application utilisateur doit en outre être administrée séparément, avec des thèmes uniques si possible.

(FRA) 27 February 2006 Si vous devez vraiment placer le Marketing et la Finance dans la même étendue pour une installation

de l'application utilisateur, vous devez envisager deux tactiques possibles. L'une consiste à insérer un nouvel objet conteneur (par exemple, ou=MarketingAndFinance) dans la hiérarchie, au-dessus des deux noeuds frères. Pointez ensuite vers le nouveau conteneur comme racine de l'étendue. Une autre tactique consiste à créer une réplique filtrée (un type spécial d'arborescence eDirectory) qui combine les parties nécessaires de l'arborescence ACME d'origine, et à pointer l'application utilisateur vers le conteneur racine de la réplique. Reportez-vous au Guide d'administration de Novell eDirectory pour plus d'informations sur les répliques filtrées.

Si vous avez des questions concernant une configuration particulière du système, contactez votre représentant Novell pour obtenir de l'assistance ou un conseil.

2.2 Sécurité

Le passage de pré production en production implique généralement le renforcement des aspects de sécurité du système. En test sandbox, il se peut que vous ayez utilisé le HTTP classique pour connecter le pilote d'application utilisateur à JBoss, ou que vous ayez utilisé un certificat signé automatiquement (comme mesure temporaire) pour la communication pilote/serveur d'applications.

En production, en revanche, vous utiliserez probablement des connexions sécurisées, avec

l'authentification du serveur basée sur le certificat Verisign (ou d'un autre fournisseur approuvé) de votre entreprise.

(FRA) 27 February 2006 Il est classique d'utiliser des certificats X.509 à plusieurs endroits de l'environnement de

l'application utilisateur Identity Manager, comme l'illustre le diagramme ci-dessous.

Toutes les communications entre l'application utilisateur et le coffre-fort d'identité sont sécurisées, par défaut avec la sécurité de la couche de transport. L'installation du certificat du coffre-fort d'identité (eDirectory) dans le keystore de JBoss s'effectue automatiquement lors de l'installation.

Sauf si vous indiquez le contraire, le programme d'installation de l'application utilisateur place une copie du certificat eDirectory dans le magasin cacerts de JRE par défaut.

Le certificat de serveur doit se trouver à plusieurs endroits si les communications doivent être sécurisées, comme le montre le diagramme. Différentes étapes de configuration peuvent s'avérer nécessaire si vous avez l'intention d'utiliser un certificat signé automatiquement dans les différents emplacements du diagramme indiqués avec un cadre JBoss cert, ou si vous avez l'intention (plutôt) d'utiliser un certificat émis par un organisme de certification reconnu tel que Verisign.

(FRA) 27 February 2006 Certificats signés automatiquement

Si vous utilisez un certificat d'un émetteur reconnu (par exemple, Verisign), aucune étape spéciale de configuration n'est nécessaire. Par contre, si vous avez l'intention de créer et d'utiliser un certificat signé automatiquement, vous devez parcourir les étapes suivantes :

1 Créez un keystore avec un certificat signé automatiquement, en utilisant une syntaxe de ligne de commande comme ci-dessous.

keytool genkey alias tomcat keyalg RSA storepass changeit -keystore jboss.jks -dname

"cn=JBoss,ou=exteNd,o=Novell,l=Waltham,s=MA,c=US" -keypass changeit

Notez que vous créez le fichier “jboss.jks” ainsi que le certificat.

2 Copiez le fichier keystore (jboss.jks) dans votre répertoire d'application utilisateur JBoss, par exemple :

cp jboss.jks ~/jboss-4.0.2/server/spitfire/conf Activation de SSL dans JBoss

Pour activer SSL dans JBoss, recherchez le fichier jbossweb-tomcat55.sar sous [IDM]/jboss/server/

IDM/deploy/. Recherchez le fichier server.xml et ouvrez-le dans un éditeur de texte. Activez SSL en supprimant le commentaire ou en ajoutant une section du type :

<Connector port="8443" address="${jboss.bind.address}"

maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"

emptySessionPath="true"

scheme="https" secure="true" clientAuth="false"

keystoreFile="${jboss.server.home.dir}/spitfire/conf/jboss.jks"

keystorePass="changeit" sslProtocol = "TLS" />

Activation de la sécurité SOAP

Dans IDM.war, recherchez le fichier web.xml et ouvrez-le dans un éditeur de texte. En bas du fichier, supprimez le commentaire de la section suivante :

<security-constraint>

<transport-guarantee>CONFIDENTIAL</transport guarantee>

</user-data-constraint>

</security-constraint>

(FRA) 27 February 2006 Enregistrez le fichier et l'archive. Redémarrez JBoss.