Фаза 1: аутентификация

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

При регистрации устройства сервер может потребовать аутентификации пользователем, устройством или обоими.

Аутентификация пользователя может быть осуществлена в то время, когда пользователь переходит к зарегистрировать URL. Для аутентификации пользователя можно использовать любую веб-схему аутентификации, ли часть HTTP (например, основной автор или NTML) или отдельную схему аутентификации, реализованную сценарием CGI. Можно даже использовать гибридную схему, такую как объединение дайджест-аутентификации с управляемым CGI списком авторизованных пользователей.

Можно также проверить устройство по списку авторизованных устройств при желании.

Шаги в этап аутентификации:

1. Пользователь посещает корневой URL (/) и получает желанное сообщение. Это сообщение предоставлено обработчиком, описанным в Странице приветствия (/) Обработчик URL.

2. Пользователь посещает центр сертификации URL (/CA) получить корневое свидетельство (в случае необходимости). На сервере этот URL обрабатывается кодом, описанным в Корневом Сертификате (/CA) Обработчик URL.) Это только требуется для самоподписанного корневого CA certs.

3. Пользователь посещает регистрацию URL (/enroll) запустить процесс регистрации. На этом шаге пользователю предлагают аутентифицировать себя или ее с помощью HTTP основной автор (в этом примере) или с помощью существующих служб каталогов.

4. Обработчик регистрации сервера (описанный в Регистрации (/регистрируются) Обработчик URL) определяет, разрешают ли пользователю зарегистрировать устройство. Если устройству позволяют зарегистрироваться, сервер отправляет ему полезную нагрузку службы профиля (Перечисление 2-5).

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

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

   Атрибуты устройств, которые может запросить служба, являются версией iOS, устройство Wi-Fi ID (MAC-адрес), тип продукта (например, возвраты iPhone 3GS iPhone2,1), телефонное оборудование ID (IMEI) и идентификатор SIM-карты (ICCID).

   Для демонстрационной полезной нагрузки службы профиля см. “Демонстрационный Ответ Сервера Фазы 1” в Руководстве по развертыванию Предприятия.

Фаза 2: регистрация сертификата (идентификационные данные X.509 и SCEP)

Во второй фазе, регистрации, устройство связывается с центром сертификации и получает удостоверение личности X.509 со знаком, тогда использующееся для шифрования.

Для получения идентификационных данных устройство сначала генерирует асимметричную пару ключей и хранит его в ее цепочке для ключей. Секреты в этой цепочке для ключей могут быть только для чтения тем определенным устройством.

Устройство тогда отправляет свой открытый ключ в центр сертификации (CA), передающий сертификат X.509 со знаком обратно. Этот сертификат, вместе с закрытым ключом на устройстве, формирует идентификационные данные.

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

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

Шаги в фазе регистрации:

1. Пользователь принимает установку профиля, полученного в фазе 1.

2. Устройство ищет требуемые атрибуты, добавляет ответ проблемы (если предоставленный), подписывает ответ с помощью встроенных идентификационных данных устройства (выпущенный Apple сертификат) и передает его обратно службе распределения профиля с помощью HTTP POST.

   В случае этого примера устройство отправляет этот ответ на /profile URL.

   Для демонстрационного профиля от этой фазы см. “Демонстрационный Ответ Устройства Фазы 2” в Руководстве по развертыванию Предприятия.

3. Обработчик запроса профиля сервера (описанный в Запросе Профиля (/профиль) Обработчик URL) передает обратно профиль конфигурации, дающий устройству команду регистрировать использование SCEP, как описано в фазе 2: Регистрация Сертификата (Идентификационные данные X.509 и SCEP). Сервер должен подписать этот профиль.

   Для демонстрационного профиля конфигурации см. “Демонстрационный Ответ Сервера Фазы 3 Со Спецификациями SCEP” в Руководстве по развертыванию Предприятия.

4. Устройство регистрирует использование SCEP, приводящий к допустимому удостоверению личности, установленному на устройстве.

Фаза 3: конфигурация устройства и зашифрованные профили

Третья фаза сверхвоздушной поставки профиля и конфигурации является самой фактической поставкой профиля. В этой фазе сервер отправляет профиль, настроенный для определенного устройства.

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

Зашифрованный профиль точно так же, как нормальный профиль конфигурации за исключением того, что полезная нагрузка профиля конфигурации шифруется с открытым ключом, связанным с идентификационными данными устройства X.509.

Чтобы препятствовать противникам изменять содержание, зашифрованный профиль конфигурации подписывается службой. Для шифрования и подписания, iOS использует Cryptographic Message Syntax (CMS), стандарт, также использующийся в S/MIME. Полезные нагрузки шифруются с помощью окутанных данных PKCS#7. Профили подписываются с помощью подписанных данных PKCS#7.

Шаги в фазе конфигурации устройства:

1. Устройство отправляет запрос со знаком для /profile обработчик снова для запроса заключительного профиля. (Запрос подписывается с удостоверением личности, полученным на предыдущем шаге.)

   Для демонстрационного профиля для этой фазы см. “Демонстрационный Ответ Устройства Фазы 4” в Руководстве по развертыванию Предприятия.

2. Обработчик запроса профиля сервера (описанный в Запросе Профиля (/профиль) Обработчик URL) отправляет, финал зашифровал профиль к устройству.

После регистрации

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

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

Обновления профиля конфигурации не продвинуты пользователям автоматически. Если необходимо сделать другие обновления профиля, не ожидая профилей для истечения, необходимо распределить их вручную или потребовать, чтобы повторно зарегистрировались пользователи. (Устройства также вытягивают новые профили на отказ аутентификации VPN.)

Можно распределить обновленные профили пользователям в почтовом присоединении или веб-странице. Для обновления профиля следующим условиям нужно ответить:

• Идентификатор профиля должен соответствовать.

  Для получения дополнительной информации об идентификаторе, см. “Общие Настройки” в Руководстве по развертыванию Предприятия.

• Если бы профиль был подписан, то заменяющий профиль должен также быть подписан тем же эмитентом.

В зависимости от Общей полезной нагрузки Настроек Вы указали при создании профиля, для пользователя может быть возможно удалить профили.

• Если профиль требует пароля для удаления, пользователю предлагают тот пароль после ответвления, Удаляют.

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

Для получения дополнительной информации о настройках безопасности профиля, см. “Общие Настройки” в Руководстве по развертыванию Предприятия.