Конфигурирование доступных атрибутов

Общие сведения

Для корректной работы Blitz Identity Provider требуется указать, какие атрибуты будут использоваться в системе. Атрибуты используются в следующих целях:

  • для проведения идентификации и аутентификации пользователей;

  • для передачи подключенным к Blitz Identity Provider приложениям.

Атрибуты формируются из разных источников. Атрибуты могут:

  • вестись во внешних хранилищах атрибутов (например, в LDAP-каталогах), к которым подключен Blitz Identity Provider (см. подробнее здесь);

  • вестись в базе данных Blitz Identity Provider – чтение/сохранение атрибута в базе данных Blitz Identity Provider осуществляется в случае, если для атрибута не настроена связка с его хранением во внешнем хранилище атрибутов;

  • вычисляться на основе других атрибутов или заполняться константными значениями. Например, можно вычислять атрибут «домен пользователя» из адреса электронной почты или создать композитный атрибут «ФИО» из отдельных атрибутов с фамилией, именем и отчеством пользователя.

Конфигурирование атрибутов может включать в себя:

  • настройку хранимых атрибутов, т.е. тех, которые ведутся в подключенных хранилищах или внутренней базе данных Blitz Identity Provider;

  • настройка вычисляемых атрибутов, т.е. тех, которые должны принимать константное значение или которые вычисляются по правилам;

  • настройка правил преобразования входных значений, позволяющих преобразовывать значения атрибутов при их изменении (например, при редактировании пользователем или при вызове соответствующих API);

  • настройка правил преобразования выходных значений, позволяющих провести дополнительные преобразования с вычисляемыми атрибутами;

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

Для корректной работы Blitz Identity Provider как минимум должны быть выполнены следующие настройки:
- сконфигурированы необходимые хранимые атрибуты;
- один из хранимых атрибутов определен в качестве идентификатора.


Настройка хранимых атрибутов

Для конфигурирования перечня хранимых атрибутов, которые будут доступны Blitz Identity Provider, необходимо в разделе Источники данных перейти в блок «Хранимые атрибуты» и выполнить следующие шаги:

  • добавить новый атрибут, нажав на ссылку «+Добавить атрибут»;

  • указать наименование атрибута, которое будет использоваться в Blitz Identity Provider; Наименование атрибута может отличаться от его имени во внешнем хранилище (в таком случае необходимо указать правило преобразования в настройках этого хранилища);

  • указать тип значения данных – формат данных;

  • определить параметры атрибута:

    • возможно ли производить по нему поиск (колонка «Поиск») ;
    • является ли атрибут обязательным (колонка «Обяз»);
    • должно ли значение атрибута быть уникальным в системе (колонка «Уник»).

После добавления атрибута недопустимо менять его имя. При необходимости переименования атрибута следует удалить атрибут и создать новый.

Если удалить атрибут, значения которого хранились в базе данных Blitz Identity Provider, а не в подключенных хранилищах, то сохраненные значения атрибута будут потеряны.


Пример настройки хранимых атрибутов

Настройка вычисляемых атрибутов

Для настройки вычисляемых атрибутов в блоке «Вычисляемые атрибуты» необходимо совершить следующие действия:

  • добавить новый атрибут, нажав на ссылку «+Добавить атрибут»;

  • указать наименование вычисляемого атрибута;

  • указать тип значения данных – формат данных;

  • указать правило вычисления атрибута на основе других атрибутов или присвоения ему константного значения. Примеры правил:

  • чтобы создать атрибут «Имя и фамилия» из хранимых атрибутов firstname и lastname необходимо определить хранимые атрибуты firstname и lastname, а далее задать вычисляемый атрибут fullname с правилом вычисления – ${firstname} ${lastname}.

  • чтобы создать атрибут «домен электронной почты» из хранимого атрибута mail необходимо определить хранимый атрибут mail, а далее задать вычисляемый атрибут domain и определить его правило вычисления ${mail##*@}.

Пример настройки вычисляемых атрибутов

Настройка правил преобразования входных значений

Правила преобразования входных значений позволяют проверять корректность формата ввода данных и обеспечивают сохранение данных в корректном формате. Правила задаются с помощью регулярных выражений. Каждое правило включает в себя регулярное выражение, позволяющее провести декомпозицию (разбиения на части) введенного значения, и правило сохранения полученных частей (компоновка). Пример решаемых задач:

  • для проверки, что атрибут mail содержит знак @, необходимо указать выражение декомпозиции ^(.+)@(.+)$ и выражение компоновки ${0-};

  • для проверки формата мобильного телефона (mobile) и сохранения его в формате +7(999)1234567, необходимо указать выражение декомпозиции ^(\+?)([78]?) ?\(?([0-9]{3})\)? ?([0-9]{3})[- ]?([0-9]{2})[- ]?([0-9]{2})$ и выражение компоновки +7(${3-})${4-}${5-}${6-}.

Пример настройки правил преобразования входных значений

Настройка правил преобразования входных значений

Эти правила позволяют совершить дополнительные преобразования с вычисляемыми атрибутами. Например, из атрибута с массивом ролей могут быть извлечены только необходимые роли. Пример настройки такого правила преобразования представлен на рисунке ниже.

Пример настройки правил преобразования выходных значений

Настройка назначения атрибутов

Необходимо указать, какой атрибут будет идентификатором в системе. Идентификатор должен быть уникальным и не меняться со временем.

Не рекомендуется в будущем менять базовый идентификатор, т.к. все специфические пользовательские настройки привязываются именно к нему. Например, при изменении базового идентификатора могут быть потеряны настройки двухфакторной аутентификации пользователей, зарегистрированные на пользователей события безопасности, запомненные списки устройств пользователей и хранимые во внутренней базе данных Blitz Identity Provider атрибуты пользователей.


Также можно указать, какие атрибуты используются для специальных целей:

  • Атрибут, используемый в качестве признака блокировки учетной записи. Этот атрибут должен иметь тип значения Boolean. Blitz Identity Provider поддерживает блокировку пользователей, хранимых в LDAP-каталоге. Для использования этой функции также требуется настроить соответствующий атрибут в настройках LDAP-каталога.

  • Атрибуты, используемые для хранения адресов электронной почты.

  • Атрибуты, используемые для хранения номером мобильных телефонов.

В качестве контактов (электронная почта, номер мобильного телефона) могут быть указаны несколько атрибутов (например, у пользователя может быть личный и рабочий адреса электронной почты).

Конфигурирование назначения атрибутов

Подключение хранилищ атрибутов

Типы хранилищ

В качестве хранилищ атрибутов пользователей Blitz Identity Provider позволяет использовать:

  • внешнее (подключенное) хранилище. В качестве такового может выступать:

    • LDAP-хранилище – это может быть любой сервер, поддерживающий протокол LDAP (389 Directory Server, Oracle Directory Server, OpenLDAP и другие), а также Microsoft Active Directory или Samba4;

    • иное хранилище, для подключения которого к Blitz Identity Provider необходимо разработать специальные REST-сервисы (подробнее здесь). Данная возможность доступна только для Enterprise-редакции Blitz Identity Provider.

  • внутреннее хранилище Blitz Identity Provider. При использовании такого хранилища все идентификационные данные пользователей хранятся в БД Blitz Identity Provider .

Для корректной работы Blitz Identity Provider требуется настройка хотя бы одного хранилища и конфигурирование атрибутов. По умолчанию настроено внутреннее хранилище и добавлен ряд атрибутов.

Следует учесть, что данные отдельного пользователя могут храниться только в одном внешнем хранилище. Система допускает конфигурирование и подключение нескольких внешних хранилищ, однако рекомендуется использовать одно основное хранилище для работы. Решение об использовании второго хранилища должно быть принято с учетом применяемой модели данных. Например, в подключенном LDAP-хранилище можно хранить данные сотрудников организации, а во внутреннем хранилище – данные специально зарегистрированных «внешних» пользователей (сотрудники партнерских организаций, фрилансеры и пр.).


Выбор и настройка используемого хранилища осуществляется после настройки атрибутов в разделе Источники данных. По умолчанию настроено внутреннее хранилище. Для добавления внешнего хранилища следует нажать на кнопку «Добавить новое хранилище», после чего указать тип внешнего хранилища и настроить параметры взаимодействия с ним.

Допустимо удалить внутреннее хранилище, если его не планируется использовать. Для этого необходимо перейти в свойства соответствующего внешнего хранилища и нажать на кнопку «Удалить».

Использование нескольких хранилищ может решить задачу входа пользователей, хранящихся в разных LDAP-каталогах или в разных ветках одного каталога. Например, в результате объединения двух компаний можно подключить два каталога к Blitz Identity Provider и обеспечить вход пользователей, не прибегая к настройкам доверия, построению метакаталога и пр.

Экран добавления хранилища учетных записей

Подключение внешнего LDAP-хранилища

Если в качестве источника идентификационных данных используется LDAP-хранилище, развернутое в организации, для его настройки необходимо воспользоваться разделом Источники данных консоли управления и выполнить следующие шаги:

  • добавить новое хранилище, указать следующие данные:

    • тип добавляемого хранилища – выбрать LDAP;

    • адрес хранилища;

    • порт;

    • отметить галочку «Использовать SSL», если должно использоваться защищенное соединение.

  • сконфигурировать LDAP-хранилище, настроив следующие параметры:

    • описание хранилища (опционально);

    • использует ли хранилище только для чтения данных или возможна запись в него;

    • необходимость использования SSL-соединения;

    • необходимость DNS-балансировки вызовов к LDAP-хранилищу – для этого нажать кнопку «DNS-балансировка» и задать параметры «Доменное имя», «Порт», «Использовать SSL», «Режим работы», «Время хранения в кэше, мс»;

    При DNS-балансировке Blitz Identity Provider запрашивает у DNS-сервера по заданному доменному имени LDAP-каталога все адреса подключения. Если в DNS прописано более одного адреса, то в зависимости от выбранного режима работы Blitz устанавливает подключение к первому доступному серверу (режим работы FAILOVER), к случайному серверу (режим работы RANDOM) или к каждому серверу по очереди (режим работы ROUND_ROBIN). Полученный от DNS список серверов хранится в кэше Blitz Identity Provider в течение времени, заданного в настройке «Время хранения в кэше, мс».

    • настройки пула соединений;
  • указать логин и пароль пользователя, от имени которого будет осуществляться работа с LDAP-хранилищем (Допустимо указать пользователя только с правами на чтение, если хранилище используется только для чтения), а также раздел каталога с учетными записями пользователей;

  • указать настройки поиска – глубину поиска и максимальное число возвращаемых учетных записей (это влияет на число пользователей, отображаемых в разделе Пользователи консоли управления).

Настройка подключения к LDAP-хранилищу данных (фрагмент)

Дополнительно можно настроить правила сопоставления атрибутов. Это необходимо делать лишь в том случае, если названия атрибутов в системе аутентификации не совпадают с названиями атрибутов в LDAP-каталоге. И для чтения, и для записи можно указать правила разбиения и правила преобразования значений атрибутов. Это позволяет:

  • дать атрибуту в системе другое название, не совпадающее с его именем в LDAP-каталоге. Например, если в LDAP-каталоге атрибут задан как sn, а в Blitz Identity Provider необходимо его использовать как surname, то выберите атрибут surname и укажите sn в качестве его названия в LDAP. Пример такой настройки приведен на рисунке ниже;

  • использовать специальные правила записи атрибутов в данный LDAP-каталога. Например, если вы хотите сохранять мобильный телефон в формате +7(999)1234567 в LDAP-каталог без скобок, то для записи задайте правило разбиения ^\+7\(([0-9]{3})\)([0-9]{7})$ и правило преобразования +7${1-}${2-}.

  • использовать специальные правила чтения атрибутов из данного LDAP-каталога. Например, если в LDAP-каталоге атрибут с номером мобильного телефона задан в формате +79991234567, а в Blitz Identity Provider используется формат +7(999)1234567, то для чтения из каталога можно использовать правило разбиения ^\+7([0-9]{3})([0-9]{7})$ и правило преобразования +7(${1-})${2-}.

Настройка правил сопоставления атрибутов (фрагмент)

Если хранение созданного ранее атрибута в данном хранилище не предполагается, то можно просто удалить атрибут, используя кнопку удаления. В этом случае значение удаленного атрибута будет сохраняться при создании/редактировании учетной записи не в подключаемом внешнем хранилище, а в базе данных Blitz Identity Provider.

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

  • убедиться, что Blitz Identity Provider поддерживает выбранный тип хранилища и его возможность блокировки: в настоящее время Blitz Identity Provider корректно обрабатывает признак блокировки для каталогов 389DS и Microsoft Active Directory;

  • атрибуту, который был ранее определен как «Признак блокировки» , следует присвоить значение _blitz_account_locked в настойках каталога.

Настройка признака блокировки (фрагмент)

Если Blitz Identity используется для регистрации пользователей, причем запись осуществляется в данный каталог, то необходимо указать параметры создания новых пользователей – DN родительского контейнера, внутри которого будут создаваться пользователи, и системные атрибуты, связанные со спецификой хранилища. Например, objectclass, определяющий тип создаваемой учетной записи в LDAP. Для Microsoft Active Directory objectclass должен иметь формат Array of string и значение - top,person.

Настройка параметров создания новых пользователей

Подключение к хранилищу через REST-сервисы

Если в качестве источника идентификационных данных используется внешняя база данных (не LDAP-хранилище), то для подключения к ней требуется создание коннектора. Коннектор не входит в поставку Blitz Identity Provider. Коннектор обеспечивает чтение (или изменение) необходимых данных из базы данных и предоставляет данные в корректном формате в виде REST-сервисов для Blitz Identity Provider.

Для настройки взаимодействия с REST-сервисами необходимо выполнить следующие шаги:

  • добавить новое хранилище, указав тип добавляемого хранилища - REST;

  • при необходимости привести описание хранилища и указать, доступно ли оно только для чтения или нет;

  • указать максимальное количество записей, возвращаемых при поиске;

  • указать перечень доступных через REST-сервисы атрибутов, если атрибут, сконфигурированный в качестве хранимого, не будет указан в этом перечне,

  • указать URL следующих сервисов:

    • сервис поиска пользователей;

    • сервис получения данных пользователя;

    • сервис проверки логина и пароля;

    • сервис смены пароля пользователем;

    • сервис добавления нового пользователя;

    • сервис изменения данных пользователя;

    • сервис удаления пользователя.

Настройка подключения к хранилищу с использованием REST (фрагмент)

В следующих подразделах описаны требования к разработке REST-сервисов, предоставляющих необходимый Blitz Identity Provider доступ к хранилищу учетных записей.

После ввода URL-сервисов следует указать максимальное количество возвращаемых записей.

Сервис поиска пользователей

Сервис поиска пользователей должен обрабатывать запросы методом GET, где в качестве параметра rql указывается поисковый запрос. Запрос имеет формат Resource Query Language (RQL) и должен как минимум поддерживать следующие операции:

  • limit – количество возвращаемых записей (число возвращаемых записей берется из настроек соответствующего хранилища);

  • and – одновременное выполнение поисковых условий;

  • or – альтернативное выполнение поисковых условий (например, поиск по разным атрибутам в качестве логина);

  • eq – проверка условия равенства с возможностью поиска по маске (например, с использованием звездочки (*)).

Например, если в качестве логина в разделе «Аутентификация» настроен только поиск по атрибуту mail, то передаваемый при аутентификации rql-параметр будет иметь вид (где test@mail.ru – данные, введенные пользователем в качестве логина):

rql=and(eq(mail,test@mail.ru),limit(10))

Если в качестве логина настроен поиск по атрибуту mail ИЛИ uid, то передаваемый rql-параметр будет иметь вид:

rql=and(or(eq(uid,test@mail.ru),eq(mail,test@mail.ru)),limit(10))

Сервис должен возвращать список пользователей и их данные в формате json в кодировке UTF-8. По каждому пользователю должны быть возвращены атрибуты:

  • id – идентификатор пользователя в подключенной базе данных. Предполагается, что этот идентификатор будет неизменным для данного пользователя;

  • attrs – объект с перечнем возвращаемых данных пользователя. Необходимо возвращать те атрибуты, которые предполагается использовать в системе и которые сконфигурированы в разделе «Источники данных».

Пример запроса:

GET /users/search?rql=and(eq(uid,BIP*),limit(10)) HTTP/1.1
Host: idstore.identityblitz.com
Content-Type: application/json
Cache-Control: no-cache

Пример ответа:

[
  {
    "id": "ID123",
    "attrs": {
      "uid": "BIP123",
      "name": "Ivan",
      "surname": "Ivanov",
      "mail": "ivanov@test.org",
      "mobile": "+79991234567"
    }
  },
  {
    "id": "ID456",
    "attrs": {
      "uid": "BIP456",
      "name": "Elena",
      "surname": "Ivanova",
      "mail": "ivanova@test.org",
      "mobile": "+79997654321"
    }
  }
]

Сервис получения данных пользователя

В ряде случаев Blitz Identity Provider запрашивает данные конкретного пользователя. Сервис получения данных пользователя должен обрабатывать запросы методом GET, в котором в URL указывается атрибут id – внутренний идентификатор пользователя в подключенной базе данных. Иными словами, при задании URL этого сервиса в консоли управления необходимо использовать строку подстановки для идентификатора пользователя – ${id}, например:

http://idstore.identityblitz.com/users/${id}

Если пользователь найден, то сервис должен отвечать 200 OK и возвращать данные пользователя в формате JSON в кодировке UTF-8. Если пользователь не найден: 400 Bad Request, код ошибки USER_NOT_FOUND в формате text/plain; charset=utf-8. Пример запроса:

GET /users/ID123 HTTP/1.1
Host: idstore.identityblitz.com
Content-Type: application/json
Cache-Control: no-cache

Пример ответа, если пользователь найден:

HTTP/1.1 200 OK
Date: Mon, 18 Jul 2016 12:28:59 GMT
Content-Type: application/json; charset=utf-8

  {
    "id": "ID123",
    "attrs": {
      "uid": "BIP123",
      "name": "Ivan",
      "surname": "Ivanov",
      "mail": "ivanov@test.org",
      "mobile": "+79991234567"
    }
  }

Ответ для случая, если пользователь не найден:

HTTP/1.1 400 Bad Request
Date: Mon, 18 Jul 2016 12:28:59 GMT
Content-Type: text/plain; charset=utf-8

USER_NOT_FOUND

Сервис проверки логина и пароля

Сервис проверки логина и пароля должен обрабатывать запросы методом POST, в теле которых указаны следующие параметры (в формате application/x-www-form-urlencoded):

  • id – внутренний идентификатор пользователя в подключенной базе данных;

  • password – пароль.

В случае успеха сервис должен вернуть ответ 200 OK.

При невозможности провести аутентификацию сервис должен вернуть 400 Bad Request с одной из следующих ошибок:

  • INVALID_CREDENTIALS – неверный логин или пароль пользователя;

  • UNWILLING_TO_PERFORM – пользователь заблокирован;

  • INAPPROPRIATE_AUTHENTICATION — пользователь не может быть аутентифицирован по паролю;

  • PASSWORD_EXPIRED — пароль пользователя устарел.

Пример запроса:

POST /users/bind HTTP/1.1
Host: idstore.identityblitz.com
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache

id=ivanov&password=12345678

Пример ответа (успешная проверка логина и пароля):

HTTP/1.1 200 OK
Date: Mon, 18 Jul 2016 12:38:53 GMT
Content-Type: application/json; charset=utf-8

Пример ответа (неверный логин и/или пароль):

HTTP/1.1 400 Bad Request
Date: Mon, 18 Jul 2016 12:38:53 GMT
Content-Type: text/plain; charset=utf-8

INVALID_CREDENTIALS

Сервис смены пароля пользователем

Сервис смены пароля пользователем должен обрабатывать запросы методом POST, в теле которых указаны следующие параметры (в формате application/x-www-form-urlencoded):

  • id – идентификатор пользователя, полученный по результату операции проверки пароля пользователя;

  • old_password – старый пароль;

  • new_password – новый пароль.

В случае успеха сервис должен вернуть ответ 200 OK.

В случае ошибки сервис должен вернуть 400 Bad Request с одной из следующих ошибок:

  • INVALID_CREDENTIALS — пользователь с данным идентификатором и паролем не найден ;

  • UNWILLING_TO_PERFORM — пользователь заблокирован;

  • CONSTRAINT_VIOLATION — новый пароль не соответствует политикам безопасности.

Остальные возвращаемые ошибки должны быть аналогичны операции по проверке логина и пароля.

Пример запроса:

POST /users/changePassword HTTP/1.1
Host: idstore.identityblitz.com
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache

id=ivanov&old_password=12345678&new_password=0987654321

Пример ответа:

HTTP/1.1 400 Bad Request
Date: Mon, 18 Jul 2016 12:43:23 GMT
Content-Type: text/plain; charset=utf-8

CONSTRAINT_VIOLATION

Сервис добавления нового пользователя

Сервис добавления нового пользователя должен обрабатывать запросы методом PUT, в теле которых указаны следующие параметры (в формате application/json):

  • password – пароль пользователя (опционально);

  • attrs – атрибуты пользователя.

В случае успеха сервис должен вернуть данные пользователя в формате JSON в кодировке UTF-8.

Если пароль не удовлетворяет политикам безопасности, сервис должен вернуть 400 Bad Request с ошибкой CONSTRAINT_VIOLATION.

Если такой пользователь уже существует, сервис должен вернуть 400 Bad Request с ошибкой USER_ALREADY_EXISTS и уточнением, что пользователь с данным идентификатором уже существует.

Пример запроса:

PUT /users HTTP/1.1
Host: idstore.identityblitz.com
Content-Type: application/json
Cache-Control: no-cache

{
    "password":"********",
    "attrs": {
            "uid": "ivanov@test.org"
            "mail": "ivanov@test.org"
    }
}

Пример ответа (пользователь создан):

HTTP/1.1 200 OK
Date: Mon, 18 Jul 2016 12:28:53 GMT
Content-Type: application/json; charset=utf-8

{
    "id": "ID678",
    "attrs": {
        "uid": "ivanov@test.org",
        "mail": "ivanov@test.org"
    }
}

Пример ответа (учетная запись уже зарегистрирована):

HTTP/1.1 400 Bad Request
Date: Mon, 18 Jul 2016 12:43:23 GMT
Content-Type: text/plain; charset=utf-8

USER_ALREADY_EXISTS:ivanov@test.org

Сервис изменения данных пользователя

Сервис изменения данных пользователя должен обрабатывать запросы методом POST, в URL вызываемого сервиса указывается атрибут id – внутренний идентификатор пользователя в подключенной базе данных. Иными словами, при задании URL этого сервиса в консоли управления необходимо использовать строку подстановки для идентификатора пользователя – ${id}, например:

http://idstore.identityblitz.com/users/${id}

В теле запроса на изменение данных указаны следующие параметры (в формате application/json):

  • password – новое значение пароля пользователя (если пароль не передан, то он не должен измениться);

  • replaced – новые значения атрибутов пользователя, которые нужно заменить или добавить;

  • deleted – список названий удаляемых атрибутов.

В случае успеха сервис должен вернуть данные пользователя в формате JSON в кодировке UTF-8.

Если новый пароль не удовлетворяет политикам безопасности, сервис должен вернуть 400 Bad Request с ошибкой CONSTRAINT_VIOLATION.

Если такой пользователь не существует, сервис должен вернуть 400 Bad Request с ошибкой USER_NOT_FOUND.

Пример запроса:

POST /users/ID123 HTTP/1.1
Host: idstore.identityblitz.com
Content-Type: application/json
Cache-Control: no-cache

{
    "replaced": {
        "mail": "ivanov@domain.org"
    },
    "deleted": ["surname"],
    "password": "########"
}

Пример ответа:

HTTP/1.1 200 OK
Date: Mon, 18 Jul 2016 12:38:53 GMT
Content-Type: application/json; charset=utf-8

{
    "id": "ID123",
    "attrs": [
        "uid": "BIP123",
        "name": "Ivan",
        "email": "ivanov@domain.org"
    ]
}

Сервис удаления пользователя

Сервис удаления учетной записи пользователя должен обрабатывать запросы методом DELETE, в URL вызываемого сервиса указывается атрибут id – внутренний идентификатор пользователя в подключенной базе данных. Иными словами, при указании URL этого сервиса необходимо использовать строку подстановки для идентификатора пользователя – ${id}, например:

http://idstore.identityblitz.com/users/${id}

В случае успеха сервис должен вернуть статус 200 ОК.

Если пользователь не существует, сервис должен вернуть 400 Bad Request с ошибкой USER_NOT_FOUND.

Пример запроса:

DELETE /users/ID123 HTTP/1.1
Host: idstore.identityblitz.com
Content-Type: application/json
Cache-Control: no-cache

Пример ответа:

HTTP/1.1 200 OK
Date: Mon, 18 Jul 2016 12:28:53 GMT
Content-Type: application/json; charset=utf-8

Настройка внутреннего хранилища

Если в качестве источника идентификационных данных предполагается использовать базу данных Blitz Identity Provider, то необходимо выполнить следующие шаги:

  • добавить новое хранилище, указав тип добавляемого хранилища – BUILT-IN;

  • указать идентификатор хранилища;

  • дать описание хранилища;

  • определить, используется ли хранилище только для чтения или нет;

  • указать максимальное число возвращаемых учетных записей при поиске.

Настройка внутреннего хранилища