Неинтерактивный вход (кэшированные учетные данные) с помощью API Azure Graph на iOS

Я создаю приложение для iOS, которое будет работать в режиме «киоска». Часть приложения требует, чтобы пользователи могли выполнять поиск в каталоге организации. Я хотел бы поддерживать Azure AD через API Azure Graph, чтобы обеспечить эту функцию.

Я не хочу требовать интерактивного входа в систему при запуске приложения и не хочу использовать дополнительную веб-службу; Я хочу, чтобы приложение iOS просто получало доступ к API Azure Graph через REST.

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

Я просмотрел множество примеров Azure и прочитал документацию, и мне кажется, что метод, который предоставляет то, что мне нужно _ 1_ недоступен в библиотеке iOS ADAL (и либо является классом ClientCredential).

Чтобы уточнить, как я хочу, чтобы мое приложение работало:

  1. Пользователь устанавливает приложение из магазина приложений и запускает его в первый раз.
  2. В рамках настройки они проходят проверку подлинности в Azure AD, предоставляя своего клиента, идентификатор клиента приложения и ключ приложения. Если они не могут пройти аутентификацию с помощью ключа приложения, идентификатор пользователя / пароль приемлем, если:
  3. Им больше никогда не предлагается пройти аутентификацию

Есть ли здесь решение, или я просто откажусь от Azure AD?


ios azure-active-directory azure-ad-graph-api adal
person Paulw11    schedule 22.08.2016    source источник
comment
В iOS нет концепции сервисных аккаунтов. Перенос артефактов и определений Windows в iOS кажется экстраполирующим.   -  person Kanishk Panwar    schedule 22.08.2016
comment
Кроме того, в чем проблема с доступом к графику из вашего приложения при интерактивном входе в систему? Все, что вам нужно сделать, это получить токен для графика в качестве ресурса и использовать свой общедоступный идентификатор клиента.   -  person Kanishk Panwar    schedule 22.08.2016
comment
Я просто использовал это, чтобы объяснить концепцию. Учетная запись службы будет использоваться приложением iOS. Он будет существовать в Azure AD (или, предпочтительно, это будет определение приложения Azure AD, которое имеет идентификатор клиента и ключ, а не имя пользователя и пароль).   -  person Paulw11    schedule 22.08.2016
comment
@ KanishkPanwar-MSFT Не могли бы вы указать на пример кода, который показывает, как это сделать? Если может быть какой-то процесс входа в систему, который клиент использует при первой установке приложения, тогда это может быть нормально, но я не хочу, чтобы приглашение входа отображалось при каждом запуске приложения; Я просто хочу надежно хранить токен в связке ключей iOS.   -  person Paulw11    schedule 22.08.2016
comment
Вы используете библиотеку xamarin или obj-c adal?   -  person Kanishk Panwar    schedule 22.08.2016
comment
Библиотека Objective-C   -  person Paulw11    schedule 22.08.2016
comment
По умолчанию библиотека обеспечивает хранение токенов цепочки ключей. Я отправлю пример псевдокода, когда вернусь домой.   -  person Kanishk Panwar    schedule 22.08.2016
comment
Я собрал приложение для быстрого тестирования - github.com/paulw11/GraphAPITest - я могу войти в систему, и когда я вхожу в систему впоследствии, он не сообщает мне, что токен хранится в цепочке для ключей, но истечет ли срок действия этого токена?   -  person Paulw11    schedule 22.08.2016
comment
Через 1 час. Но в этом случае токен обновления будет использоваться для получения нового токена.   -  person Kanishk Panwar    schedule 22.08.2016
comment
Но сколько раз можно обновить токен, прежде чем пользователю потребуется снова пройти аутентификацию? Что делать, если приложение не запускается и токен не обновляется в течение некоторого времени?   -  person Paulw11    schedule 22.08.2016
comment
Срок действия токена обновления истечет, если он не будет использоваться в течение 14 дней. Он действителен до 90 дней.   -  person Kanishk Panwar    schedule 22.08.2016
comment
Это моя проблема. Я хочу, чтобы в этом случае приложение могло повторно аутентифицироваться без взаимодействия с пользователем, но это не представляется возможным.   -  person Paulw11    schedule 22.08.2016
comment
Используя ваш подход, если ваш секрет клиента украден с помощью атаки MITM, вам придется обновить свой секрет, сломать всех пользователей вашего приложения и развернуть новое приложение. Если вы используете рекомендуемый подход, то скомпрометированному пользователю просто нужно будет обновить свой пароль.   -  person Kanishk Panwar    schedule 22.08.2016
comment
Срок действия паролей пользователей также может истечь. Также некоторые арендаторы могут использовать MFA, и для этого потребуется веб-интерфейс.   -  person Kanishk Panwar    schedule 22.08.2016
comment
Я понимаю это, поэтому я упомянул стиль учетной записи службы; это обычно используется, и учетная запись не имеет срока действия пароля или MFA. Как такового пользователя приложения нет. Это киоск, стоящий у стойки регистрации. Просто нужно работать. Риск доступа невысок, поскольку он просто считывает базовую информацию о пользователе из каталога. Веб-приложение Azure AD уже поддерживает это за счет использования ключа клиента, а не учетных данных пользователя. Похоже, ответ - не использовать Azure AD, что раздражает. Этот стиль аутентификации поддерживается собственными приложениями Windows.   -  person Paulw11    schedule 22.08.2016
comment
Я не уверен, поможет ли использование чего-то еще, что реализует oauth. Я бы порекомендовал вам пересмотреть сценарий вашего приложения. Скажем, например, вы тренажерный зал, где люди регистрируются в киоске. Приложение должно иметь возможность извлекать информацию о пользователе из графика и создавать запись посещаемости в вашей БД. Для этого владелец / менеджер спортзала может войти в киоск и попросить людей использовать его ... Просто подбрасывать идеи. :)   -  person Kanishk Panwar    schedule 22.08.2016
comment
Я играю с NXOAuth2, у которого, по крайней мере, есть метод, который принимает имя пользователя и пароль, но он, похоже, тоже не работает, но для изучения вашего сценария тренажерного зала; Скажите, что менеджер входит в систему; 90 дней спустя киоск перестает работать, и пользователи не могут войти в систему, поэтому менеджер должен войти в систему снова, или менеджер уходит, и учетная запись становится недействительной; опять киоски перестают работать, и кто-то должен это чинить. Или используется общая учетная запись, и все менеджеры должны знать ее, чтобы они могли повторно войти в систему. Все это хуже, чем защищенные учетные данные, хранящиеся в приложении.   -  person Paulw11    schedule 23.08.2016
comment
Я решил это. Завтра добавлю ответ   -  person Paulw11    schedule 23.08.2016

Ответы (1)


arrow_upward
1
arrow_downward

Это можно сделать, но не с помощью инфраструктуры ADALiOS, поскольку она не предоставляет client_credentials грант, необходимый для его работы.

Мне удалось создать рабочую демонстрацию, используя p2 / OAuth. Образец приложения находится здесь

Шаги по созданию рабочего решения:

  1. Войдите в устаревший портал управления Azure и выберите свой экземпляр Azure AD.
  2. Create a new application in that AD instance
    1. Select "Add an application my organisation is developing"
    2. Дайте ему имя и выберите «Веб-приложение и / или веб-API» не «Собственное клиентское приложение».
    3. Введите значения для URL-адреса входа и URL-адреса идентификатора приложения. Это должны быть правильно сформированные URL-адреса, но они не должны быть доступными.
  3. После создания приложения выберите «Настроить». Обратите внимание на идентификатор клиента - он вам понадобится
  4. В разделе «Ключи» выберите в раскрывающемся списке 1 или 2 года, затем нажмите «Сохранить».
  5. Как только ключ отобразится, скопируйте его и сохраните где-нибудь; он не может быть отображен снова.
  6. Установите необходимые «Разрешения для других приложений», чтобы предоставить вашему приложению необходимый доступ.
  7. Наконец, в нижней части экрана нажмите «просмотреть конечные точки» - вам необходимо скопировать конечную точку токена OAuth 2.0 и конечную точку авторизации OAuth 2.0.
  8. Загрузите демонстрационный код с GitHub
  9. Запустить pod install
  10. Вставьте значения в файл Settings.plist
  11. Запустите приложение

Суть процесса аутентификации - создать экземпляр OAuth2ClientCredentials -

let settings = [
        "client_id": appData.clientId!,
        "client_secret": appData.secret!,
        "authorize_uri": appData.authString!,
        "token_uri": appData.tokenString!,
        "keychain": true,
        "secret_in_body": true
        ] as OAuth2JSON

self.oauth2 = OAuth2ClientCredentials(settings: settings)

Затем вы можете позвонить doAuthorize(), чтобы получить токен

self.oauth2.doAuthorize()
person Paulw11    schedule 24.08.2016