Règle LDAP

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X.
En savoir plus

Quoi

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

  • Authentification: les identifiants utilisateur fournis dans la requête sont validés. avec les identifiants du fournisseur LDAP. La règle LDAP vous offre beaucoup de flexibilité avec l'authentification unique, ce qui vous permet d'utiliser n'importe quelle valeur DN avec le mot de passe, même si cette valeur ne figure pas dans la demande. Par exemple, supposons que vous deviez utiliser une adresse e-mail / un mot de passe pour l'authentification unique. Les options suivantes sont possibles: <ph type="x-smartling-placeholder">
      </ph>
    • Si l'adresse e-mail figure dans la demande, vous pouvez simplement l'utiliser avec le mot de passe pour LDAP l'authentification unique.
    • Si l'adresse e-mail ne figure pas dans la demande, mais qu'un autre attribut DN est présent (tel que le numéro de téléphone), vous pouvez utiliser le numéro de téléphone pour obtenir l’e-mail correspondant auprès de LDAP, puis utiliser email / pour s'authentifier.
  • Recherche par nom distinctif (DN): outre l'authentification, vous pouvez utilisent également 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 de LDAP pour cet utilisateur. Le nom distinctif récupéré est stockées dans une variable.

Utilisez la règle LDAP lorsque l'accès aux ressources protégées doit être limité aux utilisateurs de votre serveur LDAP fournisseur, comme les administrateurs, les utilisateurs de l'organisation et les développeurs, en particulier lorsque L'accès au jeton OAuth est inutile ou trop lourd. Ces règles s'appliquent également récupération des métadonnées de 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é. vis-à-vis du protocole LDAP. puis, éventuellement, récupérer les attributs DN (Domain Name) de l'utilisateur après l'authentification réussit.

Pour en savoir plus, consultez les pages suivantes :

Exemples

Authentification par nom d'utilisateur/mot de passe

<Ldap name="4GLdapPolicy">
   <LdapResource>ldap1</LdapResource>
   <Authentication>
       <UserName ref="request.header.username"/>
       <Password ref="request.header.password"/>
       <Scope>subtree</Scope>
       <BaseDN ref="apigee.baseDN"></BaseDN> <!-- default is dc=apigee,dc=com -->
    </Authentication>
 </Ldap>

Cet exemple fournit une authentification auprès d'un fournisseur LDAP. La stratégie transmet le nom d'utilisateur et le mot de passe de la demande au LDAP pour l’authentification.

Authentification par attribut DN

<Ldap name="LdapPolicy">
   <LdapResource>ldap1</LdapResource>
   <Authentication>
       <Password ref="request.header.password"/>
       <SearchQuery>mail={request.header.mail}</SearchQuery>
       <Scope>subtree</Scope>
       <BaseDN ref="apigee.baseDN"></BaseDN> <!-- default is dc=apigee,dc=com -->
    </Authentication>
 </Ldap>

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

Recherche LDAP

<Ldap name="LdapPolicy">
    <!-- using a custom LDAP provider -->
    <LdapConnectorClass>com.custom.ldap.MyProvider</LdapConnectorClass>
    <LdapResource>MyLdap</LdapResource>
    <Search>
        <BaseDN ref="apigee.baseDN"></BaseDN> <!-- default is dc=apigee,dc=com -->
        <SearchQuery>mail={request.header.mail}</SearchQuery>
        <Attributes>
            <Attribute>address</Attribute>
            <Attribute>phone</Attribute>
            <Attribute>title</Attribute>
        </Attributes>
        <Scope></Scope> <!-- default is ‘subtree’ -->
    </Search>
</Ldap>

Cette règle fait référence à un fournisseur LDAP personnalisé. Il utilise l'adresse e-mail de la demande pour identifier l'utilisateur, puis récupère l'adresse, le numéro de téléphone et la fonction de l'utilisateur LDAP. Les attributs DN récupérés sont stockés dans une variable. Pour en savoir plus, consultez la section variables".

Pour effectuer une recherche dans LDAP et récupérer des attributs DN, la requête doit inclure les adresses : identifiants de connexion.

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

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

Élément

Description

Ldap

Élément parent avec un attribut "name" permettant de saisir le nom de la règle.

LdapConnectorClass

En cas d'utilisation de la règle LDAP avec un LDAP personnalisé provider (non fourni par Apigee), spécifiez la classe complète du connecteur LDAP. Il s'agit de la classe dans laquelle vous avez implémenté le ExternalLdapConProvider d'Apigee. de commande.

LdapResource

Saisissez le nom d'environnement de la ressource LDAP. Reportez-vous à la section Créer un ressource LDAP pour en savoir plus.

BaseDN

Niveau de base du service LDAP sous lequel toutes vos données existent. Par exemple, dans auprès du fournisseur LDAP d'Apigee. Toutes les données sont sous dc=apigee,dc=com.

  • ref: permet de spécifier une variable de flux contenant la valeur BaseDN, telle que apigee.baseDN. ref a priorité sur une valeur BaseDN explicite. Si vous indiquez ref et value, ref a la priorité. Si la référence ne résout pas le problème à "Runtime", la valeur est utilisée.

Scope

  • Objet: l'authentification ou la recherche n'ont lieu qu'au niveau de base LDAP.
  • onelevel: l'authentification ou la recherche ont lieu à un niveau en dessous de la base d'application.
  • subtree (par défaut): l'authentification ou la recherche s'effectue au niveau de base. et entièrement récursive en dessous de la base.

Authentification

Authentication

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

UserName

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

  • ref: référence au nom d'utilisateur dans la requête, par exemple request.header.username
  • valeur: nom d'utilisateur lui-même

Si vous ne vous authentifiez pas avec un nom d'utilisateur, ou si le nom d'utilisateur n'est pas inclus dans , 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, comme l'adresse e-mail, ajoutez un SearchQuery pour obtenir l'adresse e-mail de l'utilisateur associé au mot de passe. La règle LDAP utilise le nom d'utilisateur pour interroger le fournisseur LDAP pour l'adresse e-mail correspondante, qui est ensuite utilisée pour l'authentification.

Password

Élément vide qui utilise 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é lui-même

SearchQuery

Si vous souhaitez vous authentifier à l’aide d’un attribut DN autre que le nom d’utilisateur, tel que l’adresse e-mail, configurer la règle LDAP de manière à obtenir un attribut DN de la requête (tel que le nom d'utilisateur) ; qui permet d'identifier l'utilisateur dans LDAP, de récupérer l'e-mail et d'authentifier le utilisateur.

Par exemple, en supposant que LDAP définit pour stocker l'adresse 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 à l'aide de métadonnées dans la requête ou la réponse, vous pouvez utiliser cette pour récupérer des attributs DN supplémentaires pour l'utilisateur sur LDAP. Par exemple, si le contient l'adresse e-mail de l'utilisateur, et 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 un e-mail correspondant à l'adresse e-mail de la requête, et le peut désormais récupérer des attributs DN supplémentaires pour cet utilisateur à l'aide de la règle Attributes .

Attributes

Utilisez un ou plusieurs éléments <Attribute> pour identifier les métadonnées DN que vous souhaitez récupérer pour l'utilisateur. Au moins un attribut est obligatoire.

Par exemple, après SearchQuery ayant identifié l'utilisateur, peut désormais récupérer les attributs DN de l'utilisateur, tels que l'adresse, le numéro de téléphone du titre de l'utilisateur, comme illustré dans l'exemple suivant.

Les valeurs d'attribut sont les noms d'attribut 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'exploiter un fournisseur LDAP dans les appels d'API. Avec le LDAP les applications peuvent authentifier les utilisateurs auprès d'utilisateurs récupérer les noms distincts (DN) de LDAP, c'est-à-dire les métadonnées, ou attributs, associés chaque utilisateur (adresse e-mail, adresse postale et numéro de téléphone). Le nom distinctif renvoyé est stocké dans une variable par le proxy d'API.

Créer une ressource LDAP

La règle LDAP exploite une ressource LDAP que vous créez dans Apigee Edge. Une ressource LDAP fournit les informations de connexion à votre référentiel LDAP.

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

API

Créer (POST) une ressource LDAP ou répertorier (GET) toutes les ressources LDAP:

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

Obtenir des détails sur (GET), mettre à jour (POST) et supprimer (DELETE) une ressource LDAP:

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

Charge utile

Voici un exemple de charge utile XML avec des commentaires sur l'utilisation.

<LdapResource name="ldap1">
  <Connection>
    <Hosts>
      <!-- port is optional: defaults to 389 for ldap:// and 636 for ldaps:// -->
      <Host port="636">foo.com</Host>
    </Hosts>
    <SSLEnabled>false</SSLEnabled> <!-- optional, defaults to false -->
    <Version>3</Version> <!-- optional, defaults to 3-->
    <Authentication>simple</Authentication> <!-- optional, only simple supported -->
    <ConnectionProvider>jndi|unboundid</ConnectionProvider> <!-- required -->
    <ServerSetType>single|round robin|failover</ServerSetType> <!-- not applicable for jndi -->
    <!-- If using a custom LDAP provider, the fully qualified class: -->
    <LdapConnectorClass>com.custom.ldap.MyProvider</LdapConnectorClass>
  </Connection>
  <ConnectPool enabled="true"> <!-- enabled is optional, defaults to true -->
    <Timeout>30000</Timeout> <!-- optional, in milliseconds; if not set, no timeout -->
    <Maxsize>50</Maxsize> <!-- optional; if not set, no max connections -->
    <Prefsize>30</Prefsize> <!-- optional; if not set, no pref size -->
    <Initsize></Initsize> <!-- optional; if not set, defaults to 1 -->
    <Protocol></Protocol> <!-- optional; if not set, defaults to 'ssl plain' -->
  </ConnectPool>
  <Admin>
    <DN>cn=manager,dc=apigee,dc=com</DN>
    <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:password -d \
  '<LdapResource name="ldap1">
    <Connection>
      <Hosts>
      <Host>foo.com</Host>
      </Hosts>
      <SSLEnabled>false</SSLEnabled>
      <Version>3</Version>
      <Authentication>simple</Authentication>
      <ConnectionProvider>unboundid</ConnectionProvider>
      <ServerSetType>round robin</ServerSetType>
    </Connection>
    <ConnectPool enabled="true">
      <Timeout>30000</Timeout>
      <Maxsize>50</Maxsize>
      <Prefsize>30</Prefsize>
      <Initsize></Initsize>
      <Protocol></Protocol>
    </ConnectPool>
    <Admin>
      <DN>cn=manager,dc=apigee,dc=com</DN>
      <Password>secret</Password>
    </Admin>
  </LdapResource>'

Codes de réponse

Voici les codes de réponse HTML renvoyés par la stratégie en cas de réussite ou d'échec:

  • Opération réussie: 200
  • Failure (Échec) : 401

Utilisation d'un fournisseur LDAP personnalisé dans Edge pour Private Cloud

Utilisation d'une Fournisseur LDAP

Apigee Edge for Private Cloud est fourni avec un fournisseur LDAP déjà configuré pour interagissent avec la règle LDAP. Toutefois, si vous utilisez un fournisseur LDAP personnalisé, vous devez activer le fournisseur pour qu’il prenne en charge la règle 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 la section <LdapConnectorClass> de la configuration de la règle (sections suivantes), Ajoutez le nom de classe complet de votre fournisseur LDAP personnalisé.
  3. Téléchargez ce 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 le chemin de la classe.
  6. Créez une ressource d'environnement pour votre fournisseur LDAP. Vous utiliserez la ressource d'environnement dans l'élément <LdapResource> de la règle LDAP.

Avec les SDK LDAP UnboundID 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 classpaths 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 et téléchargez le fichier ZIP. pour cette version. Par exemple, téléchargez "unboundid-ldapsdk-2.3.1-se.zip".
  3. Extrayez le fichier JAR du fichier ZIP du SDK, comme illustré dans 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. Elle supprime le répertoire structure avec -j, bien que cela soit facultatif.

  4. Sur chaque nœud du processeur de messages: <ph type="x-smartling-placeholder">
      </ph>
    1. Copiez le fichier JAR dans le répertoire du processeur de messages Répertoire /opt/apigee/edge-gateway/lib/thirdparty.
    2. Si nécessaire, accordez l'autorisation d'utilisateur Apigee au fichier JAR afin que le processeur de messages puisse y accéder.
    3. Edge ajoute toutes les bibliothèques tierces dans le /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 règles LDAP renseignées par un élément 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", en fonction du résultat.

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

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

Si les conditions indiquent l'adresse postale, le numéro de téléphone et l'adresse e-mail, vous pouvez récupérer le premier attribut et "value" à 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 vouliez récupérer le troisième attribut d'adresse dans les résultats de recherche, vous utiliseriez ceci:

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

Si un attribut a plusieurs valeurs (par exemple, si un utilisateur possède plusieurs adresses e-mail des adresses e-mail), vous récupéreriez la deuxième adresse e-mail des résultats de la manière suivante:

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

Codes d'erreur

Les erreurs renvoyées par les stratégies Edge suivent un format cohérent, comme décrit dans la documentation de référence sur le code 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.