Что такое статус Provisioned в Okta API?

Я экспериментировал с событиями жизненного цикла пользователей в отношении API-интерфейсов Okta REST.

Меня смущают различные статусы пользователей Okta, в частности, СТАЦИОНАРНЫЙ, АКТИВНЫЙ и ПРЕДНАЗНАЧЕН. Я видел эту диаграмму:

Поток состояния пользователя Okta

но это не соответствует тому, что я переживаю.

Когда я запускаю «создать пользователя», как в в этом примере, и я передаю "activate = false", я получаю пользователя в состоянии STAGED. Если я передам «activate = true», я получу пользователя в статусе АКТИВНЫЙ.

После создания пользователя я запускаю эти вызовы REST:

Что-то, что я делаю, переводит моего пользователя в статус PROVISIONED, и я не могу понять, что это такое. Это создание "активного" пользователя, а затем обновление? Или создать «поэтапного» пользователя с последующим обновлением, или создать «активного» пользователя, а затем сбросить пароль и подождать некоторое время, прежде чем они войдут в систему? Как вы понимаете, здесь много перестановок.

Какая комбинация вызовов REST переводит вновь созданного пользователя Okta в статус PROVISIONED? Является ли статус PROVISIONED похожим на статус ACTIVE, когда пользователь готов к работе и может пройти аутентификацию? Или ПРЕДНАЗНАЧЕН, больше похож на ПОСТУПЕНЧАТЫЙ, где мне нужно «активировать» своего пользователя?


okta okta-api
person nettie    schedule 27.06.2017    source источник
comment
Сообщите мне, если мой ответ поможет. Я с радостью отредактирую его, если вам понадобится дополнительная информация. Ваше здоровье!   -  person Nate Barbettini    schedule 29.06.2017

Ответы (2)


arrow_upward
6
arrow_downward

Является ли статус PROVISIONED похожим на статус ACTIVE, когда пользователь готов к работе и может пройти аутентификацию? Или ПРЕДНАЗНАЧЕН, больше похож на ПОСТУПЕНЧАТЫЙ, где мне нужно «активировать» своего пользователя?

PROVISIONED почти как ACTIVE, за исключением того, что у пользователя еще нет учетных данных и он не может войти в систему.

Вот простой пример:

Создайте пользователя (но без пароля)

POST {{url}}/api/v1/users?activate=false
{
  "profile": {
    "firstName": "Test",
    "lastName": "Testerman",
    "email": "[email protected]",
    "login": "[email protected]"
  }
}

Активировать!

POST {{url}}/api/v1/users/00ub09deolJQUhKPm0h7/lifecycle/activate?sendEmail=false

Это приводит к пользователю с "status": "PROVISIONED".

Что может происходить в вашем случае, так это то, что операция сброса пароля делает вид, будто у пользователя нет пароля, поэтому, когда вы выполняете операцию активации, вы получаете ОБЕСПЕЧЕНИЕ.

person Nate Barbettini    schedule 29.06.2017
comment
Ваше объяснение предоставленного статуса полезно. Я до сих пор не могу понять, что заставляет моих пользователей использовать PROVISIONED. - person nettie; 29.06.2017
comment
@nettie Я подозреваю, что это запрос на сброс пароля. Если вы хотите публиковать точные вызовы API, которые вы делаете, я могу изучить это подробнее. - person Nate Barbettini; 30.06.2017

arrow_upward
0
arrow_downward

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

person Felix Friedman    schedule 10.06.2019
comment
Но я не думаю, что это так. В этом конкретном случае пользователь настроен на обеспечение, потому что пароль не был указан во время создания. это не имеет ничего общего с запросом на сброс пароля. - person Felix Friedman; 11.06.2019