LDAP-политика

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee
X.info

Что

Политика LDAP предусматривает:

  • Аутентификация : Учетные данные пользователя, предоставленные в запросе, проверяются на соответствие учетным данным в LDAP-провайдере. Политика LDAP предоставляет большую гибкость в аутентификации, позволяя использовать любое значение DN вместе с паролем, даже если это значение DN отсутствует в запросе. Например, предположим, вам нужно использовать электронную почту/пароль для аутентификации. Возможны следующие варианты:
    • Если адрес электронной почты указан в запросе, вы можете просто использовать его вместе с паролем для аутентификации LDAP.
    • Если адрес электронной почты отсутствует в запросе, но присутствует другой атрибут DN (например, номер телефона), вы можете использовать номер телефона, чтобы получить соответствующий адрес электронной почты из LDAP, а затем использовать адрес электронной почты и пароль для аутентификации.
  • Поиск по отличительному имени (DN) : Помимо аутентификации, вы также можете использовать политику LDAP для идентификации атрибута пользователя в запросе, например, адреса электронной почты, и выполнить запрос, который извлекает другие атрибуты DN из LDAP для этого пользователя. Полученное DN сохраняется в переменной.

Используйте политику LDAP, когда доступ к защищенным ресурсам должен быть ограничен пользователями вашего LDAP-провайдера — такими как администраторы, пользователи организации и разработчики, — особенно когда доступ с помощью токенов OAuth либо не нужен, либо слишком ресурсоемок. Политика также предназначена для получения метаданных доменных имен для использования в потоках API-прокси.

Например, можно настроить вызов API таким образом, чтобы он выполнялся только после успешной аутентификации пользователя в LDAP; а затем, при необходимости, после успешной аутентификации можно было бы получить атрибуты DN (доменного имени) для этого пользователя.

Для получения дополнительной информации см.:

Образцы

Аутентификация по имени пользователя/паролю

<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>

В этом примере реализована аутентификация через LDAP-провайдер. Политика передает имя пользователя и пароль из запроса в LDAP для аутентификации.

аутентификация атрибутов 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>

Данная политика получает DN пользователя вместе с адресом электронной почты в заголовке запроса, а затем аутентифицирует пользователя в LDAP с помощью пароля, указанного в заголовке запроса.

Поиск в 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>

Данная политика использует пользовательский LDAP-провайдер. Она использует адрес электронной почты в заголовке запроса для идентификации пользователя, а затем извлекает из LDAP адрес, телефон и должность пользователя. Полученные атрибуты DN сохраняются в переменной. См. раздел «Переменные, специфичные для политики».

Для поиска в LDAP и получения атрибутов DN запрос должен включать учетные данные администратора.

Ссылка на элемент

Ниже приведено описание элементов и атрибутов политики LDAP.

Элемент

Описание

Ldap

Родительский элемент с атрибутом name, в который вы можете ввести название политики.

LdapConnectorClass

При использовании политики LDAP с пользовательским поставщиком LDAP (не предоставляемым Apigee) укажите полный класс коннектора LDAP. Это класс, в котором вы реализовали интерфейс ExternalLdapConProvider от Apigee.

LdapResource

Введите имя среды для ресурса LDAP. Дополнительную информацию см. в разделе «Создание ресурса LDAP» .

BaseDN

Базовый уровень LDAP, на котором хранятся все ваши данные. Например, в LDAP-провайдере Apigee все данные находятся в каталоге dc=apigee,dc=com .

  • ref : Используется для указания переменной потока, содержащей значение BaseDN, например apigee.baseDN. ref имеет приоритет над явно указанным значением BaseDN. Если вы указываете и ref, и value, приоритет имеет ref. Если ref не определяется во время выполнения, используется value.

Scope

  • Объект : Аутентификация или поиск происходят только на базовом уровне LDAP.
  • Одноуровневая аутентификация : Аутентификация или поиск осуществляется на один уровень ниже базового уровня.
  • Поддерево (по умолчанию): Аутентификация или поиск происходят на базовом уровне и полностью рекурсивно ниже базового уровня.

Аутентификация

Authentication

Родительский элемент для реализуемого вами механизма аутентификации.

UserName

Пустой элемент, принимающий один из следующих атрибутов:

  • ref : Ссылка на имя пользователя в запросе, например, request.header.username
  • значение : само имя пользователя

Если вы не используете имя пользователя для аутентификации или если имя пользователя не включено в запрос, вам не нужно добавлять этот элемент.

Если в запросе присутствует имя пользователя, но вы хотите аутентифицировать пользователя с помощью атрибута DN, отличного от имени пользователя, например, электронной почты, добавьте SearchQuery для получения адреса электронной почты пользователя, связанного с паролем. Политика LDAP использует имя пользователя для запроса у поставщика LDAP соответствующего адреса электронной почты, который затем используется для аутентификации.

Password

Пустой элемент, принимающий один из следующих атрибутов:

  • ref : Ссылка на пароль в запросе, например, request.header.password
  • значение : сам зашифрованный пароль

SearchQuery

Если вы хотите аутентифицироваться, используя атрибут DN, отличный от имени пользователя, например, адрес электронной почты, настройте политику LDAP таким образом, чтобы она получала атрибут DN из запроса (например, имя пользователя), который используется для идентификации пользователя в LDAP, получения адреса электронной почты и аутентификации пользователя.

Например, предположим, что LDAP определяет атрибут "mail" для хранения адресов электронной почты:

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

Поиск

Search

Родительский элемент для реализуемого вами механизма поиска.

SearchQuery

Идентифицируя пользователя с помощью метаданных в запросе или ответе, вы можете использовать этот элемент для получения дополнительных атрибутов DN для пользователя из LDAP. Например, если запрос содержит адрес электронной почты пользователя, и ваш LDAP определяет атрибут mail для хранения адресов электронной почты пользователей, вы будете использовать следующую настройку:

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

Этот запрос выполняет поиск в LDAP адреса электронной почты, соответствующего адресу электронной почты в запросе, и теперь политика может получить дополнительные атрибуты DN для этого пользователя с помощью элемента Attributes.

Attributes

Используйте один или несколько элементов <Attribute> для идентификации метаданных DN, которые вы хотите получить для пользователя. Необходимо наличие как минимум одного атрибута.

Например, после того как SearchQuery идентифицирует пользователя, политика может получить атрибуты DN для пользователя, такие как адрес, номер телефона и должность пользователя, как показано в следующем примере.

Значения атрибутов — это имена атрибутов DN, определенные в вашем LDAP.

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

Примечания по использованию

Apigee Edge for Private Cloud позволяет использовать LDAP-провайдер в API-запросах. С помощью политики LDAP приложения могут аутентифицировать учетные данные пользователей, хранящихся в LDAP, и получать из LDAP отличительные имена (DN) — метаданные, или атрибуты, связанные с каждым пользователем, такие как электронная почта, адрес и номер телефона. Возвращенное DN сохраняется в переменной для дальнейшего использования API-прокси.

Создайте ресурс LDAP.

Политика LDAP использует ресурс LDAP, который вы создаете в Apigee Edge. Ресурс LDAP предоставляет информацию для подключения к вашему репозиторию LDAP.

Для создания и управления ресурсами LDAP используйте следующий API и полезную нагрузку:

API

Создать ( POST ) ресурс LDAP или получить список ( GET ) всех ресурсов LDAP:

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

Получение подробной информации о ресурсе LDAP ( GET ), его обновление ( POST ) и удаление ( DELETE ):

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

Полезная нагрузка

Ниже приведён пример XML-данных с комментариями по их использованию.

<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>

Пример использования curl: Создание ресурса LDAP

В следующем примере создается ресурс LDAP с именем 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>'

Коды ответов

Ниже приведены HTML-коды ответа, которые возвращает политика в случае успеха или неудачи:

  • Успех : 200
  • Сбой : 401

Использование пользовательского LDAP-провайдера в Edge для частного облака

Использование пользовательского LDAP-провайдера

Apigee Edge for Private Cloud поставляется с уже настроенным LDAP-провайдером для взаимодействия с LDAP-политиками. Однако, если вы используете собственный LDAP-провайдер, необходимо включить его поддержку для работы с LDAP-политиками. Для этого:

  1. В классе вашего LDAP-провайдера реализуйте интерфейс 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. В поле <LdapConnectorClass> конфигурации политики (в следующих разделах) добавьте полное имя класса вашего пользовательского поставщика LDAP.
  3. Скачайте этот файл: custom-ldap.jar_.zip . (Возможно, вам потребуется щелкнуть правой кнопкой мыши и выбрать «Сохранить как ».)
  4. Распакуйте архив.
  5. Добавьте файл custom-ldap.jar в переменную среды и убедитесь, что он находится в вашем classpath.
  6. Создайте ресурс среды для вашего LDAP-провайдера. Имя ресурса среды будет использоваться в элементе <LdapResource> политики LDAP.

Использование UnboundID LDAP SDK для Java

Вы можете использовать UnboundID LDAP SDK с политикой LDAP, но сначала необходимо загрузить версию 2.3.1 и добавить ее в пути к классам каждого из ваших обработчиков сообщений.

Для использования UnboundID LDAP SDK с политикой LDAP:

  1. Откройте браузер и перейдите в репозиторий Sourceforge, содержащий SDK UnboundID LDAP:
    https://sourceforge.net/projects/ldap-sdk/files/
  2. Найдите версию 2.3.1 (SE или Standard Edition ) SDK и загрузите ZIP-файл для этой версии. Например, загрузите файл "unboundid-ldapsdk-2.3.1-se.zip".
  3. Извлеките JAR-файл из ZIP-архива SDK, как показано в следующем примере:
    unzip -j -d ~/tmp ~/Downloads/unboundid-ldapsdk-2.3.1-se.zip unboundid-ldapsdk-2.3.1-se/unboundid-ldapsdk-se.jar

    Эта команда извлекает только JAR-файл в каталог ~/tmp. Она удаляет структуру каталогов с помощью -j , хотя это необязательно.

  4. На каждом узле обработчика сообщений:
    1. Скопируйте JAR-файл в каталог /opt/apigee/edge-gateway/lib/thirdparty обработчика сообщений.
    2. При необходимости предоставьте пользователю Apigee права доступа к JAR-файлу, чтобы обработчик сообщений мог получить к нему доступ.
    3. Edge добавляет все сторонние библиотеки из каталога /opt/apigee/edge-gateway/lib/thirdparty в classpath.

    4. Перезапустите обработчик сообщений:
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Переменные потока

Ниже приведены переменные политики LDAP, заполняемые SearchQuery .

Переменная

Описание

ldap.policyName.execution.success

После выполнения политики эта переменная потока будет содержать значение «true» или «alse» в зависимости от результата.

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

Гибкий формат этой переменной, в частности индекса, позволяет учитывать как множественные атрибуты, так и атрибуты с несколькими значениями. Индекс — это число, начинающееся с 1. Если номер индекса не указан, по умолчанию используется номер индекса 1.

Если политика возвращает адрес, телефон и электронную почту, вы можете получить первый атрибут и его значение, используя следующие переменные:

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

Если вам нужно получить третий атрибут адреса в результатах поиска, используйте следующий код:

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

Если атрибут имеет несколько значений (например, если у пользователя несколько адресов электронной почты), то второй адрес электронной почты можно получить из результатов следующим образом:

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

коды ошибок

Ошибки, возвращаемые политиками Edge, имеют согласованный формат, описанный в справочнике кодов ошибок .

Эта политика использует следующие коды ошибок:

Код ошибки Сообщение
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.

,

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee
X.info

Что

Политика LDAP предусматривает:

  • Аутентификация : Учетные данные пользователя, предоставленные в запросе, проверяются на соответствие учетным данным в LDAP-провайдере. Политика LDAP предоставляет большую гибкость в аутентификации, позволяя использовать любое значение DN вместе с паролем, даже если это значение DN отсутствует в запросе. Например, предположим, вам нужно использовать электронную почту/пароль для аутентификации. Возможны следующие варианты:
    • Если адрес электронной почты указан в запросе, вы можете просто использовать его вместе с паролем для аутентификации LDAP.
    • Если адрес электронной почты отсутствует в запросе, но присутствует другой атрибут DN (например, номер телефона), вы можете использовать номер телефона, чтобы получить соответствующий адрес электронной почты из LDAP, а затем использовать адрес электронной почты и пароль для аутентификации.
  • Поиск по отличительному имени (DN) : Помимо аутентификации, вы также можете использовать политику LDAP для идентификации атрибута пользователя в запросе, например, адреса электронной почты, и выполнить запрос, который извлекает другие атрибуты DN из LDAP для этого пользователя. Полученное DN сохраняется в переменной.

Используйте политику LDAP, когда доступ к защищенным ресурсам должен быть ограничен пользователями вашего LDAP-провайдера — такими как администраторы, пользователи организации и разработчики, — особенно когда доступ с помощью токенов OAuth либо не нужен, либо слишком ресурсоемок. Политика также предназначена для получения метаданных доменных имен для использования в потоках API-прокси.

Например, можно настроить вызов API таким образом, чтобы он выполнялся только после успешной аутентификации пользователя в LDAP; а затем, при необходимости, после успешной аутентификации можно было бы получить атрибуты DN (доменного имени) для этого пользователя.

Для получения дополнительной информации см.:

Образцы

Аутентификация по имени пользователя/паролю

<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>

В этом примере реализована аутентификация через LDAP-провайдер. Политика передает имя пользователя и пароль из запроса в LDAP для аутентификации.

аутентификация атрибутов 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>

Данная политика получает DN пользователя вместе с адресом электронной почты в заголовке запроса, а затем аутентифицирует пользователя в LDAP с помощью пароля, указанного в заголовке запроса.

Поиск в 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>

Данная политика использует пользовательский LDAP-провайдер. Она использует адрес электронной почты в заголовке запроса для идентификации пользователя, а затем извлекает из LDAP адрес, телефон и должность пользователя. Полученные атрибуты DN сохраняются в переменной. См. раздел «Переменные, специфичные для политики».

Для поиска в LDAP и получения атрибутов DN запрос должен включать учетные данные администратора.

Ссылка на элемент

Ниже приведено описание элементов и атрибутов политики LDAP.

Элемент

Описание

Ldap

Родительский элемент с атрибутом name, в который вы можете ввести название политики.

LdapConnectorClass

При использовании политики LDAP с пользовательским поставщиком LDAP (не предоставляемым Apigee) укажите полный класс коннектора LDAP. Это класс, в котором вы реализовали интерфейс ExternalLdapConProvider от Apigee.

LdapResource

Введите имя среды для ресурса LDAP. Дополнительную информацию см. в разделе «Создание ресурса LDAP» .

BaseDN

Базовый уровень LDAP, на котором хранятся все ваши данные. Например, в LDAP-провайдере Apigee все данные находятся в каталоге dc=apigee,dc=com .

  • ref : Используется для указания переменной потока, содержащей значение BaseDN, например apigee.baseDN. ref имеет приоритет над явно указанным значением BaseDN. Если вы указываете и ref, и value, приоритет имеет ref. Если ref не определяется во время выполнения, используется value.

Scope

  • Объект : Аутентификация или поиск происходят только на базовом уровне LDAP.
  • Одноуровневая аутентификация : Аутентификация или поиск осуществляется на один уровень ниже базового уровня.
  • Поддерево (по умолчанию): Аутентификация или поиск происходят на базовом уровне и полностью рекурсивно ниже базового уровня.

Аутентификация

Authentication

Родительский элемент для реализуемого вами механизма аутентификации.

UserName

Пустой элемент, принимающий один из следующих атрибутов:

  • ref : Ссылка на имя пользователя в запросе, например, request.header.username
  • значение : само имя пользователя

Если вы не используете имя пользователя для аутентификации или если имя пользователя не включено в запрос, вам не нужно добавлять этот элемент.

Если в запросе присутствует имя пользователя, но вы хотите аутентифицировать пользователя с помощью атрибута DN, отличного от имени пользователя, например, электронной почты, добавьте SearchQuery для получения адреса электронной почты пользователя, связанного с паролем. Политика LDAP использует имя пользователя для запроса у поставщика LDAP соответствующего адреса электронной почты, который затем используется для аутентификации.

Password

Пустой элемент, принимающий один из следующих атрибутов:

  • ref : Ссылка на пароль в запросе, например, request.header.password
  • значение : сам зашифрованный пароль

SearchQuery

Если вы хотите аутентифицироваться, используя атрибут DN, отличный от имени пользователя, например, адрес электронной почты, настройте политику LDAP таким образом, чтобы она получала атрибут DN из запроса (например, имя пользователя), который используется для идентификации пользователя в LDAP, получения адреса электронной почты и аутентификации пользователя.

Например, предположим, что LDAP определяет атрибут "mail" для хранения адресов электронной почты:

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

Поиск

Search

Родительский элемент для реализуемого вами механизма поиска.

SearchQuery

Идентифицируя пользователя с помощью метаданных в запросе или ответе, вы можете использовать этот элемент для получения дополнительных атрибутов DN для пользователя из LDAP. Например, если запрос содержит адрес электронной почты пользователя, и ваш LDAP определяет атрибут mail для хранения адресов электронной почты пользователей, вы будете использовать следующую настройку:

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

Этот запрос выполняет поиск в LDAP адреса электронной почты, соответствующего адресу электронной почты в запросе, и теперь политика может получить дополнительные атрибуты DN для этого пользователя с помощью элемента Attributes.

Attributes

Используйте один или несколько элементов <Attribute> для идентификации метаданных DN, которые вы хотите получить для пользователя. Необходимо наличие как минимум одного атрибута.

Например, после того как SearchQuery идентифицирует пользователя, политика может получить атрибуты DN для пользователя, такие как адрес, номер телефона и должность пользователя, как показано в следующем примере.

Значения атрибутов — это имена атрибутов DN, определенные в вашем LDAP.

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

Примечания по использованию

Apigee Edge for Private Cloud позволяет использовать LDAP-провайдер в API-запросах. С помощью политики LDAP приложения могут аутентифицировать учетные данные пользователей, хранящихся в LDAP, и получать из LDAP отличительные имена (DN) — метаданные, или атрибуты, связанные с каждым пользователем, такие как электронная почта, адрес и номер телефона. Возвращенное DN сохраняется в переменной для дальнейшего использования API-прокси.

Создайте ресурс LDAP.

Политика LDAP использует ресурс LDAP, который вы создаете в Apigee Edge. Ресурс LDAP предоставляет информацию для подключения к вашему репозиторию LDAP.

Для создания и управления ресурсами LDAP используйте следующий API и полезную нагрузку:

API

Создать ( POST ) ресурс LDAP или получить список ( GET ) всех ресурсов LDAP:

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

Получение подробной информации о ресурсе LDAP ( GET ), его обновление ( POST ) и удаление ( DELETE ):

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

Полезная нагрузка

Ниже приведён пример XML-данных с комментариями по их использованию.

<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>

Пример использования curl: Создание ресурса LDAP

В следующем примере создается ресурс LDAP с именем 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>'

Коды ответов

Ниже приведены HTML-коды ответа, которые возвращает политика в случае успеха или неудачи:

  • Успех : 200
  • Сбой : 401

Использование пользовательского LDAP-провайдера в Edge для частного облака

Использование пользовательского LDAP-провайдера

Apigee Edge for Private Cloud поставляется с уже настроенным LDAP-провайдером для взаимодействия с LDAP-политиками. Однако, если вы используете собственный LDAP-провайдер, необходимо включить его поддержку для работы с LDAP-политиками. Для этого:

  1. В классе вашего LDAP-провайдера реализуйте интерфейс 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. В поле <LdapConnectorClass> конфигурации политики (в следующих разделах) добавьте полное имя класса вашего пользовательского поставщика LDAP.
  3. Скачайте этот файл: custom-ldap.jar_.zip . (Возможно, вам потребуется щелкнуть правой кнопкой мыши и выбрать «Сохранить как ».)
  4. Распакуйте архив.
  5. Добавьте файл custom-ldap.jar в переменную среды и убедитесь, что он находится в вашем classpath.
  6. Создайте ресурс среды для вашего LDAP-провайдера. Имя ресурса среды будет использоваться в элементе <LdapResource> политики LDAP.

Использование UnboundID LDAP SDK для Java

Вы можете использовать UnboundID LDAP SDK с политикой LDAP, но сначала необходимо загрузить версию 2.3.1 и добавить ее в пути к классам каждого из ваших обработчиков сообщений.

Для использования UnboundID LDAP SDK с политикой LDAP:

  1. Откройте браузер и перейдите в репозиторий Sourceforge, содержащий SDK UnboundID LDAP:
    https://sourceforge.net/projects/ldap-sdk/files/
  2. Найдите версию 2.3.1 (SE или Standard Edition ) SDK и загрузите ZIP-файл для этой версии. Например, загрузите файл "unboundid-ldapsdk-2.3.1-se.zip".
  3. Извлеките JAR-файл из ZIP-архива SDK, как показано в следующем примере:
    unzip -j -d ~/tmp ~/Downloads/unboundid-ldapsdk-2.3.1-se.zip unboundid-ldapsdk-2.3.1-se/unboundid-ldapsdk-se.jar

    Эта команда извлекает только JAR-файл в каталог ~/tmp. Она удаляет структуру каталогов с помощью -j , хотя это необязательно.

  4. На каждом узле обработчика сообщений:
    1. Скопируйте JAR-файл в каталог /opt/apigee/edge-gateway/lib/thirdparty обработчика сообщений.
    2. При необходимости предоставьте пользователю Apigee права доступа к JAR-файлу, чтобы обработчик сообщений мог получить к нему доступ.
    3. Edge добавляет все сторонние библиотеки из каталога /opt/apigee/edge-gateway/lib/thirdparty в classpath.

    4. Перезапустите обработчик сообщений:
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Переменные потока

Ниже приведены переменные политики LDAP, заполняемые SearchQuery .

Переменная

Описание

ldap.policyName.execution.success

После выполнения политики эта переменная потока будет содержать значение «true» или «alse» в зависимости от результата.

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

Гибкий формат этой переменной, в частности индекса, позволяет учитывать как множественные атрибуты, так и атрибуты с несколькими значениями. Индекс — это число, начинающееся с 1. Если номер индекса не указан, по умолчанию используется номер индекса 1.

Если политика возвращает адрес, телефон и электронную почту, вы можете получить первый атрибут и его значение, используя следующие переменные:

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

Если вам нужно получить третий атрибут адреса в результатах поиска, используйте следующий код:

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

Если атрибут имеет несколько значений (например, если у пользователя несколько адресов электронной почты), то второй адрес электронной почты можно получить из результатов следующим образом:

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

коды ошибок

Ошибки, возвращаемые политиками Edge, имеют согласованный формат, описанный в справочнике кодов ошибок .

Эта политика использует следующие коды ошибок:

Код ошибки Сообщение
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.