Règle LDAP

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Quoi

La règle LDAP fournit les éléments suivants :

  • Authentification : les identifiants utilisateur fournis dans la requête sont validés par rapport aux identifiants du fournisseur LDAP. La règle LDAP vous offre une grande flexibilité en matière d'authentification. Elle vous permet d'utiliser n'importe quelle valeur DN avec le mot de passe, même si la valeur DN souhaitée ne figure pas dans la requête. Par exemple, supposons que vous deviez utiliser une adresse e-mail et un mot de passe pour l'authentification. Les options suivantes sont possibles :
    • Si l'adresse e-mail figure dans la requête, vous pouvez simplement l'utiliser avec le mot de passe pour l'authentification LDAP.
    • Si l'adresse e-mail ne figure pas dans la requête, mais qu'un autre attribut DN est présent (comme un numéro de téléphone), vous pouvez utiliser le numéro de téléphone pour obtenir l'adresse e-mail correspondante à partir de LDAP, puis utiliser l'adresse e-mail et le mot de passe pour vous authentifier.
  • Recherche de nom distinctif (DN) : en plus de l'authentification, vous pouvez également utiliser la règle LDAP pour identifier un attribut utilisateur dans la requête, tel qu'une adresse e-mail, et effectuer une requête qui récupère d'autres attributs DN à partir de LDAP pour cet utilisateur. Le nom unique récupéré est stocké dans une variable.

Utilisez la stratégie LDAP lorsque l'accès aux ressources protégées doit être limité aux utilisateurs de votre fournisseur LDAP (administrateurs, utilisateurs de l'organisation et développeurs, par exemple), en particulier lorsque l'accès aux jetons OAuth est inutile ou trop lourd. Cette règle est également conçue pour récupérer les métadonnées du nom de domaine à utiliser dans les flux de proxy d'API.

Par exemple, vous pouvez faire en sorte qu'un appel d'API ne s'exécute que lorsqu'un utilisateur est authentifié avec succès auprès de LDAP, puis récupérer éventuellement les attributs DN (nom de domaine) de l'utilisateur une fois l'authentification réussie.

Pour en savoir plus, consultez les pages suivantes :

Exemples

Authentification par nom d'utilisateur/mot de passe

<Ldap name="4GLdapPo>licy<"
   Ld>apRes<ourceldap1/Ld>apRe<source
   Auth>enticati<on
       UserName ref="request.he>ader.use<rname"/
       Password ref=">request.<heade>r.passw<ord&qu>ot;/
   <    Scopesubtree/Scope
   ><    Bas>e<DN ref="apigee.baseDN"/B>aseDN< !-- default is> d<c=api>gee,dc=com --
    /Authentication
 /Ldap

Cet exemple fournit une authentification auprès d'un fournisseur LDAP. La règle transmet le nom d'utilisateur et le mot de passe de la requête à LDAP pour l'authentification.

Authentification des attributs de DN

<Ldap name="LdapPo>licy<"
   Ld>apRes<ourceldap1/Ld>apRe<source
   Auth>enticati<on
       Password ref="request.he>ader.pas<sword">/
       SearchQuerymail={<request.head>er.mail}</Sear>chQuery<
     >  Scopes<ubtree/Scope
       BaseDN>< ref=&q>u<ot;apigee.baseDN"/BaseDN !-- >defau<lt is dc=apigee>,d<c=com> --
    /Authentication
 /Ldap

Cette règle récupère le nom unique de l'utilisateur avec l'adresse e-mail dans l'en-tête de la requête, puis authentifie l'utilisateur auprès de LDAP avec le mot de passe fourni dans l'en-tête de la requête.

Rechercher dans LDAP

<Ldap name="LdapPo>licy&<quot;
    !-- using a custom LDAP p>rovid<er --
    LdapConn>ectorClasscom.custom.ldap.<MyProvider/LdapConn>ector<Class
    Ld>apReso<urceMyLdap/Ld>apRes<ource<>/span>
    Searc<h
        BaseDN ref="><;apigee>.<baseDN"/BaseDN !-- default is> dc=apige<e,dc=com -->
        SearchQuerymail={<request.head>er.mail}/<SearchQuer>y
        Att<ributes
 >       <    Attrib>uteaddress/At<tribute
 >     <      Attr>ibutephone/At<tribute
 >     <      Attr>ibutetitl<e/Attribute>
        </Attr><ibutes>
<        Scope/S‘cope !-’- d>efaul<t is su>b<tree >--
    /Search
/Ldap

Cette règle fait référence à un fournisseur LDAP personnalisé. Il utilise l'adresse e-mail dans l'en-tête de la requête pour identifier l'utilisateur, puis récupère son adresse, son numéro de téléphone et son titre à partir de LDAP. Les attributs de nom unique récupérés sont stockés dans une variable. Consultez "Variables spécifiques aux règles".

Pour rechercher dans LDAP et récupérer les attributs de nom distinctif, la requête doit inclure les identifiants d'administrateur.

Documentation de référence des éléments

Vous trouverez ci-dessous des descriptions des éléments et attributs de la règle LDAP.

Élément

Description

Ldap

Élément parent avec un attribut de nom dans lequel vous pouvez saisir le nom de la règle.

LdapConnectorClass

Lorsque vous utilisez la règle LDAP avec un fournisseur LDAP personnalisé (non fourni par Apigee), spécifiez la classe de connecteur LDAP complète. Il s'agit de la classe dans laquelle vous avez implémenté l'interface ExternalLdapConProvider d'Apigee.

LdapResource

Saisissez le nom de l'environnement de la ressource LDAP. Pour en savoir plus, consultez Créer une ressource LDAP.

BaseDN

Niveau de base du protocole LDAP sous lequel se trouvent toutes vos données. Par exemple, dans le fournisseur LDAP d'Apigee, toutes les données se trouvent sous dc=apigee,dc=com.

  • ref : permet de spécifier une variable de flux contenant la valeur BaseDN, telle que apigee.baseDN. ref est prioritaire par rapport à une valeur BaseDN explicite. Si vous spécifiez à la fois une référence et une valeur, la référence est prioritaire. Si la référence n'est pas résolue au moment de l'exécution, la valeur est utilisée.

Scope

  • object : l'authentification ou la recherche n'ont lieu qu'au niveau de base de LDAP.
  • onelevel : l'authentification ou la recherche s'effectuent un niveau en dessous du niveau de base.
  • subtree (par défaut) : l'authentification ou la recherche se produit au niveau de base et de manière entièrement récursive en dessous de la base.

Authentification

Authentication

Élément parent pour le comportement d'authentification que vous implémentez.

UserName

Élément vide qui accepte l'un des attributs suivants :

  • ref : référence au nom d'utilisateur dans la demande, par exemple request.header.username
  • value : nom d'utilisateur

Si vous ne vous authentifiez pas avec un nom d'utilisateur ou si le nom d'utilisateur n'est pas inclus dans la requête, vous n'avez pas besoin d'inclure cet élément.

Si le nom d'utilisateur figure dans la requête, mais que vous souhaitez authentifier un utilisateur avec un attribut DN autre que le nom d'utilisateur (par exemple, l'adresse e-mail), incluez un SearchQuery pour obtenir l'adresse e-mail de l'utilisateur associée au mot de passe. La stratégie LDAP utilise le nom d'utilisateur pour interroger le fournisseur LDAP et obtenir l'adresse e-mail correspondante, qui est ensuite utilisée pour l'authentification.

Password

Élément vide qui accepte l'un des attributs suivants :

  • ref : référence au mot de passe dans la requête, par exemple request.header.password
  • valeur : mot de passe chiffré

SearchQuery

Si vous souhaitez vous authentifier à l'aide d'un attribut de nom distinctif autre que le nom d'utilisateur (par exemple, l'adresse e-mail), configurez la règle LDAP pour obtenir un attribut de nom distinctif à partir de la requête (par exemple, le nom d'utilisateur), qui est utilisé pour identifier l'utilisateur dans LDAP, récupérer l'adresse e-mail et authentifier l'utilisateur.

Par exemple, en supposant que LDAP définisse un attribut "mail" pour stocker les adresses e-mail :

<SearchQuery>mail={request.header.mail}</SearchQuery>

Rechercher

Search

Élément parent du comportement de recherche que vous implémentez.

SearchQuery

En identifiant l'utilisateur avec des métadonnées dans la requête ou la réponse, vous pouvez utiliser cet élément pour récupérer des attributs DN supplémentaires pour l'utilisateur à partir du protocole LDAP. Par exemple, si la requête contient l'adresse e-mail de l'utilisateur et que votre LDAP définit un attribut mail pour stocker les adresses e-mail des utilisateurs, vous devez utiliser le paramètre suivant :

<SearchQuery>mail={request.header.mail}</SearchQuery>

Cette requête recherche dans LDAP une adresse e-mail correspondant à celle de la demande. La règle peut désormais récupérer des attributs de nom distinctif supplémentaires pour cet utilisateur avec l'élément "Attributes".

Attributes

Utilisez un ou plusieurs éléments <Attribute> pour identifier les métadonnées de nom à afficher pour l'utilisateur. Au moins un attribut est requis.

Par exemple, une fois que SearchQuery a identifié l'utilisateur, la règle peut désormais récupérer les attributs DN de l'utilisateur, tels que l'adresse, le numéro de téléphone et le titre de l'utilisateur, comme illustré dans l'exemple suivant.

Les valeurs d'attributs sont les noms d'attributs DN définis dans votre LDAP.

<Attributes>
  <Attribute>address</Attribute>
  <Attribute>phone</Attribute>
  <Attribute>title</Attribute>
</Attributes>

Remarques sur l'utilisation

Apigee Edge pour Private Cloud vous permet d'utiliser un fournisseur LDAP dans les appels d'API. Grâce au règlement LDAP, les applications peuvent authentifier les identifiants par rapport aux utilisateurs stockés dans LDAP. Vous pouvez également récupérer les noms distinctifs (DN) à partir de LDAP, c'est-à-dire les métadonnées ou les attributs associés à chaque utilisateur, tels que l'adresse e-mail, l'adresse postale et le numéro de téléphone. Le nom unique renvoyé est stocké dans une variable pour être utilisé ultérieurement par le proxy d'API.

Créer une ressource LDAP

La règle LDAP utilise une ressource LDAP que vous créez dans Apigee Edge. Une ressource LDAP fournit les informations de connexion à votre dépôt LDAP.

Pour créer et gérer des ressources LDAP, utilisez l'API et la charge utile suivantes :

API

Créez (POST) une ressource LDAP ou listez (GET) toutes les ressources LDAP :

/v1/organizations/org_name/environments/environment/ldapresources

Obtenez des informations (GET), mettez à jour (POST) et supprimez (DELETE) une ressource LDAP :

/v1/organizations/org_name/environments/environment/ldapresources/ldap_resource_name

Charge utile

Vous trouverez ci-dessous un exemple de charge utile XML avec des commentaires sur l'utilisation.

<LdapResource name="l>dap<1"
  >Conne<ction>
    Ho<sts
      !-- port is optional: defaults to 389 for ldap:// and 636 for l>daps://< --
      Host >port=&q<uot;6>36&qu<ot;foo>.com/<Host
    />Hosts<
    SSLEna>b<ledfalse/SSLEnabled !-- optional, >defau<lts to >f<alse --
> <   Version3/Version !-- optio>nal, <defaults to 3->-
    <Authentications>i<mple/Authentication !-- optional, only> simp<le supported --
  >  ConnectionPr<oviderjndi|unboundi>d</ConnectionProv>ider <!-- required >--
    ServerSetTypesingle|<round robin|fa>i<lover/ServerSetType !-- not ap>plica<ble for jndi --
    !-- If using a custom LDAP provider, the fully> qual<ified class: --
  >  LdapConnectorClasscom.cu<stom.ldap.MyProvide>r/L<dapConnecto>rCl<ass
  /Connection
  Connec>t<Pool enabled="true" !-- enabled is> opti<onal, d>efaul<ts to tr>u<e --
    Timeout30000/Timeout !-- optional, in milliseco>nds; <if not >se<t, no ti>m<eout --
    Maxsize50/Maxsize !-- optional; if >not s<et, no m>ax< connecti>o<ns --
    Prefsize30/Prefsize !-- optiona>l; if< not set><, no pref> <size --
    Initsize/Initsize !-- optional>; if <not set,>< defaults> <to 1 --
    Protocol/Protocol !-- optional; if not s>et,< defaults to> &#<39;ss>l pla<in>' --
  /ConnectPool
  A<dmi>n
   < DNcn=ma>nager,<dc=apigee>,dc<=com/D>N<
    Password>secret/Password
  /Admin
/LdapResource

Exemple curl : créer une ressource LDAP

L'exemple suivant crée une ressource LDAP nommée ldap1.

curl -X POST -H "Content-Type: application/xml" \
  https://api.enterprise.apigee.com/v1/organizations/myorg/environments/test/ldapresources \
  -u apigee_email:passwor<d -d \
  'LdapResourc>e nam<e="ld>ap1&quo<t;
  >  Conne<ctio>n
     < Host>s
     < Hostf>oo.com/<Host
     > /Hos<ts
      SS>LEnable<dfalse/>S<SLEnable>d
     < Version3/Vers>ion
  <    Authenticat>ionsimp<le/Authentication
>      Con<nectionProviderunbo>undid/C<onnectionProv>ider
      <ServerSetTyper>ound <robin/Serve>rSetT<ype
    /Connection
    Co>nnectPo<ol enab>led=&<quot;tru>e"<
      >Ti<meout300>00/Time<out
    >  <Maxsize50>/Maxsiz<e
      ><Prefsize3>0/Prefs<ize
    ><  Initsiz>e/Ini<tsize
      >Proto<col/P>rotocol<
 >   /ConnectPool
    Admin
 <   >  DNcn=<manager,>dc=api<gee,dc=co>m/DN
<      >Pas<swordsecret/P>assword
    /Admin
  /LdapResource'

Codes de réponse

Vous trouverez ci-dessous les codes de réponse HTML que la règle renvoie en cas de réussite ou d'échec :

  • Success (Réussite) : 200
  • Échec : 401

Utiliser un fournisseur LDAP personnalisé dans Edge pour le cloud privé

Utiliser un fournisseur LDAP personnalisé

Apigee Edge pour un cloud privé est fourni avec un fournisseur LDAP déjà configuré pour interagir avec la stratégie LDAP. Toutefois, si vous utilisez un fournisseur LDAP personnalisé, vous devez l'activer pour qu'il soit compatible avec le règlement LDAP. Pour ce faire :

  1. Dans votre classe de fournisseur LDAP, implémentez l'interface ExternalLdapConProvider.
    public interface ExternalLdapConProvider {
      void doAuthentication(LdapBean LlapBean, String userDN, String password, String baseDN);
    
      void doSearchAndAuthentication(LdapBean LlapBean, String password, String baseDN, String query, int scope);
    
      Collection<Map<String, String[]>> doSearch(LdapBean LlapBean, String query,
        String baseDN, Collection<String> requiredAttributes, int scope);
    
      void closeConnections();
    }
  2. Dans le <LdapConnectorClass> de la configuration de la stratégie (sections suivantes), ajoutez le nom complet de la classe de votre fournisseur LDAP personnalisé.
  3. Téléchargez le fichier custom-ldap.jar_.zip. (Vous devrez peut-être effectuer un clic droit et sélectionner Enregistrer sous.)
  4. Décompressez-le.
  5. Ajoutez le fichier custom-ldap.jar à votre environnement et assurez-vous qu'il se trouve dans votre chemin de classe.
  6. Créez une ressource d'environnement pour votre fournisseur LDAP. Vous utiliserez le nom de ressource de l'environnement dans l'élément <LdapResource> de la règle LDAP.

Utiliser le SDK UnboundID LDAP pour Java

Vous pouvez utiliser le SDK LDAP UnboundID avec la règle LDAP, mais vous devez d'abord télécharger la version 2.3.1 et l'ajouter à chacun des chemins de classe de votre processeur de messages.

Pour utiliser le SDK LDAP UnboundID avec la règle LDAP :

  1. Ouvrez un navigateur et accédez au dépôt de fichiers Sourceforge pour le SDK LDAP UnboundID :
    https://sourceforge.net/projects/ldap-sdk/files/
  2. Recherchez la version 2.3.1 (SE ou Standard Edition) du SDK, puis téléchargez le fichier ZIP correspondant. Par exemple, téléchargez "unboundid-ldapsdk-2.3.1-se.zip".
  3. Extrayez le fichier JAR du fichier ZIP du SDK, comme le montre l'exemple suivant :
    unzip -j -d ~/tmp ~/Downloads/unboundid-ldapsdk-2.3.1-se.zip unboundid-ldapsdk-2.3.1-se/unboundid-ldapsdk-se.jar

    Cette commande extrait uniquement le fichier JAR dans le répertoire ~/tmp. Il supprime la structure de répertoire avec -j, bien que cela soit facultatif.

  4. Sur chaque nœud Message Processor :
    1. Copiez le fichier JAR dans le répertoire /opt/apigee/edge-gateway/lib/thirdparty du processeur de messages.
    2. Si nécessaire, accordez l'autorisation d'accès au fichier JAR à l'utilisateur Apigee afin que le processeur de messages puisse y accéder.
    3. Edge ajoute toutes les bibliothèques tierces du répertoire /opt/apigee/edge-gateway/lib/thirdparty au chemin de classe.

    4. Redémarrez le processeur de messages :
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Variables de flux

Vous trouverez ci-dessous les variables de la règle LDAP renseignées par un SearchQuery.

Variable

Description

ldap.policyName.execution.success

Une fois la règle exécutée, cette variable de flux contient la valeur "true" ou "false", selon le résultat.

ldap.policyName.search.result[index].
  attribute.attrName[index]=value

Le format flexible de cette variable, l'index en particulier, tient compte de plusieurs attributs, ainsi que des attributs comportant plusieurs valeurs. L'index est un nombre qui commence à 1. Si aucun numéro d'index n'est fourni, la valeur par défaut est 1.

Si la règle renvoie l'adresse, le numéro de téléphone et l'adresse e-mail, vous pouvez récupérer le premier attribut et la première valeur à l'aide des variables suivantes :

ldap.policyName.search.result.attribute.address
ldap.policyName.search.result.attribute.phone
ldap.policyName.search.result.attribute.email

Si vous souhaitez récupérer le troisième attribut d'adresse dans les résultats de recherche, vous devez utiliser le code suivant :

ldap.policyName.search.result[3].attribute.address

Si un attribut comporte plusieurs valeurs (par exemple, si un utilisateur possède plusieurs adresses e-mail), vous pouvez récupérer la deuxième adresse e-mail à partir des résultats comme suit :

ldap.policyName.search.result.attribute.mail[2]

Codes d'erreur

Les erreurs renvoyées par les règles Edge suivent un format cohérent, comme décrit dans la Documentation de référence sur les codes d'erreur.

Cette règle utilise les codes d'erreur suivants:

Code d'erreur d'un message ;
InvalidAttributeName Invalid attribute name {0}.
InvalidSearchBase Search base can not be empty.
InvalidValueForPassword Invalid value for password field. It can not be empty.
InvalidSearchScope Invalid scope {0}. Allowed scopes are {1}.
InvalidUserCredentials Invalid user credentials.
InvalidExternalLdapReference Invalid external ldap reference {0}.
LdapResourceNotFound Ldap resource {0} not found.
BaseDNRequired Base DN required.
OnlyReferenceOrValueIsAllowed Only value or reference is allowed for {0}.
AttributesRequired At least one attribute required for search action.
UserNameIsNull User name is null.
SearchQueryAndUserNameCannotBePresent Both search query and username can not be present in the authentication action. Please specify either one of them.