Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
federation:docs:fiches:entitlement [2019/05/15 16:17]
herve.bourgault@renater.fr
— (Version actuelle)
Ligne 1: Ligne 1:
-====== Utilisation de l'​attribut eduPersonEntitlement ====== 
- 
-L'​attribut eduPersonEntitlement est définit dans les [[https://​wiki.refeds.org/​display/​STAN/​eduPerson|recommandations eduPerson]] ; il n'est pas repris dans SupAnn car cet attribut est a priori spécifique à l'​environnement Shibboleth et la valeur de l'​attribut peut être calculée dynamiquement par une brique Shibboleth fournisseur d'​identités. 
-  * La définition de l'​attribut : [[http://​software.internet2.edu/​eduperson/​internet2-mace-dir-eduperson-201602.html#​eduPersonEntitlement]] 
- 
-Cet attribut permet à un fournisseur d'​identités de transmettre des privilèges spécifiques à l'​utilisateur courant, dans le contexte d'une ressource. ​ 
- 
-===== Usage pour l'​accès à la documentation électronique ​ ===== 
- 
-La valeur //​urn:​mace:​dir:​entitlement:​common-lib-terms//​ de l'​attribut eduPersonEntitlement est prévue pour être transmise à un éditeur de contenus avec la sémantique suivante //cet utilisateur est duement autorisé à accéder à la ressource, selon les termes du contrat entre l'​éditeur et l'​université//​. 
- 
-Un fournisseur d'​identités va pouvoir générer dynamiquement cet attribut en fonction de la valeur de l'​attribut eduPersonAffiliation : si la valeur **member** de l'​attribut affiliation est présente, on génère un attribut eduPersonEntitlement dont la valeur est **urn:​mace:​dir:​entitlement:​common-lib-terms**,​ voir l'​exemple pour un IdP Shibboleth 2.1 ci-dessous : 
- 
-<code xml> 
-<​resolver:​AttributeDefinition id="​eduPersonEntitlement"​ xsi:​type="​Script"​ xmlns="​urn:​mace:​shibboleth:​2.0:​resolver:​ad"​ sourceAttributeID="​eduPersonEntitlement">​ 
-        <​resolver:​Dependency ref="​myLDAP"​ /> 
-        <​resolver:​Dependency ref="​eduPersonAffiliation"​ /> 
-        <​resolver:​AttributeEncoder xsi:​type="​SAML1String"​ xmlns="​urn:​mace:​shibboleth:​2.0:​attribute:​encoder"​ 
-            name="​urn:​mace:​dir:​attribute-def:​eduPersonEntitlement"​ /> 
-        <​resolver:​AttributeEncoder xsi:​type="​SAML2String"​ xmlns="​urn:​mace:​shibboleth:​2.0:​attribute:​encoder"​ 
-            name="​urn:​oid:​1.3.6.1.4.1.5923.1.1.1.7"​ friendlyName="​eduPersonEntitlement"​ /> 
-        <​Script>​ 
-          <​![CDATA[ 
-            importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);​ 
-              if (eduPersonEntitlement == null) { 
-                eduPersonEntitlement = new BasicAttribute("​eduPersonEntitlement"​);​ 
-              } 
-              if (eduPersonAffiliation.getValues().contains("​member"​)) { 
-                eduPersonEntitlement.getValues().add("​urn:​mace:​dir:​entitlement:​common-lib-terms"​);​ 
-              } 
-          ]]> 
-        </​Script>​ 
-    </​resolver:​AttributeDefinition>​ 
-</​code>​ 
- 
-Remarque : la population des **lecteurs autorisés** (walking users) n'est pas censée accéder aux ressources documentaires hors des murs de la bibliothèque,​ donc l'​attribut eduPersonEntitlement n'est pas positionné pour eux. 
- 
-  * Exemple de configuration d'un IdP Shibboleth 2.1 pour générer un attribut entitlement dynamiquement : [[https://​spaces.internet2.edu/​display/​SHIB2/​ResolverScriptAttributeDefinition]] 
- 
-===== Dans quels cas utiliser cet attribut ? ===== 
- 
-Cet attribut est adapté lorsque la décision d'​autorisation d'​accès à une resource ne peut pas être  réalisée du côté de la ressource (car les attributs ne sont pas standards ou pas divulgables). Dans ce cas, le fournisseur d'​identités prépare l'​attribut eduPersonEntilement pour exprimer les droits de l'​utilisateur vis à vis de cette ressource, en fonction des autres attributs de l'​utilisateur. 
- 
- 
- 
-===== Filtrage de cet attribut s'il est multivalué ===== 
-De plus en plus de ressources s'​appuient sur cet attribut pour autoriser ou pas les usagers. Dans ce cas il est fort possible que cet attribut devienne multi-valué pour certains utilisateurs. Il est possible de procéder de différentes façon pour effectuer un filtrage de valeur selon la ressource accédée. 
- 
-==== 1. Génération à la demande dans le fichier attribute-resolver.xml ==== 
-On peut positionner la/les valeur(s) de cet attribut à la demande, c'est à dire au moment de la connexion en spécifiant quelle valeur pour quelle ressource. Voici un exemple pour une application données, génération d'un entitlement multi-valué:​ 
- 
-<code xml> 
-    <!-- eduPersonEntitlement --> 
-   <​resolver:​AttributeDefinition id="​eduPersonEntitlement"​ xsi:​type="​Script"​ xmlns="​urn:​mace:​shibboleth:​2.0:​resolver:​ad"​ > 
-        <​resolver:​Dependency ref="​myLDAP"​ /> 
- <​resolver:​Dependency ref="​eduPersonAffiliation"​ /> 
- 
-        <​resolver:​AttributeEncoder xsi:​type="​SAML1String"​ xmlns="​urn:​mace:​shibboleth:​2.0:​attribute:​encoder"​ 
-            name="​urn:​mace:​dir:​attribute-def:​eduPersonEntitlement"​ /> 
-        <​resolver:​AttributeEncoder xsi:​type="​SAML2String"​ xmlns="​urn:​mace:​shibboleth:​2.0:​attribute:​encoder"​ 
-            name="​urn:​oid:​1.3.6.1.4.1.5923.1.1.1.7"​ friendlyName="​eduPersonEntitlement"​ /> 
- 
- ​ <​Script>​ 
-          <​![CDATA[ 
- 
-             ​importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);​ 
-             // init at an empty value 
-             ​eduPersonEntitlement = new BasicAttribute("​eduPersonEntitlement"​);​ 
-             ​eduPersonEntitlement.getValues().add(""​);​ 
- 
-             if (eduPersonAffiliation != null && requestContext.getPeerEntityId() != null) {  ​ 
-                  
-                 if (requestContext.getPeerEntityId() == "​https://​test.federation.renater.fr/​test/​ressource"​ && eduPersonAffiliation.getValues().contains("​staff"​)) 
-        eduPersonEntitlement.getValues().add("​admin-value"​);​ 
- 
- if (requestContext.getPeerEntityId() == "​https://​test.federation.renater.fr/​test/​ressource"​ && eduPersonAffiliation.getValues().contains("​member"​)) 
-        eduPersonEntitlement.getValues().add("​user-value"​);​ 
-             }//if 
- 
-             ​]]>​ 
- </​Script>​ 
- 
-    </​resolver:​AttributeDefinition>​ 
-</​code>​ 
- 
-==== 2. Filtrage des valeurs dans le fichier attribute-filter.xml ==== 
-Si L'​attribut devait se retrouver multi-valué dans le resolver par simple accumulation des valeurs possibles, on peut filtrer certaines valeurs selon la ressource accédée. L'​exemple ci-dessous est une **autre** manière de faire par rapport à la méthode ci-dessus. 
- 
-Imaginons donc que nous avons un entitlement ayant les valeurs suivantes positionnées dans le resolver quelle que soit la ressource : 
-  * urn:​mace:​dir:​entitlement:​test-value0 
-  * urn:​mace:​dir:​entitlement:​test-value1 
-  * urn:​mace:​dir:​entitlement:​test-value2 
- 
-Nous allons donc filtrer les valeurs qui ne sont pas pertinentes pour une ressource données : 
- 
-<code xml> 
-<!-- Entitlement pour ressource donnée --> 
-  <​AttributeFilterPolicy id="​epeExample">​ 
-    <​PolicyRequirementRule xsi:​type="​basic:​AttributeRequesterString"​ value="​https://​test.federation.renater.fr/​test/​ressource"​ /> 
-    ​ 
-    <​AttributeRule attributeID="​eduPersonEntitlement">​ 
-      <​DenyValueRule xsi:​type="​basic:​NOT">​ 
- <​basic:​Rule xsi:​type="​basic:​AttributeValueString"​ value="​urn:​mace:​dir:​entitlement:​test-value2"​ ignoreCase="​true"​ /> 
-      </​DenyValueRule>​ 
-    </​AttributeRule>​ 
-  </​AttributeFilterPolicy>​ 
-</​code>​ 
- 
-Cette configuration ne laissera passer que la valeur "​urn:​mace:​dir:​entitlement:​test-value2"​ si un utilisateur se connecte à la ressource mentionnée ci-dessus. 
-