DDMA DEVELOPPEMENT - annuuddi.fr.carrefour.comannuuddi.fr.carrefour.com/LdapWsWeb/documentation/ldap_spec.pdf · compagnie à usage de l’ensemble des applications intranet/extranet/internet

Copyright Carrefour SI France © Page 1 / 83

DDDDMMAA DDEEVVEELLOOPPPPEEMMEENNTT RRAAPPIIDDEE

FFRRAAMMEEWWOORRKK LLDDAAPP

SSPPEECCIIFFIICCAATTIIOONNSS TTEECCHHNNIIQQUUEESS

Version : 4.6

État : Applicable

Dernière modification : 22/09/2008 17:09

Framework LDAP Spécifications Techniques

Version : 4.6 Copyright Carrefour SI France © Page 2/83

Identification du document

Référence : Spécifications Techniques FrameWork LDAP.doc

Date d’édition : 23/09/2008

Date de création : 18/04/2005

Auteurs : Pascal Leydier & Thierry CARCELES

Chemin d’accès :

Gestion des versions

Version Date Auteur Objet de l’évolution 1.0 06/12/2003 P. Leydier Ecriture du document

1.1 02/01/2004 P. Leydier Corrections diverses et ajout de l’application RBAC

1.2 05/01/2004 P. Leydier Suppression du privilège « deleteAdmOrganization” des administrateurs fonctionnels, et corrections sur les privilèges des attributs.

1.3 06/01/2004 P. Leydier Diverses corrections, plus commentaires sur l’application d’administration RBAC

1.4 09/01/2004 P. Leydier Corrections dans la sécurité des admin fonctionnels et ajout des API de gestion de cache utilisateurs.

1.5 14/01/2004 P. Leydier Modification de l’application RBAC et ajout d’un rôle de sécurité

1.6 15/01/2004 P. Leydier Réglage de la sécurité.

1.7 29/03/2004 P. Leydier Mise à jour suite Axis et différentes modifications

2.0 18/4/2005 T. Carceles Séparation de la partie Installation dans doc dédiée

2.1 3/05/2005 R. Cousin Habillage de la page de login suivant la charte graphique du projet client & ajout/suppression dynamique de fournisseurs via fichiers excels

2.2 27/09/2005 R. Cousin Modification du paragraphe 6.5 concernant l’évolution du module « société » suite aux demandes d’évolution de Carfuel.

4.5 02/06/2008 S. Mendez Mise à jour en phase avec la version 4.5.x du Framework

4.6 17/07/2008 AQUE Mise à jour

Validation

Nom Fonction Date Statut Thierry Chabrol Architecture Janvier 2004 A diffuser



Sommaire

1 - CARACTERISTIQUES DU PROJET 4 1.1 - Contexte 4 1.2 - Documents de référence 4 1.3 - Organisation 4

2 - OBJECTIFS 5

3 - NORMES ET STANDARDS 6

4 - ARCHITECTURE GENERALE 7

5 - ARCHITECTURE LOGICIELLE 10 5.1 - Container EJB 10 5.2 - Le web Container LDAP 11 5.3 - Le web Container Site 13

6 - LES INTERFACES 15 6.1 - Les API des web services 15 6.2 - Authentification SSO-WEB 36 6.3 - Applications de test 40 6.4 - Les autotests 44

7 - LA SECURITE 45 7.1 - La sécurité par l’infrastructure 45 7.2 - Le protocole SSL 47 7.3 - L’auto-sécurisation 47

8 - TRACES, STATISTIQUES 58 8.1 - Traces 58 8.2 - Statistiques 59

9 - CONCEPTION DETAILLEE 62

10 - ACTEURS ET APPLICATIONS UTILISATRICES 71

ANNEXES 72 10.1 - Exemple d’utilisation des API de WS-AUTH : 72 10.2 - Exemple d’utilisation des API de WS-USER en Java : 73 10.3 - Exemple d’utilisation des API de WS-USER en .Net : 76 10.4 - Exemple d’utilisation des API de WS-ADMIN en Java : 77 10.5 - mise en place de la mire de login sur le projet Supervision EAI 79 10.6 - Description format XML de retour de l’API getProfil 83



1 - CARACTERISTIQUES DU PROJET

1.1 - CONTEXTE

Nom de l’application ou du projet

Framework LDAP

Description succincte de l'application à démarrer

Application centralisée pour la gestion de la sécurité applicative : authentification et habilitations.

Nombre d’utilisateurs et périmètres

Potentiellement toutes les applications de Carrefour France

Date de démarrage Opérationnel depuis juillet 2003.

1.2 - DOCUMENTS DE REFERENCE Ce document s’appuie sur les documents de référence ci-dessous : Tous les documents projets sont disponibles auprès du GPA (Pascal Ortoli) et à l’adresse : http://ldapcarrefourweb.fr.carrefour.com/LdapCarrefourWeb/

1.3 - ORGANISATION Fonction Nom Coordonnées

GPSI Tarik Zekri 01.69.19.36.38

GP Pascal Ortoli 01.69.19.30.00

Contact production

Emmanuel Fraysse 01.69.19.30.00

Contact exploitation

Contact architecture

Marin Le Houelleur 01.69.19.33.29

Framework Dev Thierry Carceles 04.37.69.60.00

http://ldapcarrefourweb.fr.carrefour.com/LdapCarrefourWeb/



2 - OBJECTIFS Le pré-requis de ce document est la connaissance de l’architecture OpenLdap mise en place à Carrefour. Un document est disponible auprès de la Direction Architecture Technique L’objectif du document est de définir les normes techniques à respecter pour tout développement Intranet/Internet dans l’environnement Carrefour ayant besoin d’une authentification et/ou d’une gestion applicative liée à des utilisateurs. Ce document décrit :

- les standards utilisés, - l’environnement technique, - l’architecture logicielle, - la conception détaillée et sa javadoc, - les interfaces et ses paramètres (attributs), - la gestion de la sécurité, - l’installation et l’administration du framework, - les traces, - les acteurs, et clients actuels des webservices,

L’objectif du framework est de :

- donner à Carrefour un référentiel unique des personnes et employés de la compagnie à usage de l’ensemble des applications intranet/extranet/internet. Ce référentiel permet de diminuer les coûts d’administration des applications en en concentrant l’administration sur une seule : le LDAP.

- normaliser les accès pour toutes les applications, générant ainsi des économies d’échelle,

- diminuer les coûts d’adaptation des applications lors des changements d’organisation, en concentrant cette organisation dans un seul système : le LDAP.

- diminuer les coûts de développement en simplifiant l’accès au LDAP via des web services et une page de login déjà générée.

- harmoniser la présentation des applications web en leur proposant une page de login unique.

- gérer les mots de passe des personnes dans un seul référentiel, diminuant les coûts d’administration des applications actuelles (help desk), et en simplifiant l’informatique vu des utilisateurs (un seul mot de passe pour toutes les applications).

- proposer une interface aux applications web leur permettant de ne plus gérer les logins à chaque appel d’application (SSO-WEB).

- synchroniser les données des fichiers de paye avec les métiers et fonctions réellement occupés par les employés de Carrefour, permettant une juste analyse des coûts des différents métiers.

- permettre la création d’applications à des coûts économiques plus faible (exemple : l’annuaire d’entreprise).



3 - NORMES ET STANDARDS Le framework est basé sur un ensemble rigoureux de normes et standards :

- pour le LDAP : o openLdap : très largement utilisé dans le monde et par de grands

groupes o organisation LDAP : basés sur des objets LDAP standards et des normes

(exemple : RBAC) o interface réseau basée sur le protocole TCP/IP et LDAP o interface de configuration : de nombreux clients pour OpenLdap existent

sur le marché - pour le framework :

o interface réseau basée sur les web services et le protocole SOAP et AXIS

o application à la norme J2EE 1.3 o persistance basée sur un container EJB 2.0, Sequoia et HSQLDB. o accès à OpenLdap via la norme J2EE/JNDI o applications basées sur du HTML 4 et du JavaScript 1.2 o utilisation de l’outil de développement WSAD (v5.1.2) basé sur un

standard Eclipse o utilisation du standard Apache/Axis pour la génération de fichiers de

description des web services (WSDL)



4 - ARCHITECTURE GENERALE Le framework LDAP est composé de divers éléments qui sont :

- un EJB Session sans état avec divers éléments détaillés dans le chapitre de conception détaillée,

- un container web avec des Java Beans d’accès à l’EJB et un module de routage des messages SOAP (gestion des web services),

- un ensemble d’applications de gestion détaillées dans le chapitre concernant l’architecture logicielle, de test, et d’administration du framework ainsi que des proxys d’accès aux web services,

- un webservice « site » spécifique à une application.

Instance Ldap

Annuaire

login.jsp

getNewPassword.jsp

Autotests, ...

AdminRBAC

Prox

y A

xis

EJBLdapWs

Site

Prox

y A

xis

OpenLDAP

SequoiaHSQL

DB

Instance Ldap

Autre instanceFramework Ldap

Sequoia HSQLDB

OpenLDAP

Réplication

Appl

icat

ion

Web

Appl

icat

ion

Web

Appl

icat

ion

Web

LdapAuth

LdapUser

LdapAdmin

Axi

s

:



Les modules peuvent être déportés sur différents serveurs physiques. Ces modules sont : - l’OpenLDAP - le container EJB avec son EJB Session et ses classes Java associées - le container Web LDAP avec les Beans d’accès - le container Web LDAP avec les applications de gestion des web services - le container Web SITE de gestion des Sites.

Ces modules doivent, cependant, rester sur un même réseau LAN, afin de permettre aux échanges réseaux très importants de s’effectuer correctement. D’autre part, le dialogue inter-container en J2EE étant basé sur le protocole CORBA, celui de OpenLDAP étant basé sur LDAP, il est donc indispensable que ces modules J2EE restent situés sur le même site central car les protocoles sont non passants à travers le firewall Carrefour. La séparation de ces modules nécessite tout de même une action au niveau du développement. Les applications clientes peuvent être situées sur n’importe quel endroit du réseau, voir sur des sites extérieurs étant donné que le protocole utilisé est celui des web services ; c'est-à-dire SOAP. SOAP utilise TCP/IP et HTTP et/ou HTTPS qui sont passant pour les firewalls Carrefour. Cela apporte un avantage supplémentaire à l’architecture, en ne permettant pas l’accès directement par les applications au serveur LDAP de Carrefour qui peut-être ainsi protégé au maximum des différentes attaques. Le chapitre §6 traite de la sécurité et propose plusieurs schémas d’infrastructure. Il y a trois web services dans le framework LDAP qui sont :

- le web service WS-AUTH. Sa fonction principale est d’authentifier un utilisateur et de lui associer un id sous la forme d’un chaîne de caractères. Ses autres fonctions concernent la possibilité de rechercher les privilèges associés à un utilisateur pour une application donnée. Exemple : recherche si un utilisateur a le droit de lire un état comptable, de le modifier, …etc…

- le web service WS-USER. Sa fonction concerne des fonctions plus élaborées et en relation avec deux types d’objets :

o les autres utilisateurs que soi-même, o les services et les personnes rattachées.

- le web service WS-ADMIN. Sa fonction concerne la gestion de la fonction RBAC. Il permet de gérer (création,…suppression) des applications dans l’annuaire et d’y associer des privilèges, rôles, groupes de personnes, …etc…

Une base de contextes externe (et commune) contient l’ensemble des IDs de tous les frameworks LDAP. A chaque création d’un ID, cette base est consultée afin de vérifier si l’utilisateur n’est pas déjà existant dans une autre instance de framework, et sinon, il est créé.



Ce contexte :

sert de cache aux multiples demandes venant des applications

n’a rien à voir avec un contexte session utilisateur d’une application web classique.

permet la persistance d’informations concernant les attributs de l’utilisateur (ex : mail, nom, …) et des droits Ldap associés aux applications (les privilèges et rôles)

A noter que la base Ldap est également répartie. Il existe une, et une seule, instance en écriture qui se réplique sur n instances en lecture. Une très légère latence peut donc exister entre une écriture et sa disponibilité en lecture.



5 - ARCHITECTURE LOGICIELLE Comme indiqué dans le chapitre précédent, le framework est basé sur le standard J2EE 1.3. Il est composé de différents containers qui sont :

- un container EJB, - un container Web qui est client de l’EJB et contenant les différentes applications

de tests et d’administration, - un container Web de gestion des sites.

5.1 - CONTAINER EJB

Le container EJB est constitué ainsi :

Inte

rface

Loc

ale

Inte

rface

Rem

ote

Ldap

WsB

ean

(exp

ositi

on s

ervi

ces

& g

estio

n sé

curit

é)

Ldap

Use

rId

Con

text

répa

rti(p

acka

ge p

ersi

sten

ce)

Une description détaillée sera donnée dans le chapitre de conception détaillée. Cependant, il y a deux classes Java importantes qui sont :

- LdapWsBean qui est le point d’entré de l’EJB. Cette classe a pour objectif de re-créer le mode session inexistant dans un EJB sans état et dans les web services. Cette session représente un id utilisateur et non pas un client de l’EJB. En effet, plusieurs applications utilisant un même id seront identifiées comme identiques.



- LdapWsUserId qui gère totalement l’environnement d’un id. Cette classe reste active le temps d’un timer d’activité mis en œuvre à travers la classe LdapWsGc (Garbage Collector). (Voir paramètre au chapitre §7.1)

5.2 - LE WEB CONTAINER LDAP

Les containers Web pour le framework LDAP sont composés ainsi :

Ldap Auth

Ldap User

Ldap Admin

AXIS

AdminRBAC

login.jsp

Annuaire

Prox

yAu

thPr

oxy

adm

in

corba

HTTP

SOAP

Appl

icat

ions

EJB

AdminUSER

Stats

Appli. de tests

Autotests, …

Prox

yU

ser

Documentation Fichiers WSDL

Une description détaillée sera donnée dans le chapitre de conception détaillée. Cependant un portail composé de la page index.html permet l’accès aux différents modules qui sont :

- les web services composés de : o du gestionnaire de messages SOAP : Axis o du bean routant les API du web service WS-AUTH o du bean routant les API du web service WS-USER o du bean routant les API du web service WS-ADMIN



- de la documentation concernant ces beans sous la forme d’une JavaDoc accessible en mode HTML. D’autres documentations complémentaires concernant la gestion des attributs et des requêtes dynamique sont aussi disponibles.

- de fichiers WSDL (Web Service Description Language) permettant à tout client d’un web service de disposer d’une description standard de l’interface. Ces fichiers très importants permettent aux concepteurs d’applications clientes d’un des web service, de générer, à travers les possibilités de leur IDE de développement, un code client du web service. Ce code est appelé proxy. Il ne reste qu’aux concepteurs de l’application à appeler ce proxy de la même manière que l’on appellerait les API du web service si elles étaient intégrées comme un objet interne à l’application.

- les proxys Auth, User, Admin sont des classes générées à l’origine à partir des fichiers WSDL décrits précédemment. Elles ont été modifiées de façon à prendre en compte des variables d’environnements décrits dans le chapitre installation. Ces proxys sont utilisés par les différentes applications de tests et de configuration décrites ci-dessous.

- les applications de test. Il y en a une par web service. Elles permettent de tester unitairement chaque API d’un web service. Elles permettent aussi aux différents développeurs d’applications de vérifier le fonctionnement de ces API avant implémentation pour en comprendre le fonctionnement.

- adminRBAC est l’application de configuration des applications dans le serveur OpenLdap. Elle permet de configurer les privilèges, rôles, et groupes d’utilisateurs associés.

- adminUSER est une application destinée aux utilisateurs afin de leur permettre de modifier leurs paramètres multimédia (email, fax, téléphone, …).

- createUSER est une application destinée aux RH et aux administrateurs leur permettant de créer des utilisateurs soit directement via un formulaire HTML, soit via un fichier CSV.

- de la page login.jsp et des pages associées d’aide en ligne et de test. Cette page est un des éléments de réutilisation possible par les différentes applications clientes du framework. Elle permet à celles-ci de s’affranchir du codage de l’authentification, et leur permet de préparer une authentification unique SSO-WEB (de type SSO Single-Sign-On). Ainsi l’utilisateur ne s’authentifiera qu’une seule fois au lieu de le faire lors de chaque lancement d’application. La gestion de changement de mot de passe par l’utilisateur est aussi intégrée à cette page.

- de la page getNewPassword.jsp. Cette page est un des éléments de réutilisation possible par les différentes applications clientes du framework. Elle permet à celles-ci de s’affranchir du codage la gestion de perte de mot de passe par l’utilisateur.

- l’annuaire permet de rapidement rechercher un utilisateur dans OpenLdap ainsi que ses attributs dynamiques. Il est à destination unique des développeurs d’applications. Pour son fonctionnement, il a besoin de l’utilisateur FRTEST0.

- stats.jsp permet de connaître les paramètres de configuration du web container et de l’EJB container. Il indique aussi des statistiques concernant l’instanciation de l’EJB et des utilisateurs LDAP.



- les autotests sont des pages jsp permettant de tester unitairement chacun des web services. Pour leurs fonctionnements, ils ont besoin des utilisateurs CS$LDAP00, CS$LDAP01, CS$LDAP02, CS$LDAP03, CS$LDAP04, et CS$LDAP05.

5.3 - LE WEB CONTAINER SITE

Le container Web pour la gestion des sites est composé ainsi :

Site

AXI

S

portail

HTTP

SOAP

Appl

icat

ions

Appli. de tests

Pro

xyS

ite

Documentation Fichiers WSDL

Son point d’entrée est un portail composé de la page index.html qui permet l’accès aux différents modules qui sont :

- le web service composé de : o du gestionnaire de messages SOAP : AXIS o du bean routant les API du web service SITE

- de la documentation concernant ce bean sous la forme d’une JavaDoc accessible en mode HTML.



- d’un fichier WSDL (Web Service Description Language) permettant à tout client du web service de disposer d’une description standard de l’interface.

- d’un proxy Site qui a été généré à l’origine à partir du fichier WSDL décrit précédemment. Ce proxy est utilisé par les différentes applications de tests décrites ci-dessous.

- l’application de test. Elle permet de tester unitairement chaque API du web service. Elle permet aussi aux différents développeurs d’applications de vérifier le fonctionnement de ces API avant implémentation pour en comprendre le fonctionnement.



6 - LES INTERFACES Les interfaces sont de différents ordres :

- il y a les interfaces des web services qui sont sous la forme d’API décrites dans des fichiers WSDL et dont l’explication est donnée dans la documentation JavaDoc.

- puis les interfaces d’authentifications uniques à travers une page de login unique.

- puis, l’application d’administration RBAC de l’annuaire. - et enfin, les applications de statistiques, d’installation, et des tests.

6.1 - LES API DES WEB SERVICES

La description complète de chacune des API est donnée dans la JavaDoc accessible depuis le portail de chacun des web container.



6.1.1 - WS-AUTH

Ce web service a pour fonction d’authentifier un utilisateur de l'annuaire LDAP Carrefour et de retourner les privilèges associés à cet utilisateur pour différentes applications.

Résumé des méthodes java.lang.String Login(java.lang.String user, java.lang.String password)

Login d'un utilisateur LDAP.

java.lang.String Login(byte[] cert, java.lang.String password)

Login d'un utilisateur LDAP. Non implémentée.

java.lang.String setPassword(java.lang.String user, java.lang.String oldPassword, java.lang.String newPassword, java.lang.String newPassword2) Change le mot de passe d'un utilisateur LDAP.

java.lang.String setPassword(byte[] cert, java.lang.String oldPassword, java.lang.String newPassword, java.lang.String newPassword2) Change le mot de passe d'un utilisateur LDAP. Non implémentée.

boolean isAlive(java.lang.String id)

Permet de vérifier l'existence d'un ID.

java.lang.String[] getPrivileges(java.lang.String id, java.lang.String applicationName) Recherche des privilèges d'un utilisateur pour une application donnée.

java.lang.String[] getRoles(java.lang.String id, java.lang.String applicationName) Recherche des rôles d'un utilisateur pour une application donnée.

java.lang.String[] getDynamics(java.lang.String id, java.lang.String applicationName, java.lang.String request, java.lang.String[] params)

Lance l'exécution d'une requête dynamique.

java.lang.String[] getSites(java.lang.String id, java.lang.String applicationName)

Lance l'exécution d'une requête dynamique nommé "site".



java.lang.String[] getAttribut(java.lang.String id, java.lang.String attributName) Recherche la valeur d'un attribut.

boolean isValidCert(java.lang.String id, byte[] cert, boolean testDate, boolean testRevoked) Vérifie que le certificat correspond à celui de l’utilisateur référencé par son ID et : - est dans sa période de validité si « testDate est « true ». -est non révoqué si « testRevoked » est « true »

boolean isNotRevokedCert(java.lang.String id)

Vérifie que le certificat de l’utilisateur existe et n’est pas révoqué.

java.lang.String getCertStringAttribut(java.lang.String id, java.lang.String attribut) Recherche les valeurs d’un attribut de certificat. Voici les différentes valeurs des attributs :

Nom Remarque BEGIN_DATE Date de début de validité du certificat sous la

forme du nombre de millisecondes depuis le 1er janvier 1970.

END_DATE Date de fin de validité du certificat sous la forme du nombre de millisecondes depuis le 1er janvier 1970.

SERIAL_NUMBER Numéro de série du certificat utilisé pour la révocation.

TYPE Type de certificat (ex : « X.509 »)

VERSION Version du certificat ( ex : « 3 »)

ALGORITHME Nom de l’algorithme utilisé (ex : « RSA »)

SERIAL_VERSION_UID Numéro de série de la clé publique

REVOK_DATE Date de révocation si elle existe sous la forme du nombre de millisecondes depuis le 1er janvier 1970.

byte[] getCertByteAttribut(java.lang.String id, java.lang.String attribut) Recherche les valeurs d’un attribut de certificat. Voici les différentes valeurs des attributs :

Nom Remarque



PUBLIC_KEY Clé publique retournée

EXTENSION_VALUE Retourne les extensions

SIGNATURE Signature du certificat

byte[] getCert(java.lang.String id)

Retourne le certificat de l’utilisateur

void getNewPassword(java.lang.String login, java.lang.String email, java.lang.String url)

Envoi un mail si l’email passé en paramètre correspond a celui connu du ldap.

byte[] getCaptcha(java.lang.String chgpwdId)

Retourne l’image du Captcha sous la forme d’un tableau de bytes.

void setCaptchaAsPassword(java.lang.String chgpwdId, java.lang.String texte) Modifie le password si la concordance du texte en paramètre et du password stocké est vérifiée.

String getProfil(java.lang.String id)

Retourne une structure XML contenant pour l’utilisateur l’ensemble de ses attributs et les applications métier auquel il est autorisé en un seul appel. (voir annexe pour la description)

Remarques :

le paramètre « params » de getDynamics() peut être mis à « null » si aucun paramètre n’est demandé.

Pour les APIs « login » et « setPassword » , suivant le type de certificat, le mot de passe n’est pas toujours obligatoire. Dans le cadre des certificats actuels, il le sera toujours. Ces APIs ne sont pour le moment pas implémentées.

Exemple d’utilisation des API de WS-AUTH en Java : voir annexes



6.1.2 - WS-USER

Ce web service est réservé à des administrateurs de services et d’utilisateurs tels que les Ressources Humaines. Il se décompose en deux types de services : - le service aux utilisateurs avec la possibilité de créer, supprimer, modifier un utilisateur et ses attributs - idem sur la gestion des services regroupant des personnes hiérarchiquement.

Résumé des méthodes void deleteUser(java.lang.String id, java.lang.String login)

Suppression d'un utilisateur LDAP.

void addUser(java.lang.String id, java.lang.String login, java.lang.String[] attributsType, java.lang.String[] attributsValue)

Ajoute un utilisateur LDAP.

void setUserAttributs(java.lang.String id, java.lang.String login, java.lang.String[] attributsType, java.lang.String[] attributsValue, java.lang.String fAction)

Récupère les attributs d'un utilisateur LDAP.

java.lang.String[] getUserAttributs(java.lang.String id, java.lang.String login, java.lang.String[] attributsType, java.lang.String pad)

Ajoute ou supprime des attributs d'un utilisateur LDAP.

java.lang.String[] getUsersAttribut(java.lang.String id, java.lang.String[] login, java.lang.String attributType, java.lang.String pad) Permet une recherche d'un type d'attributs sur plusieurs utilisateurs en même temps.

java.lang.String[] searchUsers(java.lang.String id, java.lang.String[] login, java.lang.String[] attributsType, java.lang.String[] attributsValue) Permet une recherche d'utilisateurs ayant les attributs cités ; par exemple la liste des utilisateurs d'un service si "login" et "*", "attributsType" vaut "ATTR_USER_SERVICE" et "attributsValue" est un serviceId.

void setUserPassword(java.lang.String adminUser, java.lang.String adminPassword, java.lang.String user, java.lang.String userPassword, java.lang.String userConfirm) Mise à jour du mot de passe d'un utilisateur



java.lang.String[] getServices(java.lang.String id)

Donne la liste des services de premier niveau.

java.lang.String addService(java.lang.String id, java.lang.String newService, java.lang.String baseServiceId, java.lang.String[] attributsType, java.lang.String[] attributsValue) Ajoute un service.

void deleteService(java.lang.String id, java.lang.String serviceId)

Suppression d'un service.

java.lang.String[] getServiceAttributs(java.lang.String id, java.lang.String serviceId, java.lang.String[] attributsType, java.lang.String pad)

Récupère les attributs d'un service dans le LDAP.

void setServiceAttributs(java.lang.String id, java.lang.String serviceId, java.lang.String[] attributsType, java.lang.String[] attributsValue, java.lang.String fAction) Ajoute ou supprime des attributs sur un service

java.lang.String[] getSecretariesService(java.lang.String id, java.lang.String serviceId) Cas particulier : recherche d'assistante.

java.lang.String[] getChildServices(java.lang.String id, java.lang.String serviceId)

Retourne les id de chaque service fils.

java.lang.String getParentService(java.lang.String id, java.lang.String serviceId)

Retourne l'id du service père.

java.lang.String[] getManagerService(java.lang.String id, java.lang.String serviceId) Retourne les logins du manager du service

java.lang.String[] getBussiness(java.lang.String id, java.lang.String serviceId, java.lang.String pad) Retourne la liste des métiers existants

java.lang.String[] getFunctions(java.lang.String id, java.lang.String serviceId, java.lang.String pad)



Retourne la liste des fonctions existantes

boolean isValidUserCert(java.lang.String id, java.lang.String login, boolean testDate, boolean testRevoked)

Vérifie que le certificat de l’utilisateur référencé par son login existe, est valide et non révoqué.

boolean isNotRevokedUserCert(java.lang.String id, java.lang.String login) Vérifie que le certificat de l’utilisateur référencé par son login existe et n’est pas révoqué.

java.lang.String getUserCertStringAttribut(java.lang.String id, java.lang.String login, java.lang.String attribut) Recherche les valeurs d’un attribut de certificat. Voici les différentes valeurs des attributs :

Nom Remarque BEGIN_DATE Date de début de validité du certificat sous la

forme du nombre de millisecondes depuis le 1er janvier 1970.

END_DATE Date de fin de validité du certificat sous la forme du nombre de millisecondes depuis le 1er janvier 1970.

SERIAL_NUMBER Numéro de série du certificat utilisé pour la révocation.

TYPE Type de certificat (ex : « X.509 »)

VERSION Version du certificat ( ex : « 3 »)

ALGORITHME Nom de l’algorithme utilisé (ex : « RSA »)

SERIAL_VERSION_UID Numéro de série de la clé publique

REVOK_DATE Date de révocation si elle existe sous la forme du nombre de millisecondes depuis le 1er janvier 1970.

byte[] getUserCertByteAttribut(java.lang.String id, java.lang.String login, java.lang.String attribut) Recherche les valeurs d’un attribut de certificat. Voici les différentes valeurs des attributs :

Nom Remarque PUBLIC_KEY Clé publique retournée

EXTENSION_VALUE Retourne les extensions

SIGNATURE Signature du certificat



byte[] getUserCert(java.lang.String id, java.lang.String login)

Retourne le certificat d’un utilisateur.

Remarque : les paramètres « logins », « attributsType », « attributsValue » peuvent être mis à « null » si non nécessaires à l’exécution de l’API. Exemple d’utilisation des API de WS-USER en Java : voir Annexes Exemple d’utilisation des API de WS-USER en .Net : voir Annexes



6.1.3 - WS-ADMIN

Ce web service est destiné aux administrateurs du LDAP et aux administrateurs fonctionnels des applications dont le modèle RBAC est intégré au LDAP.

Résumé des méthodes java.lang.String[] getAdmIdActives(java.lang.String id)

Liste les utilisateurs actifs.

void stopAdmIdActive(java.lang.String id, java.lang.String user) Invalide un id utilisateur dans le cache du web service.

void addAdmApplication(java.lang.String id, java.lang.String appName, java.lang.String description) Ajoute une application.

java.lang.String getAdmApplicationDescription(java.lang.String id, java.lang.String appName) Récupère la description d'une application.

void deleteAdmApplication(java.lang.String id, java.lang.String appName)

Supprime une application.

java.lang.String[] getAdmApplications(java.lang.String id)

Récupère la liste de toutes les applications.

void addAdmPrivilege(java.lang.String id, java.lang.String appName, java.lang.String privilege, java.lang.String description) Ajoute un privilège à une application.

java.lang.String getAdmPrivilegeDescription(java.lang.String id, java.lang.String appName, java.lang.String privilege) Récupère la description d'un privilège.

void deleteAdmPrivilege(java.lang.String id, java.lang.String appName, java.lang.String privilege)

Supprime un privilège d'une application.

java.lang.String[] getAdmPrivileges(java.lang.String id, java.lang.String appName)

Récupère la liste de tous les privilèges d'une application.



void addAdmRole(java.lang.String id, java.lang.String appName, java.lang.String role, java.lang.String description) Ajoute un rôle à une application.

void deleteAdmRole(java.lang.String id, java.lang.String appName, java.lang.String role) Supprime un rôle d'une application.

java.lang.String getAdmRoleDescription(java.lang.String id, java.lang.String appName, java.lang.String role)

Récupère la description d'un rôle.

java.lang.String[] getAdmRoles(java.lang.String id, java.lang.String appName)

Récupère la liste de tous les rôles d'une application.

java.lang.String[] getAdmPrivilegesForRole(java.lang.String id, java.lang.String appName, java.lang.String role) Récupère la liste des privilèges pour un rôle d'une application.

void setAdmPrivilegesForRole(java.lang.String id, java.lang.String appName, java.lang.String role, java.lang.String[] privileges, java.lang.String action)

Positionne une liste de privilèges pour un rôle d'une application.

java.lang.String[] getAdmUsersForRole(java.lang.String id, java.lang.String appName, java.lang.String role) Récupère la liste des utilisateurs pour un rôle d'une application.

void setAdmUsersForRole(java.lang.String id, java.lang.String appName, java.lang.String role, java.lang.String[] users, java.lang.String action) Positionne une liste d'utilisateurs pour un rôle d'une application.

java.lang.String[] getAdmGroupOfUsersForRole(java.lang.String id, java.lang.String appName, java.lang.String role)

Récupère la liste des groupes d'utilisateurs pour un rôle d'une application.

void setAdmGroupOfUsersForRole(java.lang.String id, java.lang.String appName, java.lang.String role, java.lang.String[] groups, java.lang.String action) Positionne une liste de groupes d'utilisateurs pour un rôle



d'une application.

java.lang.String[] getAdmOrganizations(java.lang.String id)

Liste toutes les organisations.

java.lang.String addAdmOrganization(java.lang.String id, java.lang.String newOrg, java.lang.String baseOrgId, java.lang.String description) Ajoute une organisation.

java.lang.String[] getAdmChildOrganizations(java.lang.String id, java.lang.String orgId) Retourne l’id de chaque organisation fille.

java.lang.String[] getAdmOrganizationAttribut(java.lang.String id, java.lang.String orgId, java.lang.String attrName) Récupère la valeur de l’attribut de l’organisation

void setAdmOrganizationAttribut(java.lang.String id, java.lang.String orgId, java.lang.String attrName, java.lang.String attrValue) Modifie la valeur de l’attribut de l’organisation

java.lang.String getAdmOrganizationDescription(java.lang.String id, java.lang.String orgId)

Récupère la description d'une organisation.

java.lang.String[] searchAdmOrganizationForAttribut(java.lang.String id, java.lang.String orgId, java.lang.String attrName, java.lang.String attrValue)

Recherche des organisations grâce à la valeur d’un attribut.

void deleteAdmOrganization(java.lang.String id, java.lang.String orgId)

Suppression d'une organisation.

java.lang.String[] getAdmObjectAttributs(java.lang.String id, java.lang.String name, java.lang.String type, java.lang.String base)

Liste tous les attributs d'un objet LDAP.

void addAdmDynamic(java.lang.String id, java.lang.String appName, java.lang.String dynamic, java.lang.String description)

Ajoute un dynamic à une application

java.lang.String getAdmDynamicDescription(java.lang.String id,



java.lang.String appName, java.lang.String dynamic) Récupère la description d’une requête dynamique.

void deleteAdmDynamic(java.lang.String id, java.lang.String appName, java.lang.String dynamic) Supprime un dynamic d'une application.

java.lang.String[] getAdmDynamics(java.lang.String id, java.lang.String appName) Récupère la liste de tous les dynamics d'une application.

void setAdmMemberURLForDynamic(java.lang.String id, java.lang.String appName, java.lang.String dynamic, java.lang.String memberURL, java.lang.String action) Positionne la valeur d'un dynamic.

java.lang.String getAdmMemberURLForDynamic(java.lang.String id, java.lang.String appName, java.lang.String dynamic)

Lit la valeur d'un dynamic.

java.lang.String getAdmParam(java.lang.String id, java.lang.String param)

Statistiques et paramètres internes en vue de l'affichage sur le site web.

void setAdmParam(java.lang.String id, java.lang.String param, java.lang.String value)

Mise à jour des paramètres internes.

java.lang.String getVersion()

Renvoie la version de l’EAR.

Exemple d’utilisation des APIs de WS-ADMIN en Java : voir Annexes



6.1.4 - WS-SITE

Ce web service est destiné à la gestion des sites permettant d’obtenir, par exemple, l’adresse postale d’un magasin.

Résumé des méthodes

java.lang.String[] getLegalEntities(java.lang.String id) Donne la liste des entitées commerciales.

java.lang.String[] getLegalEntityAttributs(java.lang.String id, java.lang.String legalEntity, java.lang.String[] attributsType, java.lang.String pad) Récupère les attributs d'une entité commerciale.

java.lang.String[] getSiteAttributs(java.lang.String id, java.lang.String site, java.lang.String[] attributsType, java.lang.String pad) Récupère les attributs d'un site.

java.lang.String[] getSites(java.lang.String id) Donne la liste des sites.

java.lang.String[] searchLegalEntities(java.lang.String id, java.lang.String[] legalEntities, java.lang.String[] attributsType, java.lang.String[] attributsValue) Permet une recherche d'entité commerciale ayant les attributs cités.

java.lang.String[] searchSites(java.lang.String id, java.lang.String[] sites, java.lang.String[] attributsType, java.lang.String[] attributsValue) Permet une recherche de site ayant les attributs cités.

Remarques : Toutes ces API rendent un résultat « null » tant que ce web service n’est pas connecté à l’application « Cadre d’Analyse ».



6.1.5 - LA GESTION DES ATTRIBUTS

Il s’agit des attributs utilisés avec les web services WS-AUTH, WS-USER, et WS-ADMIN. Il y a deux types d’attributs :

- ceux destinées aux utilisateurs, - ceux destinés aux services.

Afin de simplifier le traitement du client du web service, des attributs virtuels gèrent automatiquement les valeurs complexes comme les DN LDAP. Des explications sont données plus loin dans ce chapitre.

Résumé des attributs des APIs des web services LDAP

java.lang.String ATTR_ADD Valeur du champ "ACTION" : permet d'ajouter un attribut

java.lang.String ATTR_DEL Valeur du champ "ACTION" : permet de supprimer un attribut

java.lang.String ATTR_MOD Valeur du champ "ACTION" : permet de modifier un attribut

java.lang.String ATTR_SERVICE_BUSINESSCATEGORY Dérouté : permet de savoir de quel type est le service (ex : "role")

java.lang.String ATTR_SERVICE_CARREFOUR_SEEALSO Permet de lier ce service à un autre DN LDAP.

java.lang.String ATTR_SERVICE_DESCRIPTION Nom abrégé du service

java.lang.String ATTR_SERVICE_SEEALSO Permet de lier ce service à un autre DN LDAP (préférer l'utilisation de "ATTR_SERVICE_CARREFOUR_SEEALSO")

java.lang.String ATTR_USER_BUSINESSCATEGORY Dérouté : permet de savoir quelle est l'ntité juridique employant l'utilisateur.

java.lang.String ATTR_USER_CARREFOUR_BUSINESS Permet de lié un utilisateur avec une position.

java.lang.String ATTR_USER_CARREFOUR_FUNCTION Permet de lié un utilisateur avec une fonction.

java.lang.String ATTR_USER_CARREFOUR_MANAGER Manager de la personne.



java.lang.String ATTR_USER_CARREFOUR_PRIVILEGE_SERVICE Permet de lié un privilege de droit à modification d'un service.

java.lang.String ATTR_USER_CARREFOUR_SECRETARY Secrétaire associée à la personne.

java.lang.String ATTR_USER_CARREFOUR_SEEALSO Permet de connaître/associer le service associé à la personne.

java.lang.String ATTR_USER_COMMONNAME Nom + prénom

java.lang.String ATTR_USER_DEPARTMENTNUMBER Dérouté : permet de savoir quelle est le site de travail principal de l'utilisateur.

java.lang.String ATTR_USER_DESCRIPTION Description de la personne

java.lang.String ATTR_USER_EDUPERSONENTITLEMENT Dérouté pour donner les droits des utilisateurs privilégiés sur un service

java.lang.String ATTR_USER_EDUPERSONORGUNITDN Permet le pontage vers les groupes dynamiques

java.lang.String ATTR_USER_EDUPERSONPRIMARYAFFILIATION Utilisé pour donner la nom de la société du prestataire, inexistant pour un interne

java.lang.String ATTR_USER_EMPLOYEENUMBER Matricule de la personne

java.lang.String ATTR_USER_EMPLOYEETYPE Type d'employé avec les valeurs suivantes : "Contractor", "Employee", "Internal", "Temp", "External", "Unknown"

java.lang.String ATTR_USER_FACSIMILETELEPHONENUMBER Utilisé pour le fax

java.lang.String ATTR_USER_GIVENNAME Prénom

java.lang.String ATTR_USER_INETUSERSTATUS Utilisé pour indiquer si l'utilisateur est actif ou non avec les valeurs suivantes : "active", "inactive", "deleted"

java.lang.String ATTR_USER_INITIALS Initials

java.lang.String ATTR_USER_MAIL Adresse email



java.lang.String ATTR_USER_MANAGER Manager de la personne (préférer l'utilisation de "ATTR_USER_CARREFOUR_MANAGER")

java.lang.String ATTR_USER_MOBILETELEPHONENUMBER Numéro de téléphone du mobile

java.lang.String ATTR_USER_SECRETARY Secrétaire associée à la personne (préférer l'utilisation de "ATTR_USER_CARREFOUR_SECRETARY")

java.lang.String

ATTR_USER_SEEALSO Permet de connaître le service associé à la personne (préférer l'utilisation de "ATTR_USER_CARREFOUR_SEEALSO")

java.lang.String ATTR_USER_SURNAME Nom

java.lang.String ATTR_USER_TELEPHONENUMBER Numéro de téléphone du fixes

java.lang.String ATTR_USER_TELEXNUMBER Utilisé pour le télex

java.lang.String ATTR_USER_TITLE Civilité : "Mr", "Mme", "Melle"

java.lang.String ATTR_USER_UID Login de la personne

Cette liste n’est pas exhaustive. Par exemple, tous les attributs de l’objet LDAP inetOrgPerson sont acceptés.



Voici un exemple d’utilisation des attributs tel qu’il est implémenté dans l’application Pages Jaunes

La cinématique de création d’un service dans « Pages Jaunes » est la suivante :

o création d’un service : appel de wsUser.addService() o affecter un utilisateur au service : appel de wsUser.setUserAttributs()

avec un attribut virtuel (voir §1) o nommer un manager du service : appel de wsUser.setServiceAttributs(

« seeAlso ») o affecter une secrétaire au service : appels de :

getManagerService() puis de setUserAttributs(« secretary » pour le manager)

o récupérer les secrétaires du service : appel de getSecretariesService()

UserUser

User

User

User

ServiceseeAlso

eduPersonOrgUnitDN

secretary(*)

secretary

manager(*)

seeAlso

UserUser

User

User

User

ServiceseeAlso

eduPersonOrgUnitDN

secretary(*)

secretary

manager(*)

seeAlso



ATTENTION : ce type de chaînage ne respecte pas la convention LDAP qui prévoit que l’utilisateur possède les attributs « manager » et « secretary » pointant vers des utilisateurs différents. Ce n’est pas le cas dans l’application Pages Jaunes (voir les attributs avec l’étoile (*)).

Exemple d’utilisation des privilèges et des rôles à travers l’application Pages Jaunes : La partie bleutée est gérée par l’application d’administration AdminRBAC. « Pages Jaunes » peut ajouter ou supprimer des utilisateurs aux différents rôles de « Pages Jaunes » en ajoutant ou supprimant l’attribut « eduPersonOrgUnitDN » vers le service servant de container aux rôles « Pages jaunes ».

UserUser

User

User

User

Service

User (avec roleRH)

seeAlso

eduPersonOrgUnitDN

secretary(*)

secretary

manager(*)

seeAlso

RoleRH

PrivilègesPrivilèges

Privilèges

ServiceRoleRHbussinessCategrory=role

memberURL

eduPersonOrgUnitDN

eduPersonEntitlement

UserUser

User

User

User

Service

User (avec roleRH)

seeAlso

eduPersonOrgUnitDN

secretary(*)

secretary

manager(*)

seeAlso

RoleRH

PrivilègesPrivilèges

Privilèges

ServiceRoleRHbussinessCategrory=role

memberURL

eduPersonOrgUnitDN




Les attributs virtuels : Les attributs virtuels sont destinés à masquer la génération des structures de type “DN” qui ne sont pas accessibles depuis les utilisateurs. If faut donc utiliser impérativement ces attributs virtuels en lieu et place des attributs LDAP définis eux aussi dans le fichier interface Java. Les attributs virtuels sont :

- ATTR_USER_CARREFOUR_SEEALSO - ATTR_USER_CARREFOUR_MANAGER - ATTR_USER_CARREFOUR_SECRETARY - ATTR_USER_CARREFOUR_BUSINESS - ATTR_USER_CARREFOUR_FUNCTION - ATTR_USER_CARREFOUR_PRIVILEGE_SERVICE - ATTR_SERVICE_CARREFOUR_SEEALSO

Leurs fonctions sont décrites dans le schéma ci-dessous ainsi que dans la JavaDoc.

User

User

User

User

User

Service

User (avec roleRH)


User

User

User

User

User

Service

User (avec roleRH)


ATTR_USER_CARREFOUR_PRIVILEGE_SERVICE

ATTR_USER_CARREFOUR_SECRETARY

ATTR_USER_CARREFOUR_SECRETARY ATTR_SERVICE_CARREFOUR_SEEALSO

ATTR_USER_CARREFOUR_MANAGER

ATTR_SERVICE_CARREFOUR_SEEALSO



Les attributs des APIs certificat :

Résumé des attributs java.lang.String ATTR_CERT_STRING_BEGIN_DATE

Date de début de validité du certificat sous la forme du nombre de millisecondes depuis le 1er janvier 1970.

java.lang.String ATTR_CERT_STRING_END_DATE Date de fin de validité du certificat sous la forme du nombre de millisecondes depuis le 1er javier 1970.

java.lang.String ATTR_CERT_STRING_SERIAL_NUMBER Numéro de série du certificat utilisé pour la révocation.

java.lang.String ATTR_CERT_STRING_TYPE Type de certificat (ex: "X.509").

java.lang.String ATTR_CERT_STRING_VERSION Version du certificat (ex: "3").

java.lang.String ATTR_CERT_STRING_ALGORITHME Nom de l'algorithme utilisé (ex: "RSA").

java.lang.String ATTR_CERT_STRING_SERIAL_VERSION_UID Numéro de série de la clé publique.

java.lang.String ATTR_CERT_STRING_REVOK_DATE Date de révocation si elle existe sous la forme du nombre de millisecondes depuis le 1er janvier 1970.

java.lang.String ATTR_CERT_BYTES_PUBLIC_KEY Clé public retournée.

java.lang.String ATTR_CERT_BYTES_EXTENSION_VALUE Retourne les certificats.

java.lang.String ATTR_CERT_BYTES_SIGNATURE Signature du certificat

6.1.6 - LES EXCEPTIONS

Les exceptions émises par le framework sont de deux types : - les exceptions standard Java :

o Exceptions liées à l’accès LDAP et émise par le package JNDI o Exceptions liées à la gestion du container EJB o Exceptions liées à la gestion inter-container c'est-à-dire CORBA o Exceptions liées à la gestion du container Web



o Exceptions liées à la gestion des web service et de SOAP o Exceptions liées à Java lors d’erreur de codage par exemple

- les exceptions applicatives. La classe LdapWsException a pour objectif d’encapsuler les erreurs Java du code s’exécutant dans le container EJB, les erreurs JNDI, ainsi que les erreurs applicatives. La variable d’environnement « lang », décrite au §7.1, a pour fonction d’indiquer à la classe LdapWsException la langue dans laquelle les erreurs émises par OpenLdap doivent être traduites. Ceci a l’avantage de proposer des messages concernant, par exemple, l’erreur de saisie de mot de passe un peu plus parlante que le seul message « Invalid credentials ».

Au niveau des clients des web services, seule l’erreur Java de base est émise pour toutes les exceptions émises depuis le framework LDAP. Ainsi, toutes les exceptions listées ci-dessus sont transformées en exception de base. Seule la description de l’exception devient donc parlante au niveau des clients des web services.



6.2 - AUTHENTIFICATION SSO-WEB

Cette fonction a pour objectif de permettre une authentification unique d’un utilisateur d’applications web. Elle a aussi pour fonction de diminuer les coûts de développement en proposant une page d’authentification LDAP avec la fonction de changement de mot de passe associé. La page login.jsp aura par défaut la forme suivante :



Lors d’un changement de mot de passe, elle prend la forme suivante :



Et lors d’une demande de réinitialisation de mot de passe :

Voici la procédure d’utilisation de la page login.jsp : Le site client est appelé "site applicatif". Il ne contient donc pas de page d'authentification et de changement de mot de passe. Le site d'authentification est appelé "site de login". Pour appeler la page de "login", le site applicatif doit implémenter la ligne suivante ou son équivalent :

response.sendRedirect("http://SiteLogin/LdapCarrefourWeb/login.jsp?fromURL=http://SiteApplicatif/webApp/testloginresult.jsp");

où "fromURL" est l'url de la page appelée en retour. Remarque : Si le site client a besoin en retour de paramètres spécifiques, il peut ajouter ces paramètres de la manière suivante :

http://SiteLogin/LdapCarrefourWeb/login.jsp?fromURL=http://Site



response.sendRedirect("http://SiteLogin/LdapCarrefourWeb/login.jsp?fromURL=http://SiteApplicatif/webApp/testloginresult.jsp?param1=xx&param2=yy");

En retour, le site de login envoi comme paramètre "CSIF_SessionId" au site applicatif. Ce paramètre est codé en BASE64. Voici un exemple de code à implémenter sur le site applicatif pour relire ce paramètre et, ensuite, interroger le web service LDAP :

String strError = null; String strIdCoded = request.getParameter("CSIF_SessionId"); sun.misc.BASE64Decoder decode = new sun.misc.BASE64Decoder(); String strId = new String(decode.decodeBuffer(strIdCoded)); try{ proxy.soap.LdapCarrefourProxy prox = new proxy.soap.LdapCarrefourProxy(); String attrSN[] = prox.getAttribut(strId,"sn");// Recherche de l'attribut SN }catch(Exception e) { strError = "Erreur de connexion"+e.toString(); }

où "proxy.soap.LdapCarrefourProxy" est une classe permettant l'appel du web service LDAP. Cette classe a été générée via l'outil de développement (par exemple WSAD) à partir du fichier "WSDL". Il existe une bibliothèque c4-ldap.jar incluse dans le Framework J2EE simplifiant la mise en place de cette mire. Suivant les besoins propres à chaque projet il pourra être nécessaire d’adapter la page de login à la chartre graphique définie pour le projet. Si tel est le cas, il est possible de renseigner en plus du précédent paramètre fromURL décrit ci-dessus , un second paramètre « cssURL » pointant vers l’url de la feuille de style adaptée au projet . Pour un exemple de mise en place sur le projet de supervision EAI : voir Annexes

http://SiteLogin/LdapCarrefourWeb/login.jsp?fromURL=http://Site



6.3 - APPLICATIONS DE TEST

Il y a une application de test par web service. Pour utiliser les APIs de chaque web service, il est indispensable de disposer d’un id qui n’est disponible que dans le web service WS-AUTH avec l’API login(). Voici l’écran principal de l’application. Il est composé de trois parties :

- à gauche la liste des fonctions disponibles dans le web service WS-AUTH, - en haut à droite, les différents paramètres de la fonction sélectionnée, - en bas à droite, le résultat de l’appel après avoir cliqué sur le bouton « Invoke ».



Voici l’écran pour le web service WS-USER :



Voici l’écran pour le web service WS-ADMIN :



Voici, ci-dessous, l’écran pour le web service WS-SITE. Ce web service n’a pas besoin d’un id pour fonctionner.



6.4 - LES AUTOTESTS

Il y en un par web service Ldap. Leurs buts sont de deux ordres :

- tests des API unitairement avant mise en production d’une nouvelle version du framework LDAP,

- autotests en cours de fonctionnement afin d’indiquer aux différents utilisateurs, dont les développeurs, que la chaîne de liaison framework Ldap plus OpenLdap fonctionne correctement.

Ils se composent d’une page JSP par web service dont des extraits ont été donnés au §5.1. Pour appelé ces autotests, il suffit de cliquer dans le portail sur les liens « Page de test complet » situés dans chacune des sections correspondant aux différents web servces LDAP. On peut y accéder directement en appelant les URLs suivants :

- pour le web service WS-AUTH : http://serveur:port/ LdapCarrefourWeb /autoTestWsAut.jsp

- pour le web service WS-USER : http://serveur:port/ LdapCarrefourWeb /autoTestWsUser.jsp

- pour le web service WS-ADMIN : http://serveur:port/ LdapCarrefourWeb /autoTestWsAdmin.jsp Les résultats de ces autotests pour chacune des APIs exécutées sont affichés dans la page web du navigateur. En cas d’erreur sur une API, les APIs suivantes ne sont pas appelées car des résultats d’une API sont souvent utilisés comme paramètres d’une autre.



7 - LA SECURITE La sécurité des web services est un débat encore ouvert au sein des organismes de normalisation. Il est de fait que les web services sont actuellement sécurisés par des méthodes propriétaires qui ne remettent nullement en cause leurs fonctionnements et leurs fonctionnalités. Le choix Carrefour s’est porté sur différents niveaux de sécurité :

- une réutilisation de l’infrastructure de sécurité en place avec le firewall et le redirector http

- la possibilité d’utiliser des liaisons sécurisées avec le protocole HTTPS - l’auto sécurisation des web services dans lequel nous reviendrons

abondamment dans ce chapitre.

7.1 - LA SECURITE PAR L’INFRASTRUCTURE

Serveur OpenLDAP

ServeursWebsphere

Site d’Evry

LiaisonInternet

Intranet

Extranet

Framework LDAP



Dans le monde Extranet et Internet, elle consiste donc à réutiliser la sécurité déjà activée pour les accès EDI et Web de nos Extranet. Le but de ce document n’étant pas de donner des informations sensibles sur cette infrastructure, il ne sera donc indiqué que ce qui suit :

- un serveur WebSphere (ou plusieurs) est chargé d’un framework LDAP se connectant au serveur OpenLdap. Pour le moment, il n’est pas décidé si un serveur OpenLDAP spécifique mais esclave du serveur OpenLdap intranet sera ou non dédié à ce framework. Si c’était le cas, ce serveur ne serait qu’en lecture seule ce qui impliquerait que seules les API de consultation fonctionneraient. Ce dernier fonctionnement peut-être très préjudiciable à certaines applications.

- le protocole HTTPS sera activé - enfin, la mise en place de certificats permettant d’identifier de manière sûre

l’appelant sera implémentée dans le futur. Evidemment, ces certificats seront certifiés par le Groupe Carrefour afin de fournir une unicité de codage/cryptage vis-à-vis de nos clients et fournisseurs externes à travers le monde.

Important : il faut distinguer une application Extranet hébergée sur un serveur WebSphere Extranet, dune application externe au datacenter de Carrefour. Cependant, dans les deux cas, le serveur hébergeant le framework LDAP sera celui situé dans l’un des serveurs WebSphere extranet. Il n’est pas question de permettre à une application extranet l’accès au framework LDAP intranet directement. Dans le monde Intranet, l’infrastructure est la suivante :

ServeursWebsphere

Application Proxy intranet

Site d’Evry

Serveur OpenLDAP

Framework LDAP



Un serveur WebSphere intranet héberge le framework LDAP. Dans ce modèle, les applications clientes du framework LDAP peuvent être sur le même serveur WebSphere. En cas de défaillance du serveur Websphere hébergeant le framework LDAP, l’utilisation des fermes WebSphere est préconisée permettant une reprise d’activité quasi-instantanée. La condition de fonctionnement conerne les applications appelantes qui devront appeler les web serveur via l’URL générique démarrant ainsi :

http:// ldapcarrefourweb/ LdapCarrefourWeb /….

7.2 - LE PROTOCOLE SSL

Il est nativement implémenté dans WebSphere. Il suffit de l’activer avec la console d’administration WebSphere et de supprimer, si besoin, le protocole http du serveur WebSphere où est installé le framework LDAP. C’est une raison qui milite en faveur de l’installation de deux instances du framework LDAP : un en intranet en http seul pour des considérations de performances, et un en extranet en https seul.

7.3 - L’AUTO-SECURISATION

L’auto-sécurisation consiste à utiliser les possibilités offertes par le framework LDAP pour la gestion des applications pour lui-même. Il s’agit donc de créer une application Ldap dans OpenLdap s’appelant « wsAuth » et disposant de privilèges et de rôles permettant au framework Ldap de savoir si tel utilisateur a le droit ou non d’utiliser une API. Les API ont plusieurs modes :

- en lecture seule, - en écriture, - en modification.

Elles ont des fonctions diverses :

- gestion de « son » profile - gestion d’autres utilisateurs - gestion de services - gestion d’application LDAP



Enfin, elles ont des domaines ou géographie différents qui consiste à savoir si une personne ayant autorité sur une API, peut ou ne peut pas exécuter cet appel. Cela peut-être le cas d’administrateurs fonctionnels qui doivent pouvoir modifier les rôles et privilèges de leur application mais pas ceux d’autres applications. Un autre exemple consiste à vérifier la position géographique d’une demande de modification. Par exemple, un chef de service doit avoir le droit de modifier les informations de son service dans la hiérarchie et pas celle d’un autre service ; idem pour un responsable de Ressources Humaines qui a un domaine alloué et qui ne doit pas en sortir. Ces différentes contraintes imposent donc une vérification à plusieurs niveaux.

7.3.1 - CONTROLE PAR API

Chaque Api des web services dispose d’un privilège associé. Pour les API disposant d’un paramètre « action » permettant d’ajouter, de modifier, et de supprimer un attribut, des privilèges associés à ces actions sont ajoutés. Cela concerne deux API : setUserAttributs et setServiceAttributs. Ainsi, lorsque une API est appelée, le web service concerné vérifie que l’API appelé est autorisée par l’utilisateur concerné donné par son id. Il est évident que la recherche des privilèges n’est pas effectuée à chaque appel d’API, mais uniquement au login et mémorisé dans l’instance de la classe Profil associée à l’utilisateur. Pour le script Java de création : voir Annexes Une fois ce contrôle exécuté, le contrôle par attribut peut être effectué.

7.3.2 - CONTROLE PAR ATTRIBUT

Le contrôle des attributs s’effectue sur les API utilisant des attributs en lecture, écriture, et/ou modification. Seuls certains attributs sont analysés ; ceux ayant un impact important en terme applicatif comme la fonction de la personne par exemple. D’autres attributs ne sont pas contrôlés comme l’email de la personne car n’ayant aucun impact sur l’organisation. Cependant, la modification d’un attribut comme l’email n’est réservé qu’aux personnes authentifiées et ayant le droit de modification d’autrui et/ou de sa propre personne. Des privilèges sont créés pour contrôler les attributs importants. Pour différencier les actions sur ces attributs, des privilèges pour la lecture (GET), la création (ADD), la modification (MOD) et la suppression (DEL) sont créés pour chaque attribut. Cela donne la liste des privilèges suivants :



ATTR_GET_EDUPERSONORGUNITDN

ATTR_GET_UID

ATTR_GET_EMPLOYEENUMBER

ATTR_GET_EDUPERSONPRIMARYAFFILIATION

ATTR_GET_INETUSERSTATUS

ATTR_GET_SEEALSO

ATTR_GET_MANAGER

ATTR_GET_SECRETARY

ATTR_GET_EDUPERSONENTITLEMENT

ATTR_GET_CARREFOURUSERSEEALSO

ATTR_GET_CARREFOURUSERMANAGER

ATTR_GET_CARREFOURUSERSECRETARY

ATTR_GET_BUSINESSCATEGORY

ATTR_GET_DEPARTMENTNUMBER

ATTR_GET_CARREFOURUSERFUNCTION

ATTR_GET_CARREFOURUSERBUSINESS

ATTR_GET_CARREFOURUSERPRIVILEGESERVICE

ATTR_GET_CARREFOURSERVICESEEALSO

ATTR_ADD_EDUPERSONORGUNITDN

ATTR_ADD_UID

ATTR_ADD_EMPLOYEENUMBER

ATTR_ADD_EDUPERSONPRIMARYAFFILIATION

ATTR_ADD_INETUSERSTATUS

ATTR_ADD_SEEALSO

ATTR_ADD_MANAGER

ATTR_ADD_SECRETARY

ATTR_ADD_EDUPERSONENTITLEMENT

ATTR_ADD_CARREFOURUSERSEEALSO

ATTR_ADD_CARREFOURUSERMANAGER

ATTR_ADD_CARREFOURUSERSECRETARY

ATTR_ADD_BUSINESSCATEGORY

ATTR_ADD_DEPARTMENTNUMBER

ATTR_ADD_CARREFOURUSERFUNCTION

ATTR_ADD_CARREFOURUSERBUSINESS

ATTR_ADD_CARREFOURUSERPRIVILEGESERVICE

ATTR_ADD_CARREFOURSERVICESEEALSO

ATTR_MOD_EDUPERSONORGUNITDN

ATTR_MOD_UID

ATTR_MOD_EMPLOYEENUMBER

ATTR_MOD_EDUPERSONPRIMARYAFFILIATION

ATTR_MOD_INETUSERSTATUS



ATTR_MOD_SEEALSO

ATTR_MOD_MANAGER

ATTR_MOD_SECRETARY

ATTR_MOD_EDUPERSONENTITLEMENT

ATTR_MOD_CARREFOURUSERSEEALSO

ATTR_MOD_CARREFOURUSERMANAGER

ATTR_MOD_CARREFOURUSERSECRETARY

ATTR_MOD_BUSINESSCATEGORY

ATTR_MOD_DEPARTMENTNUMBER

ATTR_MOD_CARREFOURUSERFUNCTION

ATTR_MOD_CARREFOURUSERBUSINESS

ATTR_MOD_CARREFOURUSERPRIVILEGESERVICE

ATTR_MOD_CARREFOURSERVICESEEALSO

ATTR_DEL_EDUPERSONORGUNITDN

ATTR_DEL_UID

ATTR_DEL_EMPLOYEENUMBER

ATTR_DEL_EDUPERSONPRIMARYAFFILIATION

ATTR_DEL_INETUSERSTATUS

ATTR_DEL_SEEALSO

ATTR_DEL_MANAGER

ATTR_DEL_SECRETARY

ATTR_DEL_EDUPERSONENTITLEMENT

ATTR_DEL_CARREFOURUSERSEEALSO

ATTR_DEL_CARREFOURUSERMANAGER

ATTR_DEL_CARREFOURUSERSECRETARY

ATTR_DEL_BUSINESSCATEGORY

ATTR_DEL_DEPARTMENTNUMBER

ATTR_DEL_CARREFOURUSERFUNCTION

ATTR_DEL_CARREFOURUSERBUSINESS

ATTR_DEL_CARREFOURUSERPRIVILEGESERVICE

ATTR_DEL_CARREFOURSERVICESEEALSO

En cas d’ajout d’attribut, il suffit juste d’ajouter un attribut respectant la syntaxe ci-dessus dans l’OpenLDAP. Le framework prend dynamiquement ces changements. Une fois ce contrôle exécuté, le contrôle des valeurs des attributs peut être effectué.

7.3.3 - CONTROLE DES VALEURS D’ATTRIBUTS



Le contrôle par valeur est plus délicat et demande des informations internes aux applications clientes des web services LDAP. Afin de contourner la difficulté, des requêtes dynamiques sont créées par type d’attribut. Deux paramètres sont passés à la requête dans cet ordre :

- le nom du type LDAP de l’attribut. En effet, le nom de la requête dynamique est celui du type de paramètre passé en paramètre de l’API d’un web service précédé des caractères « ATTR_DYN_ » ; cela peut-être un attribut virtuel ! Il est donc nécessaire de rechercher quelquefois avec le vrai nom d’attribut LDAP.

- le nom de l’utilisateur au sens du nom donné au login(). Le résultat de la requête dynamique est comparé avec la valeur de l’attribut. Si un des résultats correspond, alors l’accord de sécurité est donné, sinon il y a rejet de sécurité. Voici la liste des requêtes dynamiques actuellement en place : ATTR_DYN_EDUPERSONORGUNITDN

ATTR_DYN_SEEALSO

ATTR_DYN_MANAGER

ATTR_DYN_SECRETARY

ATTR_DYN_CARREFOURUSERSEEALSO

ATTR_DYN_CARREFOURUSERMANAGER

ATTR_DYN_CARREFOURUSERSECRETARY

ATTR_DYN_CARREFOURUSERFUNCTION

ATTR_DYN_CARREFOURUSERBUSINESS

ATTR_DYN_CARREFOURUSERPRIVILEGE_SERVICE

ATTR_DYN_CARREFOURSERVICESEEALSO

Les requêtes par défaut pointent vers une zone de l’organisation « ou=attributes,ou=wsAuth,ou=organizations » où une organisation par attribut doit être ajoutée avec un champ « description » qui sera répété autant de fois que nécessaire. Ces valeurs déterminent celles autorisées pour cet attribut.



7.3.4 - CONTROLE DES APPLICATIONS

Ce contrôle concerne la gestion des applications. Cela permet d’associer des administrateurs fonctionnels à des applications. Pour réaliser cette fonction, une requête dynamique est exécutée en utilisant le nom de l’application comme nom de requête précédé des caractères « APP_ ». Le résultat est comparé au nom de l’utilisateur loggé. Si un résultat correspond, alors l’accord de sécurité est donné, sinon, il est refusé. Voici la liste des applications traitées par défaut : APP_wsAuth

APP_applicationtest

APP_gefx

APP_logicarbnet

APP_intradoctelecom

APP_WebOffresPFT

APP_STAR

Remarque : cette requête dynamique est créée automatiquement lors de la création d’une application.

7.3.5 - LES ROLES PAR DEFAUT

Cinq rôles sont créés par défaut en utilisant le principe RBAC mis en place dans OpenLdap. Ces rôles, en résumés, sont : - user : c’est un utilisateur de base. Il peut exécuter toutes les Apis qui sont en lecture et modifier les attributs le concernant exceptés ceux concernant son manager, les ressources humaines, les administrateurs fonctionnels d’applications. -administrator : il a tous les pouvoirs sauf sur le contenu des applications fonctionnelles. - adminannu : comme administrator sauf qu’il ne peut modifier l’application lié à la sécurité du framework LDAP « wsAuth » - adminfonc : il ne peut modifier que les privilèges, rôles , requêtes dynamiques de ou des applications auxquelles il est attaché. - adminuser : il ne peut modifier que le mot de passe d’autres utilisateurs. - RH : Ressources Humaines : réservé à l’application Pages Jaunes. Cela permet à cette application de donner des droits à des utilisateurs sur la gestion des personnes et des services en positionnant vers une arborescence les utilisateurs considérés. Pour cela, il suffit d’ajouter l’attribut « eduPersonOrgUnit » vers le répertoire associé. - manager : réservé aux responsables de services pour l’application Pages Jaunes. Fonctionnement identique.



Voici le tableau d’associations rôles/privilèges de « wsAuth » :

privilèges user

adm

inis

trat

or

adm

inan

nu

adm

info

nc

RH

man

ager

adm

inus

er

user

Mor

e

supp

lier

supp

liera

dmin

supp

liera

dmin

dele

gate

supp

liere

nrol

lmen

t

hotL

ine

user

Org

Des

c

suiv

iPro

duct

ion

adm

inD

SO

ADMIN_CONFIG X X X X X X X ADMIN_CREATEUSER X X X X X ATTR_ADD_BUSINESSCATEGORY X X X X X X X ATTR_ADD_CARREFOURSERVICESEEALSO X X X ATTR_ADD_CARREFOURUSERBUSINESS X X X ATTR_ADD_CARREFOURUSERFUNCTION X X X ATTR_ADD_CARREFOURUSERMANAGER X X X ATTR_ADD_CARREFOURUSERPRIVILEGESERVICE X X X ATTR_ADD_CARREFOURUSERSECRETARY X X X ATTR_ADD_CARREFOURUSERSEEALSO X X X ATTR_ADD_DEPARTMENTNUMBER X X X X ATTR_ADD_EDUPERSONENTITLEMENT X X X ATTR_ADD_EDUPERSONORGUNITDN X X X X X X X X X ATTR_ADD_EDUPERSONPRIMARYAFFILIATION X X X X X X X ATTR_ADD_EMPLOYEENUMBER X X X ATTR_ADD_INETUSERSTATUS X X X X X X ATTR_ADD_MANAGER X X X ATTR_ADD_SECRETARY X X X ATTR_ADD_SEEALSO X X X ATTR_ADD_UID X X X X X X ATTR_DEL_BUSINESSCATEGORY X X X X ATTR_DEL_CARREFOURSERVICESEEALSO X X X ATTR_DEL_CARREFOURUSERBUSINESS X X X ATTR_DEL_CARREFOURUSERFUNCTION X X X ATTR_DEL_CARREFOURUSERMANAGER X X X ATTR_DEL_CARREFOURUSERPRIVILEGESERVICE X X X ATTR_DEL_CARREFOURUSERSECRETARY X X X ATTR_DEL_CARREFOURUSERSEEALSO X X X ATTR_DEL_DEPARTMENTNUMBER X X X X ATTR_DEL_EDUPERSONENTITLEMENT X X X ATTR_DEL_EDUPERSONORGUNITDN X X X X X X X X X ATTR_DEL_EDUPERSONPRIMARYAFFILIATION X X X X ATTR_DEL_EMPLOYEENUMBER X X X ATTR_DEL_INETUSERSTATUS X X X ATTR_DEL_MANAGER X X X ATTR_DEL_SECRETARY X X X ATTR_DEL_SEEALSO X X X ATTR_DEL_UID X X X ATTR_GET_BUSINESSCATEGORY X X X X X X X ATTR_GET_CARREFOURSERVICESEEALSO X X X X X X X ATTR_GET_CARREFOURUSERBUSINESS X X X X X X X ATTR_GET_CARREFOURUSERFUNCTION X X X X X X X ATTR_GET_CARREFOURUSERMANAGER X X X X X X X ATTR_GET_CARREFOURUSERPRIVILEGESERVICE X X X X X X X



ATTR_GET_CARREFOURUSERSECRETARY X X X X X X X ATTR_GET_CARREFOURUSERSEEALSO X X X X X X X ATTR_GET_DEPARTMENTNUMBER X X X X X X X ATTR_GET_EDUPERSONENTITLEMENT X X X X X X X ATTR_GET_EDUPERSONORGUNITDN X X X X X X X ATTR_GET_EDUPERSONPRIMARYAFFILIATION X X X X X X X ATTR_GET_EMPLOYEENUMBER X X X X X X X ATTR_GET_INETUSERSTATUS X X X X X X X ATTR_GET_MANAGER X X X X X X X ATTR_GET_SECRETARY X X X X X X X ATTR_GET_SEEALSO X X X X X X X ATTR_GET_UID X X X X X X X ATTR_MOD_BUSINESSCATEGORY X X X X X X X ATTR_MOD_CARREFOURSERVICESEEALSO X X X ATTR_MOD_CARREFOURUSERBUSINESS X X X ATTR_MOD_CARREFOURUSERFUNCTION X X X ATTR_MOD_CARREFOURUSERMANAGER X X X ATTR_MOD_CARREFOURUSERPRIVILEGESERVICE X X X ATTR_MOD_CARREFOURUSERSECRETARY X X X ATTR_MOD_CARREFOURUSERSEEALSO X X X ATTR_MOD_DEPARTMENTNUMBER X X X X ATTR_MOD_EDUPERSONENTITLEMENT X X X ATTR_MOD_EDUPERSONORGUNITDN X X X X X X X X ATTR_MOD_EDUPERSONPRIMARYAFFILIATION X X X X X X X ATTR_MOD_EMPLOYEENUMBER X X X ATTR_MOD_INETUSERSTATUS X X X X X X X ATTR_MOD_MANAGER X X X ATTR_MOD_SECRETARY X X X ATTR_MOD_SEEALSO X X X ATTR_MOD_UID X X X addAdmApplication X X addAdmDynamic X X X addAdmOrganization X X X X addAdmPrivilege X X X addAdmRole X X X addService X X X addUser X X X X X X X X deleteAdmApplication X X deleteAdmDynamic X X X deleteAdmOrganization X X X deleteAdmPrivilege X X X deleteAdmRole X X X deleteService X X X deleteUser X X X X X X getAdmApplicationDescription X X X X X X X getAdmApplications X X X X X X X X getAdmChildOrganizations X X X X X getAdmDynamicDescription X X X X X X getAdmDynamics X X X X getAdmGroupOfUsersForRole X X X X getAdmIdActives X X X X X X X getAdmMemberURLForDynamic X X X X getAdmObjectAttributs X X X X X X X X getAdmOrganizationAttribut X X X X X getAdmOrganizationDescription X X X X X X X X getAdmOrganizations X X X X X getAdmParam X X X X X X X getAdmPrivilegeDescription X X X X X X X getAdmPrivileges X X X X



getAdmPrivilegesForRole X X X X getAdmRoleDescription X X X X X X getAdmRoles X X X X getAdmUsersForRole X X X X getAttribut X X X X X X X getBussiness X X X X X X X getCert X X X X X X X getCertByteAttribut X X X X X X X getCertStringAttribut X X X X X X X getChildServices X X X X X X X getDynamics X X X X X X X X getFunctions X X X X X X X getManagerService X X X X X X X getParentService X X X X X X X getPrivileges X X X X X X X X getRoles X X X X X X X X getSecretariesService X X X X X X X getServiceAttributs X X X X X X X getServices X X X X X X X getSites X X X X X X X getUserAttributs X X X X X X X getUserCert X X X X X X X getUserCertByteAttribut X X X X X X X X X getUserCertStringAttribut X X X X X X X X X getUsersAttribut X X X X X X X X isNotRevokedCert X X X X X X X isNotRevokedUserCert X X X X X X X X isValidCert X X X X X X X isValidUserCert X X X X X X X searchAdmOrganizationForAttribut X X X searchUsers X X X X X X X X setAdmGroupOfUsersForRole X X X setAdmMemberURLForDynamic X X X setAdmOrganizationAttribut X X X X setAdmParam X X setAdmPrivilegesForRole X X X setAdmUsersForRole X X X setServiceAttributs_ADD X X X setServiceAttributs_DEL X X X setServiceAttributs_MOD X X X X setUserAttributs_ADD X X X X X X X setUserAttributs_DEL X X X X X X X setUserAttributs_MOD X X X X X X setUserPassword X X X stopAdmIdActive X X X X



7.3.6 - L’ORGANISATION DE « WSAUTH »

Afin d’apporter une grande souplesse dans la gestion des rôles décrits ci-dessous, une organisation a été ajoutée dans OpenLdap. Son chemin est :

ou=wsAuth, ou=organizations, dc=fr, dc=carrefour,dc=com

A l’intérieur de cette organisation, des entités suivantes sont créées :

- cn = administrators - cn = adminannus - cn = RHs - cn = managers - cn = adminfoncs

Sous « adminfoncs » d’autres entités sont créées qui correspondent aux noms des applications. Ceci permet de réserver des administrateurs fonctionnels « adminannu » aux applications qui seuls seront accréditer à visualiser et modifier le contenu. Par exemple :

cn=APP_applicationtest, cn=adminfoncs, ou=wsAuth, ou=organizations, …

Remarque : une entité est créée automatiquement lors de la création d’une application. Il n’y a plus qu’à associer des utilisateurs à ces organisations pour leur ajouter le rôle associé. Pour cela il suffit d’ajouter l’attribut « eduPersonOrgUnitDn » comme ceci :

cn=administrators,ou=wsAuth,ou=organizations,dc=fr,dc=carrefour,dc=com

On peut obtenir, par exemple, pour un utilisateur, une liste de valeurs pour cet attribut comme suit :



L’utilisation de l’application RBAC permet de créer facilement cette association. D’autre part, comme expliqué au paragraphe §6.3.3 ; une branche LDAP est créée sous « ou=attributes,ou=wsAuth,ou=organizations » afin de gérer les requêtes dynamiques en charge du contrôle des valeurs d’attributs. Comme ces requêtes dynamiques peuvent disposer du nom d’utilisateur, il est possible de modifier les requêtes dynamiques afin de les faire pointer sous une organisation de ce type : « ou=xxxx,ou=attributes,ou=wsAuth,ou=organizations » où « xxxx » est le nom de l’utilisateur. Ainsi, pour certains utilisateurs, l’accès à certains chemins LDAP (appelés « DN ») sera autorisé si ces chemins sont indiqués dans l’attribut « description ».



8 - TRACES, STATISTIQUES

8.1 - TRACES

Les traces sont activables via les variables d’environnement décrites dans le dossier d'installation FrameWork. Il est conseillé de ne pas activer toutes les traces simultanément afin de ne pas ralentir trop le système. Le résultat des traces se retrouve dans le fichier de sortie standard de la JVM. Pour accéder à ce fichier depuis la console WebSphere, suivre la procédure suivante :

1- Aller dans le menu Résolution des incidents Journaux et traces [nom du serveur d’entreprise où s’exécute le framework LDAP] Journaux de la JVM 2 – Cliquer sur l’onglet « Execution » 3 – Cliquer sur le bouton « Affichage » de la ligne concernant le fichier « System.out » 4 – choisir les dernières lignes par rapport au nombre de lignes indiquées du fichier et cliquer sur « Régénération » 5- Visualiser les traces. Sous Jboss, les traces apparaitront (par défaut) dans la trace système ( log/server.log ).



8.2 - STATISTIQUES

La page « Statistiques LDAP » accessible depuis le portail dans la partie « Application de gestion des privilèges et roles », donne des informations de deux types : 1 – la valeur des paramètres de configuration,



2 – des statistiques de fonctionnement générales.

Les paramètres de lancement sont ceux décrits dans le document d’installation. Nous n’y reviendrons pas.



Les statistiques concernent l’instance du framework en cours, mais également la somme de toutes les instances pour les compteurs suivants :

Compteur Description

Nb Frameworks nombre d’instance de framework utilisé pour l’environnement en cours.

nb ID ouverts nombre courant d’ID utilisateurs ouverts. Cela correspond au nombre de login() effectués et non fermé sur timeout.

nb ouvertures ID depuis le "xxx " nombre d’ID ouvert depuis le lancement du framework.

nb EJB créés nombre d’instances d’EJB lancées par le container EJB pour répondre aux demandes des utilisateurs.

nb EJB supprimés nombre d’instances d’EJB supprimées par le container EJB qui considérait qu’elles devenaient inutiles.

nb EJB mémorisés nombre d’instances d’EJB lancées puis mises en mémoire pour une utilisation future.

nb EJB réactivés nombre d’instances d’EJB lancées qui ont été mise en mémoire puis réactivée par besoin par le container EJB.

nb EJB actifs nombre d’instances d’EJB en cours de fonctionnement. Il s’agit du nombre d’EJB créés moins ceux qui ont été supprimés et mémorisés.



9 - CONCEPTION DETAILLEE Les fonctionnalités principales du framework LDAP sont résumées dans les cas d’utilisations suivants :

On retrouve les différents acteurs qui ont été décrit dans le chapitre §6.3.5. Afin de ne pas surcharger ce schéma, les simples utilisateurs sont représentés par les applications.



Revenons au container EJB et à sa liste de classes :

Inte

rface

Loc

ale

Inte

rface

Rem

ote

Ldap

WsB

ean

(exp

ositi

on s

ervi

ces

& g

estio

n sé

curit

é)

Ldap

Use

rId

Con

text

répa

rti(p

acka

ge p

ersi

sten

ce)

Les différentes classes sont :

- LdapWsBean qui est le point d’entré de l’EJB. Cette classe a pour objectif de re-créer le mode session inexistant dans un EJB sans état et dans les web services. Cette session représente un id utilisateur et non pas un client de l’EJB. En effet, plusieurs applications utilisant un même id seront identifiées comme identiques. C’est ici que la gestion de la sécurité au niveau API est implémentée.

- LdapUserId qui contient tous les services. - LdapWsUserId qui gère totalement l’environnement d’un id. Cette classe reste

active le temps d’un timer d’activité mis en œuvre à travers la classe LdapWsGc (Garbage Collector). Elle encapsule la classe Profil.

- LdapWsException est la classe d’exceptions du framework - LdapWsGc est le timer d’inactivité. Il a en charge le nettoyage des id lorsque

ceux-ci n’ont pas été utilisés depuis un laps de temps configuré en paramètre d’installation.

- Stats est un singleton. Il est lancé au démarrage du container et a pour objectif de contenir les variables correspondant aux paramètres de configuration (voir Dossier d’installation), ainsi que les compteurs pour les statistiques.

- OoLdap est une classe ayant pour objet une recherche récursive dans les chemins Ldap. Elle est utilisée pour les méthodes getPrivileges() et getRoles().

- Profil est une classe de stockage des données d’un id. Les attributs correspondants à un utilisateur sont stockés afin de les rendre persistants et d’économiser ainsi du trafic vis-à-vis de l’OpenLdap. Les privilèges liés à la



sécurité de l’utilisateur, ainsi que de toutes les demandes de getPrivileges() et de getRoles() y sont aussi stockés.

Il faut ajouter a cela :

- PasswordMaker qui s’occupe de la génération aléatoire d’un nouveau mot de passe.

- CaptchaMaker qui s’occupe de la génération de l’image de type ‘captcha’ d’un mot (utilisée pour le password)

- JMSSender / MDBMail qui permet l’envoi asynchrone de mail à l’utilisateur. - Le package persistence qui contient les DAOs pour sauvegarder le contexte

local dans la base répartie (Sequioa/HsqlDB). Il permet également le tracage de tous les appels aux APIs. Cette trace peut être redirigé dans une autre base que celle contenant le contexte ldap répartie.

Le diagramme de séquence suivant montre l’enchaînement d’actions exécutées lors de la phase de l’appel de login() d’un utilisateur. On voit nettement que la classe LdapWsBean qui est le point d’entrée de l’EJB session, créé une instance de classe LdapWsUserId.



Dans le diagramme suivant, l’appel à la méthode getPrivileges() montre bien le rôle de façade d’EJB constitué par la classe LdapWsBean vis-à-vis du contexte utilisateur qui est constitué de la classe LdapWsUserId. On voit aussi que le contrôle de sécurité est fait via la méthode isAuth(…) de LdapWsUserId avant tout appel de méthode en provenance de l’utilisateur distant.



Dans le diagramme suivant, on voit le travail réalisé en interne pour toujours un appel à getPrivileges(). L’objet OoLdap est sollicité et les résultats trouvés sont stockés dans l’instance de classe Profil.



Le diagramme de classes suivant montre le rôle central exécuté par le singleton Stats pour le stockage et la lecture des paramètres et compteurs. On voit aussi la liste des exceptions traitées dans la classe LdapWsException.



Le diagramme des classes suivant montre les classes Java du container web LdapCarrefourWs. On voit nettement apparaître une classe par web service associé à une interface. Chacune des interfaces est utilisée pour la Javadoc associée à chaque web service. Enfin, la classe LdapWsAttributs contient l’ensemble de la liste des attributs connus ce jour.

La description de chacun des fichiers des deux containers web est fastidieuse et peu productive car la compréhension de la fonction de chacun des fichiers est évidente. Par contre, nous nous attarderons sur les tâches à effectuer leur d’une livraison du framework. ATTENTION : Tous ces diagrammes de classes ne sont plus à jour : beaucoup de méthodes ont été ajoutés mais l’organisation, elle, n’a pas changé.



Pour rappel, seul un fichier EAR est livré à la production. Il est constitué ainsi :

Dans le fichier EAR, les contraintes de sécurité liées à la machine J2EE sont ajoutées automatiquement grâce au fichier « was.policy ». Le fichier « application.xml » contient la liste des containers du fichier EAR. Avant de fabriquer ce fichier EAR, plusieurs étapes sont auparavant nécessaires :

- si les interfaces de l’EJB sont changées, il est nécessaire de redéployer l’EJB via l’assistant contenu dans WSAD (RMID). Il faut de même modifier les classes de définition des web services dans le container LdapCarrefourWs pour les interfaces (API) modifiées.

- il peut être nécessaire de régénérer les web services dans le container LdapCarrefourWs en utilisant l’assistant de WSAD réservé à cet effet. Il est recommandé de supprimer le répertoire « Web Content/wsdl » avant d’exécuter l’assistant. Attention, les proxys générés dans le container LdapCarrefourWeb doivent être modifiés afin d’y inclure manuellement le code de lecture du paramètre « ldapWsURL ».

- si le fichier « LdapWsAttributs.java » a été modifié depuis la dernière livraison, il est nécessaire de recopier ce fichier dans le répertoire « Web Content » de WSAD.



- mettre à jour le fichier « journal.java » avec les dernières modifications. Changer la version des fichiers modifiés.

- régénérer la javadoc du container web LdapCarrefourWs en utilisant l’assistant correspondant de WSAD (contenu dans « export ») et en copiant les fichiers javadoc dans le container web LdapCarrefourWeb.

- enfin, lancer l’assistant de génération du fichier EAR en y incluant les sources. Considérations concernant la sécurité : Il est peut-être nécessaire de mettre à jour les règles de sécurité incluses dans OpenLdap. Il ne faut pas modifier ces règles via le navigateur OpenLdap, sous risque de créer des incohérences. Le fichier «Web Content/testsbug/initsecu.jsp » contenu dans le web container LdapCarrefourWeb permet de réinitialiser toutes ces règles en utilisant l’utilisateur FRTEST1. Pour exécuter ce fichier, il est nécessaire d’inhiber la sécurité du framework en modifiant la méthode isAuth() de la classe LdapWsUserId afin de la rendre inopérante (appeler cette méthode isAuthV() et créer une méthode isAuth() vide). Puis lancer « Content/testbug/initsecu.jsp » depuis WSAD. Remettre en place isAuth(), tester, et générer un fichier LDIF pour livraison. Considérations concernant les données OpenLdap pour le framework : Il est important de livrer un fichier LDIF à coté du fichier EAR contenant les modifications à apporter aux objets OpenLdap nécessaire au fonctionnement du framework. Cela concerne essentiellement les DNs suivants : « ou=applicationtest, ou=applications, dc=fr, dc=carrefour,dc=com » « ou=wsAuth, ou=applications, dc=fr, dc=carrefour,dc=com » « ou=wsAuth, ou=organizations, dc=fr, dc=carrefour,dc=com » « uid=FRTEST0, ou=people, dc=fr, dc=carrefour,dc=com » « uid=FRTEST1, ou=people, dc=fr, dc=carrefour,dc=com » « uid=FRTEST2, ou=people, dc=fr, dc=carrefour,dc=com » « uid=FRTEST3, ou=people, dc=fr, dc=carrefour,dc=com » « uid=FRTEST4, ou=people, dc=fr, dc=carrefour,dc=com » « uid=FRTEST5, ou=people, dc=fr, dc=carrefour,dc=com » , et en partie : « ou=hierarchy, ou=organizations, dc=fr, dc=carrefour,dc=com »



10 - ACTEURS ET APPLICATIONS UTILISATRICES Au 18.4.2005, les applications utilisatrices sont les suivantes :

- la Centrale de réservation : cette application gère les demandes de formations venant des magasins.

- Pages Jaunes : cette application est un annuaire doublé d’un GDU permettant de situer les organisations et les personnes associées.

- intradoctelecoms : cette application est destinées aux employés de la téléphonie.

- fidélité : gestion de la fidélité hypermarchés - BOFI : gestion du back office financier (lié à la fidélite) - PRICING : gestion des prix en hypermarchés - VPN : contrôle accès VPN et PKI - RSVI :

D’autres applications vont venir prochainement :

- intrafuel : gestion de l’essence - ulysse : gestion des notes de frais

Les acteurs du projet sont les suivants : - garant du projet : Thierry Chabrol - responsable système OpenLdap : Marin Le Houelleur - responsable du framework LDAP : Pascal Ortoli - responsable développement framework LDAP : Thierry Carcelès - garant LDAP : Pascal Leydier - production : équipe Unix/WebSphere de production

Le framework LDAP (avec OpenLdap) est maintenant en place, et son utilisation est désormais obligatoire pour toutes les applications Carrefour demandant une authentification.



ANNEXES

10.1 - EXEMPLE D’UTILISATION DES API DE WS-AUTH :

try { // Intentiation du proxy WS-AUTH proxy.soap.LdapWsAuthProxy ll = new proxy.soap.LdapWsAuthProxy(); // Recherche d’un id pour l’utilisateur « FRTEST0 » String id = ""; try{ id = ll.login("FRTEST0","PASSWORD"); }catch(Exception e) { System.out.println("Erreur de connexion"+e.toString()); } // Recherche de l’adresse email de FRTEST0 String val[] = ll.getAttribut(id,"mail"); if (val != null){ for (int ii = 0;ii < val.length;ii++){ System.out.print(val[ii]+" , "); } } // Recherche des privilèges de FRTEST0 pour l’application “applicationtest” val = ll.getPrivileges(id,"applicationtest"); if (val != null) { for (int ii = 0;ii < val.length;ii++){ System.out.print(val[ii]+" , "); } } // Recherche des rôles de FRTEST0 pour l’application “applicationtest” val = ll.getRoles(id,"applicationtest"); if (val != null) { for (int ii = 0;ii < val.length;ii++){ System.out.print(val[ii]+" , "); } } // Recherche du résultat de l’éxécution de la requête dynamique « test1 » // de l’application “applicationtest” String params [] = new String[2]; params[0] = new String("01022"); params[1] = new String("14470"); val = ll.getDynamics(id,"applicationtest","test1",params); if (val != null) { for (int ii = 0;ii < val.length;ii++){ System.out.print(val[ii]); } } } catch (Exception e) { // Traitement des erreurs System.out.println("Erreur :"+e.getMessage()); }



10.2 - EXEMPLE D’UTILISATION DES API DE WS-USER EN JAVA :

String id = ""; try { LdapWs ldapws[]; // liste des articles // Intentiation du proxy WS-AUTH pour l’appel à « login() » proxy.soap.LdapWsAuthProxy wsAuth = new proxy.soap.LdapWsAuthProxy(); // Intentiation du proxy WS-USER proxy.soap.LdapWsUserProxy wsUser = new proxy.soap.LdapWsUserProxy(); try{ id = wsAuth.login("FRTEST4","PASSWORD"); }catch(Exception e) { System.out.println("Erreur de connexion"+e.toString()); } // Création d’un utilisateur « FRXXXXY » String[] attrsTyp = new String[2]; String[] attrsVal = new String[2]; attrsTyp[0] = "cn"; attrsVal[0] = "moi"; attrsTyp[1] = "sn"; attrsVal[1] = "moi"; wsUser.addUser(id,"FRXXXXY",attrsTyp,attrsVal); // Modification des attributs de l’utilisateur « FRXXXXY » String[] attrsTyp2 = new String[11]; String[] attrsVal2 = new String[11]; attrsTyp2[0] = "telephoneNumber"; attrsVal2[0] = "010203040506"; attrsTyp2[1] = "mail"; attrsVal2[1] = "moi@moi"; attrsTyp2[2] = "givenName"; attrsVal2[2] = "Pascal"; attrsTyp2[3] = "eduPersonEntitlement"; attrsVal2[3] = "Architecte"; attrsTyp2[4] = "initials"; attrsVal2[4] = "P L"; attrsTyp2[5] = "employeeNumber"; attrsVal2[5] = "50004000"; attrsTyp2[6] = "employeeType"; attrsVal2[6] = "Employee"; attrsTyp2[7] = "eduPersonPrimaryAffiliation"; attrsVal2[7] = "CSIF"; attrsTyp2[8] = "inetUserStatus"; attrsVal2[8] = "active"; attrsTyp2[9] = "telexNumber"; attrsVal2[9] = "09090909"; attrsTyp2[10] = "description"; attrsVal2[10] = "employé modèle"; wsUser.setUserAttributs(id,"FRXXXXY",attrsTyp2,attrsVal2,"ADD"); // Lecture des attributs de l’utilisateur « FRXXXXY » String[] attrsTypR1 = new String[2]; attrsTypR1[0] = "telephoneNumber";



attrsTypR1[1] = "mail"; String [] resultR1 = wsUser.getUserAttributs(id,"FRXXXXY",attrsTypR1,"[PAD]"); System.out.println("tel : "+resultR1[0]); System.out.println("mail : "+resultR1[1]); // Modifie des attributs de l'utilisateur "FRXXXXY" : <% String[] attrsTyp3 = new String[2]; String[] attrsVal3 = new String[2]; attrsTyp3[0] = "telephoneNumber"; attrsVal3[0] = "7777777"; attrsTyp3[1] = "mail"; attrsVal3[1] = "[email protected]"; wsUser.setUserAttributs(id,"FRXXXXY",attrsTyp3,attrsVal3,"MOD"); // Lit des attributs de plusieurs utilisateurs "FRXXXXY" et "FRTEST0" : <% String[] logins = new String[2]; logins[0] = "FRXXXXY"; logins[1] = "FRTEST0"; String [] resultMails = wsUser.getUsersAttribut(id,logins,"mail","[PAD]"); System.out.println("mail de \""+logins[0]+"\" est : "+resultMails[0]); System.out.println("mail de \""+logins[1]+"\" est : "+resultMails[1]); //Supprime des attributs de l'utilisateur "FRXXXXY" : String[] attrsTyp4 = new String[2]; String[] attrsVal4 = new String[2]; attrsTyp4[0] = "telephoneNumber"; attrsVal4[0] = null; attrsTyp4[1] = "mail"; attrsVal4[1] = null; wsUser.setUserAttributs(id,"FRXXXXY",attrsTyp4,attrsVal4,"DEL"); //Supprime l'utilisateur "FRXXXXY" : wsUser.deleteUser(id,"FRXXXXY"); // Recherche des utlisateurs : String[] attrsTyp5 = new String[2]; String[] attrsVal5 = new String[2]; attrsTyp5[0] = "eduPersonOrgUnitDN"; attrsVal5[0] = "cn=MSC,ou=Fonctions,ou=HYPER,ou=organizations,dc=fr,dc=carrefour,dc=com"; attrsTyp5[1] = "eduPersonPrimaryOrgUnitDN"; attrsVal5[1] = "cn=GGFR0045,ou=Magasins,ou=HYPER,ou=organizations,dc=fr,dc=carrefour,dc=com"; String [] resUser = wsUser.searchUsers(id,null,attrsTyp5,attrsVal5); for (int ii = 0; ii < resUser.length ; ii ++){ System.out.println("utilisateurs ["+ii+"] : "+resUser[ii]); } // Test des services //Liste des services de premier niveau : String[] lstServ = wsUser.getServices(id); for (int ii = 0; ii < lstServ.length ; ii ++){ System.out.println("service ["+ii+"] : "+lstServ[ii]); } //Création d'un service :

mailto:[email protected]



String newServId = wsUser.addService(id,"new1",lstServ[0],null,null); System.out.println(" service créé : "+newServId); //Ajoute des attributs au service : String[] attrsTypS1 = new String[2]; String[] attrsValS1 = new String[2]; attrsTypS1[0] = "postalCode"; attrsValS1[0] = "010203040506"; attrsTypS1[1] = "description"; attrsValS1[1] = "mon service"; wsUser.setServiceAttributs(id,newServId,attrsTypS1,attrsValS1,"ADD"); // Lit des attributs du service : String[] attrsTypS2 = new String[2]; attrsTypS2[0] = "postalCode"; attrsTypS2[1] = "description"; String [] resultS2 = wsUser.getServiceAttributs(id,newServId,attrsTypS2,"[PAD]"); System.out.println("postalCode : "+resultS2[0]); System.out.println("description : "+resultS2[1]); //Création d'un service : String newServ2Id = wsUser.addService(id,"new2",lstServ[0],null,null); System.out.println("service créé : "+newServ2Id); //Liste des services enfants de : String[] lstServ2 = wsUser.getChildServices(id,lstServ[0]); for (int ii = 0; ii < lstServ2.length ; ii ++){ System.out.println("service ["+ii+"] : "+lstServ2[ii]); } //Liste le service parent de : String lstServParent = wsUser.getParentService(id,newServId); System.out.println("service parent : "+lstServParent); //Suppression d'un service : wsUser.deleteService(id,newServId); //Suppression d'un service : wsUser.deleteService(id,newServ2Id); //Liste des métiers : String [] business = wsUser.getBussiness(id,lstServ[0],"<li>"); for (int ii = 0; ii < business.length ; ii ++){ System.out.println("metier ["+ii+"] : "+business[ii]); } //Liste des fonctions : String [] functions = wsUser.getFunctions(id,lstServ[0],"<li>"); for (int ii = 0; ii < functions.length ; ii ++){ System.out.println("fonction ["+ii+"] : "+functions[ii]); } } catch (Exception e) { System.out.println("Error :"+e.getMessage()); }



10.3 - EXEMPLE D’UTILISATION DES API DE WS-USER EN .NET : Dim oHab As New LdapWsAuth.LdapWsIntService() Dim oUser As New LdapWsUser.LdapWsUserIntService() Dim Jeton As String Dim Nom As String() Dim lstServices As String() Dim lstAttributs As String() = {"employeeNumber", "CarrefourUserSeeAlso"} Dim lstValeurs As String() Const attrPAD As String = "|" Try ' Si l'on souhaite contrôler le timeOut : ' oHab.Timeout = timer.Text oHab.Url = "http://annuuddi.fr.carrefour.com/LdapCarrefourWeb/servlet/rpcrouter <http://annuuddi.fr.carrefour.com/LdapCarrefourWeb/servlet/rpcrouter>" Jeton = oHab.login(Login.Text, Password.Text) csif_sessionId.Text = Jeton Nom = oHab.getAttribut(Jeton, "sn") sn.Text = Nom(0) Catch err As SoapException ' Pour la gestion des exceptions applicatives levées par le Web Service Auth csif_sessionId.Text = err.Message Exit Sub Catch err As WebException ' Pour la gestion du timeout ou d'autres exceptions SOAP csif_sessionId.Text = err.Message Exit Sub End Try ' Si l'on souhaite contrôler le timeOut : ' oUser.Timeout() = timer.Text Try oUser.Url = "http://annuuddi.fr.carrefour.com/LdapCarrefourWeb/servlet/rpcrouter <http://annuuddi.fr.carrefour.com/LdapCarrefourWeb/servlet/rpcrouter>" lstServices = oUser.getServices(Jeton) allServices.Text = lstServices(0) lstValeurs = oUser.getUserAttributs(Jeton, Login.Text, lstAttributs, attrPAD) myService.Text = lstValeurs(0) & " + " & lstValeurs(1) & " + " & lstValeurs(2) Catch err As SoapException ' Pour la gestion des exceptions applicatives levées par le Web Service User myService.Text = err.Message Catch err As WebException ' Pour la gestion du timeout ou d'autres exceptions SOAP myService.Text = err.Message End Try

http://annuuddi.fr.carrefour.com/LdapCarrefourWeb/servlet/rpcrouter






10.4 - EXEMPLE D’UTILISATION DES API DE WS-ADMIN EN JAVA :

String id = ""; try { LdapWs ldapws[]; // Intentiation du proxy WS-ADMIN proxy.soap.LdapWsAdminProxy wsAdmin = new proxy.soap.LdapWsAdminProxy(); // Intentiation du proxy WS-AUTH pour l’appel à « login() » proxy.soap.LdapWsAuthProxy wsAuth = new proxy.soap.LdapWsAuthProxy(); // Intentiation du proxy WS-USER proxy.soap.LdapWsUserProxy wsUser = new proxy.soap.LdapWsUserProxy(); try{ id = wsAuth.login("FRTEST2","PASSWORD"); }catch(Exception e) { System.out.println("Erreur de connexion"+e.toString()); } //Liste des applications : String[] resAdmin = wsAdmin.getAdmApplications(id); for (int ii = 0; ii < resAdmin.length ; ii ++){ System.out.println(resAdmin[ii]); } //Création d'une application : "MonApplication" wsAdmin.addAdmApplication(id,"MonApplication","Ma description d'application"); //Liste des applications : resAdmin = wsAdmin.getAdmApplications(id); for (int ii = 0; ii < resAdmin.length ; ii ++){ System.out.println(resAdmin[ii]); } //Création d'un privilège : "MonPrivilege" wsAdmin.addAdmPrivilege(id,"MonApplication","MonPrivilege","Ma description de privilege"); //Liste des privileges de l'application : "MonApplication" String[] resPriv = wsAdmin.getAdmPrivileges(id,"MonApplication"); for (int ii = 0; ii < resPriv.length ; ii ++){ System.out.println(resPriv[ii]); } //Création d'un role : "MonRole" wsAdmin.addAdmRole(id,"MonApplication","MonRole","Ma description de role"); //Création d'un role : "MonRole2" wsAdmin.addAdmRole(id,"MonApplication","MonRole2","Ma description de role"); //Liste des roles de l'application : "MonApplication"



String[] resRole = wsAdmin.getAdmRoles(id,"MonApplication"); for (int ii = 0; ii < resRole.length ; ii ++){ System.out.println(resRole[ii]); } //Ajout d'un privilege à un role : "MonPrivilege" à "MonRole" String[] privs = new String[1]; privs[0] = "MonPrivilege"; wsAdmin.setAdmPrivilegesForRole(id,"MonApplication","MonRole",privs,"ADD"); //Liste les privileges d'un role : privs = new String[1]; privs[0] = "MonPrivilege"; String[] retPrivs = wsAdmin.getAdmPrivilegesForRole(id,"MonApplication","MonRole"); for (int ii = 0; ii < retPrivs.length ; ii ++){ out.print("<br><li> "+retPrivs[ii]); } //Ajout d'un utilisateur à un role : "FRTEST0" à "MonRole" String[] users = new String[1]; users[0] = "FRTEST0"; wsAdmin.setAdmUsersForRole(id,"MonApplication","MonRole",users,"ADD"); } catch (Exception e) { System.out.println(“Error :"+e.getMessage()); }



10.5 - MISE EN PLACE DE LA MIRE DE LOGIN SUR LE PROJET SUPERVISION EAI

La feuille de style passée en paramètre devra partir du modèle suivant : /* Remplacer chaque ::imgURL:: par l’url de vos images */ /* l’encapsulation par c4-ldap.jar le fait automatiquement */

/* style appliqué au body avec notamment l’image de fond */ body.def { color: #02A4D2; background-color: white; background-image: url(::imgURL::/fond.gif); background-repeat: no-repeat; background-attachment: fixed; }

/* couleur des liens hypertextes */ a:link { color: #02A4D2 }

/* couleur des liens hypertextes visités */ a:visited { color: #02A4D2 }

/* image de « Utilisateur » */ #imgLogin { background-image: url(::imgURL::/lib_utilisateur.gif);



background-repeat: no-repeat; background-attachment: scroll; width: 195px; height: 16px; }

/* image de « Mot de passe » */ #imgPassword { background-image: url(::imgURL::/lib_motdepasse.gif); background-repeat: no-repeat; background-attachment: scroll; width: 195px; height: 16px; }

/* image de « Nouveau mot de passe » */ #imgNewPassword { background-image: url(::imgURL::/lib_nouveau.gif); background-repeat: no-repeat; background-attachment: scroll; width: 195px; height: 16px; }

/* image « Confirmer mot de passe » */ #imgConfirmPassword { background-image: url(::imgURL::/lib_confirmer.gif); background-repeat: no-repeat; background-attachment: scroll; width: 195px; height: 16px; }

/* image « email » */ #imgEmail { background-image: url(::imgURL::/lib_email.gif); background-repeat: no-repeat; background-attachment: scroll; width: 195px; height: 16px; }

/* bouton « Valider » */ #btnValid { background-image: url(::imgURL::/btn_valider.gif); position: relative; background-repeat: no-repeat; background-attachment: scroll; background-position: 3px 3px ; width: 108px; height: 38px; cursor: pointer; border-color: #0480AD; border-width: 1px; border-style: solid;



padding:0px; margin:0px; background-color: white; } #btnValid:hover{ background-color:#EEF9FD; }

/* bouton « Changer de mot de passe » */ #btnChangePassword { background-image: url(::imgURL::/btn_changerpasse.gif); position: relative; background-repeat: no-repeat; background-attachment: scroll; background-position: 3px 3px ; width: 108px; height: 38px; cursor: pointer; border-color: #0480AD; border-width: 1px; border-style: solid; padding:0px; margin:0px; background-color: white; } #btnChangePassword:hover{ background-color:#EEF9FD; }

/* bouton « Retour » */ #btnReturn { background: url(::imgURL::/btn_retour.gif); position: relative; background-repeat: no-repeat; background-attachment: scroll; background-position: 3px 3px ; width: 108px; height: 38px; cursor: pointer; border-color: #0480AD; border-width: 1px; border-style: solid; padding:0px; margin:0px; background-color: white; } #btnReturn:hover{ background-color:#EEF9FD; }

/* bouton « demande de password » */ #btnDemandePassword { background-image: url(::imgURL::/btn_reinitialiserpasse.gif); position: relative; background-repeat: no-repeat;



background-attachment: scroll; background-position: 3px 3px ; width: 108px; height: 38px; cursor: pointer; border-color: #0480AD; border-width: 1px; border-style: solid; padding:0px; margin:0px; background-color: white; } #btnDemandePassword:hover{ background-color:#EEF9FD; }

/* bouton « Recharger le captcha » */ #btnRecharger { background-image: url(::imgURL::/btn_rechargercaptcha.gif); position: relative; background-repeat: no-repeat; background-attachment: scroll; background-position: 3px 3px ; width: 108px; height: 38px; cursor: pointer; border-color: #0480AD; border-width: 1px; border-style: solid; padding:0px; margin:0px; background-color: white; } #btnRecharger:hover{ background-color:#EEF9FD; }

/* tableau principal contenant les images, textes libres et boutons */ #tabMain { margin-top:200px; }



10.6 - DESCRIPTION FORMAT XML DE RETOUR DE L’API GETPROFIL