Могу ли я избежать хранения учетных данных MS Exchange при возможности аутентификации (против EWS)?

Я создаю приложение, которое синхронизирует данные между учетными записями пользователей Exchange (поддерживается версия 2007-2013) и приложение.

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

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

Я не уверен, какие вопросы задавать, поэтому я собираюсь с ними:

Как аутентифицируется Exchange Server? Учетные данные пользователя отправляются непосредственно на сервер так, как они есть, или же хешируются вместе перед отправкой по проводу? Если они хэшируются, как я могу получить/генерировать этот хэш для повторного использования при последовательных аутентификации?

Отправляет ли Exchange Server какой-то токен аутентификации, который может быть повторно использован позже (и навсегда, до изменения пароля или аннулирования)?

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

Чтобы ответить на некоторые ваши вопросы (в том же порядке - с учетом сценария единого входа с ADFS 2.0):

  • Аутентификация для обмена сервером будет выполняться через ADFS 2.0 (который предоставляет токены безопасности (служба STS) - вашему приложению после аутентификации с помощью службы AD/main Directory). Все сообщения зашифрованы, а сертификаты подписывания токенов используются для обеспечения целостности и конфиденциальности.
  • Срок службы маркеров безопасности, отправленных ADFS 2.0, может быть настроен и повторно использован по мере необходимости. Подробнее см. этот пост в блоге.

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

Ответ 3

System.Net.CredentialCache должен работать в соответствии с вашими потребностями. WebCredentials является оберткой для System.Net.NetworkCredential. В зависимости от типа подключения/домена ect вы должны использовать System.Net.CredentialCache.DefaultNetworkCredentials или System.Net.CredentialCache.DefaultCredentials

Ответ 4

возможно, вы должны взглянуть на это Ссылки Подключение к EWS с помощью управляемого API EWS, Подключиться к Exchange - Начало работы с учебным пособием?, надеюсь, это даст вам новую идею, как решить вашу проблему:)

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

Ответ 5

Нижняя линия

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

Мысли о хранении пароля:

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

Например:

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

Если вы хотите предоставить пользователю возможность, у вас может быть PIN-код авторизации, который также будет добавлен к данным.

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

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

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