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, car elle vous permet d'utiliser n'importe quelle valeur DN avec le mot de passe, même si cette valeur DN
souhaitée ne figure pas dans la requête. Supposons, par exemple, 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 y figure (par exemple, 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 exécuter une requête qui récupère d'autres attributs DN à partir de LDAP pour cet utilisateur. Le DN récupéré est stocké dans une variable.
Utilisez la règle LDAP lorsque l'accès aux ressources protégées doit être limité aux utilisateurs de votre fournisseur LDAP , tels que vos utilisateurs administrateurs, les utilisateurs de l'organisation et les développeurs, en particulier lorsque l'accès au jeton OAuth est inutile ou trop lourd. La règle est également conçue pour récupérer les métadonnées de nom de domaine à utiliser dans les flux de proxy API.
Par exemple, vous pouvez faire en sorte qu'un appel d'API ne s'exécute que lorsqu'un utilisateur est authentifié 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 :
- Gérer la règle de mot de passe LDAP par défaut pour la gestion des API
- "Informations importantes concernant votre règle de mot de passe" dans la communauté Apigee
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 règle transmet le nom d'utilisateur et le mot de passe de la requête à 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 DN 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="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é. Elle 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 DN récupérés sont stockés dans une variable. Consultez la section "Variables spécifiques aux règles variables".
Pour rechercher dans LDAP et récupérer des attributs DN, la requête doit inclure des identifiants d'administrateur identifiants.
Documentation de référence des éléments
Vous trouverez ci-dessous des descriptions des éléments et des attributs de la règle LDAP.
|
Élément |
Description |
|---|---|
|
|
Élément parent avec un attribut name (nom) pour que vous puissiez saisir le nom de la règle. |
|
|
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 |
|
|
Saisissez le nom d'environnement de la ressource LDAP. Pour en savoir plus, consultez la section Créer une ressource LDAP. |
|
|
Niveau de base de LDAP sous lequel toutes vos données existent. Par exemple, dans
le fournisseur LDAP d'Apigee, toutes les données se trouvent sous
|
|
|
|
|
Authentification |
|
|
|
Élément parent pour le comportement d'authentification que vous implémentez. |
|
|
Élément vide qui accepte l'un des attributs suivants :
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, tel qu'une adresse e-mail, incluez un |
|
|
Élément vide qui accepte l'un des attributs suivants :
|
|
|
Si vous souhaitez vous authentifier à l'aide d'un attribut DN autre que le nom d'utilisateur, tel qu'une adresse e-mail, configurez la règle LDAP pour obtenir un attribut DN à partir de la requête (tel que 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 l'adresse e-mail :
|
|
Rechercher |
|
|
|
Élément parent pour le comportement de recherche que vous implémentez. |
|
|
En identifiant l'utilisateur à l'aide de métadonnées dans la requête ou la réponse, vous pouvez utiliser cet
élément pour récupérer d'autres attributs DN pour l'utilisateur à partir de LDAP. Par exemple, si la
requête contient l'adresse e-mail de l'utilisateur et que votre LDAP définit un attribut
Cette requête recherche dans LDAP une adresse e-mail correspondant à celle de la requête. La règle peut désormais récupérer d'autres attributs DN pour cet utilisateur avec l'élément Attributes . |
|
|
Utilisez un ou plusieurs Par exemple, une fois que 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 le cloud privé vous permet d'exploiter un fournisseur LDAP dans les appels d'API. Avec la règle LDAP , les applications peuvent authentifier les identifiants par rapport aux utilisateurs stockés dans LDAP, et vous pouvez récupérer les noms distinctifs (DN) à partir de LDAP : les métadonnées ou attributs associés à chaque utilisateur, tels que l'adresse e-mail, l'adresse et le numéro de téléphone. Le DN renvoyé est stocké dans une variable pour être utilisé ultérieurement par le proxy 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 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 détails (GET), mettez à jour (POST) et supprimez (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 d'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 règle en cas de succès ou d'échec :
- Opération réussie : 200
- Échec : 401
Utiliser un fournisseur LDAP personnalisé dans Edge pour le cloud privé
Utiliser un fournisseur LDAP personnalisé
Apigee Edge pour le cloud privé est fourni avec un fournisseur LDAP déjà configuré pour interagir avec la règle LDAP. Toutefois, si vous utilisez un fournisseur LDAP personnalisé, vous devez activer le fournisseur pour qu'il soit compatible avec la règle LDAP. Pour ce faire :
- Dans la classe de votre 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(); } - Dans le
<LdapConnectorClass>de la configuration de la règle (sections suivantes), ajoutez le nom de classe complet de votre fournisseur LDAP personnalisé. - Téléchargez ce fichier : custom-ldap.jar_.zip. (Vous devrez peut-être cliquer avec le bouton droit de la souris et sélectionner Enregistrer sous.)
- Décompressez-le.
- Ajoutez le fichier custom-ldap.jar à votre environnement et assurez-vous qu'il se trouve dans votre classpath.
- Créez une ressource d'environnement pour votre fournisseur LDAP. Vous utiliserez le nom de la ressource d'environnement dans l'élément
<LdapResource>de la règle LDAP.
Utiliser le 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 au classpath de chacun de vos processeurs de messages.
Pour utiliser le SDK LDAP UnboundID avec la règle LDAP :
- 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/
- Recherchez la version 2.3.1 (SE ou Standard Edition) du SDK et téléchargez le fichier ZIP correspondant. Par exemple, téléchargez "unboundid-ldapsdk-2.3.1-se.zip".
- 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 la structure de répertoire avec
-j, bien que cela soit facultatif. - Sur chaque nœud de processeur de messages :
- Copiez le fichier JAR dans le répertoire
/opt/apigee/edge-gateway/lib/thirdpartydu processeur de messages. - Si nécessaire, accordez l'autorisation d'utilisateur Apigee sur le fichier JAR afin que le processeur de messages puisse y accéder.
- Redémarrez le processeur de messages :
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Edge ajoute toutes les bibliothèques tierces du
/opt/apigee/edge-gateway/lib/thirdpartyrépertoire au classpath. - Copiez le fichier JAR dans le répertoire
Variables de flux
Voici les variables de la règle LDAP renseignées par une 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, le numéro d'index 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 la variable suivante : 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 devez récupérer la deuxième adresse e-mail dans les 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. |