6.4.1 Ajouts effectués par le pilote Active Directory lorsque les droits sont activés

Lorsque les droits sont activés, la structure du pilote AD présente les modifications suivantes :

Les stratégies suivantes contiennent des règles supplémentaires permettant aux droits de fonctionner correctement :

Pour voir le code XML de chaque stratégie, procédez comme suit dans iManager :

Si les droits sont activés, le pilote Active Directory s'accompagne de trois droits : Compte utilisateur, Groupe et Boîte aux lettres Exchange.

Figure 6-1 Droits fournis avec le pilote AD

Vous pouvez consulter le code XML de ces droits dans les exemples de rédaction de la Section 6.4.6, Modèles de droits.

6.4.2 Utilisation du fichier DTD (Document Type Definition) des droits Novell

Certains droits sont prédéfinis sur les pilotes, si les droits sont activés sur les pilotes en question. Vous pouvez utiliser ces droits ou en créer de nouveaux dans iManager ou Designer. Pour vous aider à créer vos propres droits, utilisez le fichier DTD Novell suivant comme modèle.

Cette description du fichier DTD est suivie de quatre exemples de rédaction des droits au format XML dans iManager. Si vous ne voulez pas utiliser le format XML, servez-vous de l'assistant de création de droits du Designer, qui vous facilitera la tâche.

<!-*****************************************************************->
<!-- DirXML Entitlements DTD 
<!-- Novell Inc.
<!-- 1800 South Novell Place
<!-- Provo, UT 84606-6194
<!-- Version=1.0.0
<!-- Copyright 2005 Novell, Inc. All rights reserved -->
<!--************************************************************* -->
<!--
	Entitlement definition stored in the XmlData attribute of a
      DirXML-Entitlement object.
-->
<!ELEMENT entitlement (values?)>
<!ATTLIST entitlement
	conflict-resolution (priority | union) "priority"
	display-name CDATA #REQUIRED
	description CDATA #REQUIRED
>
<!ELEMENT values (query-app | value+)?>
<!ATTLIST values
	multi-valued (true | false) "true"
>
<!ELEMENT value (#PCDATA)>
<!ELEMENT query-app (query-xml, result-set)>
<!ELEMENT query-xml ANY>
<!ELEMENT result-set (display-name, description, ent-value)>
<!ELEMENT display-name(token-attr | token-src-dn | token-association)>
<!ELEMENT ent-value (token-association | token-src-dn | token-attr)>
<!ELEMENT description (token-association | token-src-dn | token-attr)>
<!ELEMENT token-association EMPTY>
<!ELEMENT token-attr EMPTY>
<!ATTLIST token-attr
	attr-name CDATA #REQUIRED
>
<!ELEMENT token-src-dn EMPTY>
<!--
	Entitlement reference stored in the DirXML-EntitlementRef attribute 	of a DirXML-EntitlementRecipient or a DirXML-SharedProfile object.
-->
<!ELEMENT ref (src?, id?, param?)>
<!ELEMENT param (#PCDATA)>
<!ELEMENT id (#PCDATA)>
<!ELEMENT src (#PCDATA)>
<!--
    Entitlement result stored in the DirXML-EntitlementResult attribute of a DirXML-EntitlementRecipient object.
-->
<!ELEMENT result(dn, src, id?, param?, state, status, msg?,timestamp)>
<!ELEMENT dn (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT status (#PCDATA)>
<!ELEMENT msg ANY>
<!ELEMENT timestamp (#PCDATA)>
<!--
   Cached query results stored in the DirXML-SPCachedQuery attribute of a DirXML-Entitlement object.
-->
<!ELEMENT items (item*)>
<!ELEMENT item (item-display-name?, item-description?, item-value)>
<!ELEMENT item-display-name (#PCDATA)>
<!ELEMENT item-description (#PCDATA)>
<!ELEMENT item-value (#PCDATA)>
<!--
   Representation of a DirXML-EntitlementRef within the DirXML Script and within the operation-data of an operation in an XDS document.
-->
<!ELEMENT entitlement-impl (#PCDATA)>
<!ATTLIST entitlement-impl
	name CDATA #REQUIRED
	src CDATA #REQUIRED
	id CDATA #IMPLIED
	state (0 | 1) #REQUIRED
	src-dn CDATA #REQUIRED
	src-entry-id CDATA #IMPLIED
>

6.4.3 Description du DTD de droits

Le DTD de droits se divise en cinq parties : définition, référence, résultat, requête en cache et informations de référence interne. L'en-tête représente juste un commentaire. Il est facultatif. Dans le DTD, l'en-tête de la définition du droit est le suivant :

<!-- Entitlement definition stored in the XmlData attribute of a DirXML-Entitlement object. -->

Les en-têtes sont suivis par des éléments (ELEMENT) et des listes d'attributs (ATTLIST). Voici la description détaillée des éléments et attributs sous l'en-tête de définition du droit, autrement dit du principal en-tête auquel vous devez vous attacher lorsque vous créez des droits.

<!ELEMENT entitlement (values?)>

L'élément du niveau racine est <entitlement>, qui peut contenir un élément <values> enfant facultatif et unique. Il est suivi de la liste d'attributs, qui comprend notamment les attributs conflict-resolution (résolution des conflits), display-name (nom d'affichage) et description. L'attribut de résolution des conflits utilise les valeurs d'attribut Priority (Priorité) ou Union.

conflict-resolution (priority | union) "priority"

Les droits basés sur le rôle utilisent l'attribut de résolution des conflits pour déterminer ce qui doit se passer lorsqu'un droit avec valeur est appliqué plusieurs fois au même objet. Supposons par exemple que l'utilisateur U soit membre de la stratégie de droit A et de la stratégie de droit B, qui contiennent toutes deux le même droit E accompagné d'ensembles de valeurs différents. Le droit E de la stratégie de droit A est associé aux valeurs (a, b, c). Le droit E de la stratégie de droit B, lui, est associé aux valeurs (c, d, e).

L'attribut de résolution des conflits détermine quel ensemble de valeurs doit s'appliquer à l'utilisateur U. S'il est défini sur Union, l'utilisateur U se voit attribuer les deux séries de valeurs (a, b, c, d, e). S'il est défini sur Priority, il ne reçoit que la série de valeurs de la stratégie de droits dotée de la priorité la plus élevée.

Si un droit doit être associé à une seule valeur, les conflits doivent être résolus par priorité, puisque l'attribut Union entraînerait l'application de plusieurs valeurs. Les droits basés sur le rôle utilisent actuellement cet attribut. Dans le futur, cela pourrait également être le cas des droits basés sur le workflow.

display-name CDATA #REQUIRED description CDATA #REQUIRED

Le nom littéral du droit ne correspond pas nécessairement au nom affiché par le droit. Les attributs Display-name et Description déterminent ce qui s'affiche pour l'utilisateur final. Dans Designer, une option permet de choisir le nom d'affichage du droit à la place du nom réel.

<!ELEMENT values (query-app | value+)?> <!ATTLIST values multi-valued (true | false) "true"

L'élément <values> est facultatif. Il indique qu'un droit est associé à une valeur. Si vous n'utilisez pas cet élément, le droit est « sans valeur ». Un droit accordant une liste de distribution est un droit avec valeur. Un droit accordant un compte dans une application (par exemple le droit Compte utilisateur fourni avec le pilote Active Directory) est un droit sans valeur.

Les valeurs des droits qui en sont dotés proviennent de trois sources. La première est l'application externe (désignée par l'élément <query-app>). La deuxième est une liste prédéfinie de valeurs (un ou plusieurs éléments <value>). La troisième est le client de droit (élément <values> sans enfant <value>. Les exemples fournis vous aideront à comprendre le fonctionnement des valeurs.

Les droits avec valeur peuvent comporter une ou plusieurs valeurs. Par défaut, ils en comptent plusieurs. Le client de droits est chargé d'appliquer cette restriction.

<!ELEMENT value (#PCDATA)>

Les valeurs des droits sont des chaînes qui ne sont pas saisies.

<!ELEMENT query-app (query-xml, result-set)>

Si les valeurs proviennent d'une application externe (par exemple, une liste de distribution de messagerie électronique), vous devez spécifier une requête d'application par le biais de l'élément <query-xml>. Les résultats de la requête sont extraits par le biais de l'élément <result-set>. Vous en trouverez deux exemples à Exemple 2 : droit de requête d'application : requête externe.

<!ELEMENT query-xml ANY>

Les requêtes XML sont au format XDS. La commande <query-xml> permet de rechercher et de lire des objets de l'application connectée. Les fonctions des règles DirXML, de migration d'objet, etc., dépendent de l'implémentation de la commande de requête par le pilote. Pour plus d'informations sur les requêtes XML, reportez-vous à la documentation Novell sur les requêtes.

<!ELEMENT result-set (display-name, description, ent-value)> <!ELEMENT display-name(token-attr | token-src-dn | token-association)> <!ELEMENT ent-value (token-association | token-src-dn | token-attr)> <!ELEMENT description (token-association | token-src-dn | token-attr)> <!ELEMENT token-association EMPTY> <!ELEMENT token-attr EMPTY> <!ATTLIST token-attr attr-name CDATA #REQUIRED

Aidez-vous de l'élément result-set (ensemble de résultats) pour interpréter le résultat d'une requête sur l'application externe. Trois éléments de données nous intéressent : le nom d'affichage de la valeur (élément display-name enfant), la description de la valeur (élément description enfant) et la valeur littérale du droit (élément ent-value enfant), qui ne s'affiche pas.

Les éléments jetons <token-src-dn>, <token-association> et <token-attr> sont en fait des marques de réserve pour les expressions XPATH chargées d'extraire respectivement la valeur de l'attribut src-dn, la valeur de l'association ou toute valeur d'attribut provenant d'un document XML au format XDS. Le DTD part de l'hypothèse que le résultat de la requête est au format XDS.

6.4.4 Création de droits dans Designer

Les exemples de la Section 6.4.5, Création et modification de droits dans iManager présentent le code XML utilisé pour rédiger des droits, mais il est beaucoup plus facile de se servir de l'utilitaire Designer fourni avec Identity Manager. Une fois que vous avez ajouté un pilote Identity Manager à un coffre-fort d'identité dans l'espace Modeler du Designer, vous pouvez cliquer sur ce pilote avec le bouton droit de la souris dans la vue Outline (Aperçu) et sélectionner Ajouter un droit. L'assistant de création de droits vous invite à indiquer le type de droit souhaité, puis il vous guide tout au long du processus de création.

Pour plus d'informations sur l'utilisation de l'assistant de création de droits, reportez-vous au manuel Designer for Identity Manager 3: Administration Guide (Guide d'administration de Designer pour Identity Manager 3).

6.4.5 Création et modification de droits dans iManager

Il est conseillé d'utiliser l'assistant de création de droits de Designer pour créer des droits, mais vous pouvez également le faire dans iManager.

6.4.6 Modèles de droits

Vous pouvez créer deux types de droits : avec ou sans valeur. Les droits avec valeurs peuvent tirer celles-ci d'une requête externe, d'une liste définie par l'administrateur ou de valeurs de forme libre. Vous trouverez ci-après des exemples des quatre types de droits que vous pouvez créer.

Exemple 1 : droits du compte : sans valeur

<?xml version="1.0" encoding="UTF-8"?>
<entitlement conflict-resolution="priority"
    description="This is an Account Entitlement"
    display-name="Account Entitlement"/>

Dans cet exemple, le nom du droit sans valeur est Account. Il est suivi de la ligne conflict-resolution, avec l'attribut par défaut (Priority), qui signifie généralement que si le droit est utilisé par les droits basés sur le rôle, celui qui a la priorité la plus élevée détermine la valeur retenue. Toutefois, comme il s'agit d'un exemple de droit sans valeur, les paramètres de valeur ne s'appliquent pas. Le droit a pour description « This is an Account Entitlement », et pour nom d'affichage Account Entitlement. Ces informations sont suffisantes pour créer un droit de compte utilisable pour accorder un compte dans une application.

Le pilote Active Directory, comporte un droit UserAccount qui lui sert à accorder ou révoquer les comptes utilisateur.

<?xml version="1.0" encoding="UTF-8"?>
<entitlement conflict-resolution="union"
	description="The User Account entitlement grants or denies an
	account in Active	Directory for the user. When granted, the user
	is given an enabled logon account.	When revoked, the logon
	account is either disabled or deleted depending on how the drive
	is configured."	display-name="User Account Entitlement" name="UserAccount">
</entitlement>

Dans cet exemple, le paramètre de résolution des conflits est Union. Il permet au droit de fusionner les valeurs assignées. Encore une fois, les paramètres avec valeur ne s'appliquent pas aux droits sans valeur. Le champ Description explique le rôle du droit et la raison de sa création. Ces informations seront utiles en cas de modification ultérieure du droit. Le nom effectif du droit est UserAccount, mais le <display-name> affiche User Account Entitlement dans l'agent de gestion.

Exemple 2 : droit de requête d'application : requête externe

Les droits Groupe et Boîte aux lettres Exchange fournis avec les pilotes Active Directory avec droits activés proposent des exemples de requêtes d'application. Utilisez ces droits lorsque vous avez besoin d'informations externes en provenance d'un système connecté pour réaliser un événement.

<?xml version="1.0" encoding="UTF-8"?>
<entitlement conflict-resolution="union"
   description="The Group Entitlement grants or denies membership in
   a group in Active Directory. The group must be associated with a
   group in the Identity Vault. When revoked, the user is removed from
   the group. The group membership entitlement is not enforced on the
   publisher channel: If a user is added to a controlled group in
   Active Directory by some external tool, the user is not removed by
   the driver. Further, if the entitlement is removed from the user
   object instead of being simply revoked, the driver takes no action."   display-name="Group Membership Entitlement" name="Group">
   <values>
	<query-app>
	   <query-xml>
		<nds dtd-version="2.0">
		   <input>
			<query class-name="Group"
			   scope="subtree">
			   <search-class class-name="Group"/>
			   <read-attr attr-name="Description"/>
			</query>
		   </input>
		</nds>
	   </query-xml>
	   <result-set>
		<display-name>
		    <token-src-dn/>
		</display-name>
		<description>
		   <token-attr attr-name="Description"/>
		</description>
		<ent-value>
		   <token-association/>
		</ent-value>
	   </result-set>
	</query-app>
   </values>
</entitlement>

Dans cet exemple, le droit Groupe utilise le paramètre Union pour résoudre les conflits si le droit est appliqué plusieurs fois au même objet. Cet attribut fusionne les droits de toutes les stratégies de droits basés sur le rôle concernées. Si une stratégie révoque un droit alors qu'une autre l'accorde, le droit est finalement accordé.

La description, très détaillée, précise les éléments configurés par le biais des règles des stratégies du pilote. Cette description est un bon exemple du niveau de détail à fournir lors de la première définition d'un droit.

Le <display-name> est Group Membership Entitlement. Il apparaît dans les agents de gestion, par exemple iManager, pour les droits basés sur le rôle. Le nom est le Nom distinctif relatif (RDN) du droit. Si vous ne définissez pas de nom d'affichage, le RDN est utilisé.

Les valeurs de requête initiales cherchent le nom de classe du Groupe en haut de l'arborescence et continuent dans les arborescences secondaires. Ces valeurs sont issues du serveur Active Directory connecté. La requête de l'application démarre à la balise <nds>. Sous la balise <query-xml>, cette requête reçoit des informations de ce type :

<instance class-name="Group" src-dn="o=Blanston,cn=group1">
   <association>o=Blanston,cn=group1</association>
   <attr attr-name="Description"> the description for group1</attr>
</instance>
<instance class-name="Group" src-dn="o=Blanston,cn=group2">
   <association>o=Blanston,cn=group2</association>
   <attr attr-name="Description"> the description for group2</attr>
</instance>
<instance class-name="Group" src-dn="o=Blanston,cn=group3">
   <association>o=Blanston, cn=group3</association>
   <attr attr-name="Description"> the description for group3</attr>
</instance>
<!-- ... ->

Ensuite, sous la balise <result-set>, les informations obtenues par la requête renseignent les différents champs. Dans notre exemple, le champ <display-name> indiquerait o=Blanston,cn=group1. Le champ <description> indiquerait the description for group1 (description du groupe 1), et le champ <ent-value> indiquerait o=Blanston,cn=group1. Comme il existe plusieurs groupes répondant aux critères de la requête, ces informations sont également recueillies et affichées pour d'autres instances.

Le droit Boîte aux lettres Exchange est un autre exemple de droit.

<?xml version="1.0" encoding="UTF-8"?>
<entitlement conflict-resolution="union"
  description="The Exchange Mailbox Entitlement grants or denies an
  Exchange mailbox for the user in Microsoft Exchange."
  display-name="Exchange Mailbox Entitlement" name="ExchangeMailbox">
  <values>
	<query-app>
	   <query-xml>
		<nds dtd-version="2.0">
		   <input>
			<query class-name="msExchPrivateMDB"
			   dest-dn="CN=Configuration," scope="subtree">
			   <search-class class-name="msExchPrivateMDB"/>
			   <read-attr attr-name="Description"/>
			   <read-attr attr-name="CN"/>
			</query>
		   </input>
		</nds>
	    </query-xml>
	    <result-set>
		<display-name>
		   <token-attr attr-name="CN"/>
		</display-name>
		<description>
		   <token-attr attr-name="Description"/>
		</description>
		<ent-value>
		  <token-src-dn/>
		</ent-value>
	    </result-set>
	</query-app>
   </values>
</entitlement>

Dans cet exemple, le droit Boîte aux lettres Exchange utilise le paramètre Union pour résoudre les conflits si le droit est appliqué plusieurs fois au même objet. Cet attribut fusionne les droits de toutes les stratégies de droits basés sur le rôle concernées. Si une stratégie révoque un droit alors qu'une autre l'accorde, le droit est finalement accordé.

La description indique que le droit accorde à l'utilisateur une boîte aux lettres dans Microsoft Exchange ou la révoque. Cette description est suffisamment détaillée pour le rôle du droit. Le display-name est Exchange Mailbox Entitlement. Il apparaît dans les agents de gestion, par exemple iManager, pour les droits basés sur le rôle. Le nom est le Nom distinctif relatif (RDN) du droit. Si vous ne définissez pas de nom d'affichage, le RDN est utilisé.

Les valeurs de requête initiales cherchent le nom de classe de msExchPrivateMDB, un appel fonction qui commence la recherche dans le conteneur Configuration et la poursuit dans les arborescences secondaires. Ces valeurs sont issues de la base de données Active Directory connectée. La requête de l'application démarre à la balise <nds>. La classe msExchPrivateMDB n'a pas d'équivalent dans eDirectory. Vous devez donc bien connaître les appels de fonction Microsoft Exchange pour effectuer ce type de requête. Mais la requête est achevée grâce aux règles et stratégies du pilote Active Directory.

Les consommateurs de droits utilisent les informations récupérées par la requête. Par exemple, la valeur du droit (ent-value) est transmise aux stratégies Identity Manager par le biais de l'attribut DirXML-EntitlementRef. Le nom d'affichage et la description sont affichés par iManager ou par l'application utilisateur. Ils sont enregistrés dans l'attribut DirXML-SPCachedQuery.

Exemple 3 : droit défini par l'administrateur : avec listes

Ce troisième exemple concerne un droit défini par l'administrateur qui accorde ou révoque un événement après sélection d'un élément dans une liste.

<?xml version="1.0" encoding="UTF-8"?>
<entitlement conflict-resolution="union"
    description="This will show Administrator-defined Values">
	   <display-name="Admin-defined Entitlement"/>
	   <values multi-valued="true">
		<value>Building A</value>
		<value>Building B</value>
		<value>Building C</value>
		<value>Building D</value>
		<value>Building E</value>
		<value>Building F</value>
	</values>
</entitlement>

Dans cet exemple, le nom du droit est Admin-defined, avec le nom d'affichage défini Admin-defined Entitlement. Vous pouvez indiquer uniquement le nom d'affichage si vous souhaitez qu'il soit différent du RDN du droit. La ligne de résolution des conflits contient le paramètre Union, qui permet au droit de fusionner les valeurs assignées.

La description du droit est la suivante : This will show Administrator-defined Values (Cela affichera les valeurs définies par l'administrateur). L'attribut multi-value (valeurs multiples) est défini sur true (vrai), ce qui permet au droit d'assigner plusieurs fois une valeur. Dans cet exemple, les valeurs correspondent aux lettres des bâtiments de la société, du bâtiment A au bâtiment F. Puis, à travers un client de droits, par exemple une tâche RBE de iManager ou de l'application utilisateur, les utilisateurs ou les responsables des tâches définies peuvent spécifier les informations sur le bâtiment, qui sont ensuite intégrées à l'application externe, par exemple Novell eDirectory.

Exemple 4 : droits définis par l'administrateur : sans liste

Le quatrième exemple représente un droit défini par l'administrateur qui oblige ce dernier à saisir une valeur pour que le droit puisse accorder ou révoquer un événement. Vous pouvez utiliser ce type de droit si vous ne disposez pas de toutes les informations nécessaires au moment de la configuration initiale et si vous ne pouvez donc pas créer de liste de tâches.

<?xml version="1.0" encoding="UTF-8"?>
<entitlement conflict-resolution="priority"
    description="There will be no pre-defined list">
    <values multi-valued="false"/>
</entitlement>

Dans cet exemple, le droit a pour nom Admin-defined (no list). Le nom du droit est utilisé comme nom d'affichage, ce dernier n'étant pas spécifié. Cette fois encore, le paramètre de résolution des conflits par défaut (Priority) est défini : si le droit est utilisé par les droits basés sur le rôle, celui qui a la priorité la plus élevée détermine la valeur. Vous spécifiez les informations sur le bâtiment par le biais d'un client de droits, par exemple une tâche RBE de iManager ou l'application utilisateur. Ces informations sont ensuite intégrées à l'application externe, par exemple eDirectory.

6.4.7 Dernières étapes de la procédure de création de droits

Les exemples de création de droits fournis plus haut illustrent les deux premières étapes de la procédure de création et d'utilisation de droits décrites à la Section 6.2, Création de droits : présentation. Il y a d'abord l'étape 1, qui consiste à établir la liste des exigences auxquelles doit répondre le droit, et l'étape 2, qui consiste à rédiger le droit de telle sorte qu'il réponde aux exigences définies dans cette liste. L'étape 3, la création de stratégies pour le pilote Identity Manager, n'est pas décrite dans ce chapitre. Pour plus d'informations sur la création et la modification de stratégies, reportez-vous au Policy Builder and Driver Customization Guide (Guide de création des stratégies et de personnalisation des pilotes) et au guide du pilote Identity Manager concerné.

Une fois que vous avez créé des droits (ou utilisé les droits préconfigurés fournis avec certains pilotes Identity Manager), vous devez les gérer, à l'étape 4. Les droits sont gérés par deux ensembles ou agents : via les stratégies de droits basés sur les rôles de iManager, ou via l'application utilisateur, dans le provisioning basé sur le workflow. Pour les droits utilisés dans le provisioning basé sur le workflow, reportez-vous à la Section V : Conception et gestion des demandes de provisioning du Guide d'administration de l'application utilisateur de Identity Manager. Le reste de ce chapitre traite essentiellement des droits basés sur le rôle.