Опубликован: 15.05.2013 | Уровень: для всех | Доступ: платный
Лекция 8:

Проверка подлинности, учетные данные и профиль пользователя

< Лекция 7 || Лекция 8: 1234 || Лекция 9 >
Аннотация: Рассматриваются методики работы с учетными данными пользователя, особенности различных подходов к проверке подлинности, раскрываются методики работы с сокетами.

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

Есть два основных подхода по работе с учетными данными. Первая, вы можете собирать учетные данные напрямую, с помощью интерфейса Средства выбора учетных данных, или с помощью собственного пользовательского интерфейса. В любом случае, однако, следующий вопрос заключается в том, как организовать безопасное хранение учетных данных, для чего у нас имеется API хранилища учетных данных (Credential Locker API). Хранилище позволяет приложения получать учетные данные в последующих сеансах работы, таким образом, ему не нужно каждый раз просить пользователя вводить эти учетные данные (что довольно утомительно, уверен, вы это знаете).

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

По этой причине – хорошая идея делегировать эти действия другим. например, интерфейс средства выбора файлов будет, по умолчанию, шифровать пароли прежде чем передаст их вашему приложению. Или вы можете использовать второй подход для работы с учетными данными, когда приложение проверяет подлинность пользователя с помощью другого поставщика услуг, такого, как Microsoft Live Connect, Facebook, Flickr, Yahoo, и так далее. При этом поставщик выполняет всю работу по проверке подлинности и приложению лишь нужно сохранить соответствующие маркеры или другие ключи доступа для данного сервиса. Основное преимущества интегрированной проверки подлинности подобного вида заключается в том, что приложение никогда не работает с учетными данными самостоятельно, и, таким образом, ему не нужно беспокоиться об их безопасности. (Однако, приложению следует шифровать маркеры или ключе доступа, если оно их хранит. Хранилище учетных данных можно использовать и для этой цели.)

В большинстве случаев этот процесс включает в себя агента, который называется Брокер веб-проверки подлинности (Web Authentication Broker), который, в частности, работает с протоколами OAuth/OpenID и поставщиками услуг, обычно расположенными в Веб. Microsoft Live Connect – это особый случай, так как учетная запись Microsoft, используемая с ним может, кроме того, использоваться для входа в Windows. (Проверка подлинности через Live Connect так же предоставляет приложению доступ к другим данным из сервисов Live, в том числе, к Calendar, Messenger, и SkyDrive.)

Одно из других замечательных преимуществ этого второго подхода заключается в возможности работы в режиме единого входа (single sign on, SSO). Это означает, что когда пользователь авторизовался у какого-либо OAuth-поставщика в одном приложении, ему часто не нужно осуществлять вход в другие приложения, которые исопльзуют того же поставщика (если приложение сочтет это нужным). В случае с Live Connect, приложения может никогда не понадобиться запрашивать учетные данные, если та же самая учетная запись Microsoft использована для входа в Windows или связана с входом пользователя в домен.

В этом разделе мы так же кратко рассмотрим – и это все, что нужно в данном случае – информацию профиля пользователя, доступную с помощью API WinRT, вместе с API для шифрования и дешифровки. Помимо этого, я расскажу о двух других материалах по теме. Первый, это "Защита соединений и проверка подлинности запросов" (http://msdn.microsoft.com/library/windows/apps/hh986970.aspx ). Второй – это пример "Банковское приложение Магазина Windows со строгой проверкой подлинности" ( http://code.msdn.microsoft.com/windowsapps/Metro-style-banking-app-7d963c00), которое демонстрирует пример безопасной проверки подлинности и обмена данными через Интернет. Полное описание этого примера можно найти вматериале "Банковское приложение Магазина Windows: обзор кода" (http://msdn.microsoft.com/library/windows/apps/Hh464943 ), поэтому здесь мы не будем его рассматривать.

Совет по дизайну. Существует множество руководств по дизайну для различных сценариев входа в систему, касающиеся ситуаций, когда приложению требуется вход в систему для работы, или когда вход необязателен. Эти темы, а так же рекомендации о том, где разместить интерфейс для входа в систему и управления учетной записью или профилем, обсуждаются в материале "Руководство и контрольный список для элементов управления входом" (http://msdn.microsoft.com/library/windows/apps/hh965453.aspx ).

Пользовательский интерфейс средства работы с учетными данными

Так же, как WinRT предоставляет встроенный интерфейс для выбора файлов, имеется и встроенный пользовательский интерфейс для ввода учетных данных: Windows.Security.Credentials.UI.CredentialsPicker ( http://msdn.microsoft.com/library/windows/apps/windows.security.credentials.ui.credentialpicker.aspx).

Эта возможность предоставлена для удобства, вы можете реализовать собственный интерфейс, который лучше подходит для вашего приложения, но множество функциональных возможностей делают средство выбора учетных данных весьма привлекательным. Когда вы создаете экземпляр этого объекта и вызываете его метод pickAsync, как в примере "Средство выбора учетных данных" (http://code.msdn.microsoft.com/windowsapps/Credential-picker-sample-30fcba2e ), вы видите интерфейс, показанный на рис. 8.1. Этот интерфейс предоставляет возможности входа в домен, поддержку, смарт-карты (как видите, к моему компьютера подключены два устройства для чтения смарт-карт), и поддерживает различные параметры, такие, как протоколы проверки подлинности и автоматическое сохранение учетных данных (смотрите следующий раздел).

Интерфейс средства выбора учетных данных выводится, как и диалоговое окно сообщения, поверх приложения

Рис. 8.1. Интерфейс средства выбора учетных данных выводится, как и диалоговое окно сообщения, поверх приложения

Результаты из pickAsync, переданные обработчику завершения, это объект CredentialPickerResults (http://msdn.microsoft.com/library/windows/apps/windows.security.credentials.ui.credentialpickerresults.aspx ), который имеет следующие свойства. Когда вы введете какие-нибудь учетные данные в примере, вы увидите их значения, отраженные в выходных данных примера:

  • credentialuserName Строка, которая содержит введенное имя пользователя.
  • credentialPassword Строка, которая содержит пароль (обычно зашифрованный, в зависимости от параметров протокола проверки подлиности).
  • credentialDomainName Строка, содержащая имя домена, если он введен вместе с именем прользователя, (в таком виде: <domain> \<username>).
  • credentialSaved Логическое значение, которое показывает, будет ли производиться автоматическое сохранение введенных учетных данных. Это зависит от параметра средства выбора учетных данных, как обсуждается ниже.
  • credentialSavedOption Значение типа CredentialSavedOption (http://msdn.microsoft.com/library/windows/apps/windows.security.credentials.ui.credentialsaveoption.aspx ), отображает состояние флага Сохранить учетные данные (Remember My Credentals): unselected, selected, или hidden. Скоро мы рассмотрим обработку этого значения.
  • errorCode Содержит ноль, если ошибок нет, в противном случае – код ошибки.
  • credential Значение типа IBuffer, содержащее учетные данные в виде непрозрачного массива байтов. Его вы можете сохранить, если нужно, в составе состояния приложения и позднее передать обратно средству выбора учетных данных. Как это сделать, мы скоро увидим.

Три сценария в примере показывают различные параметры, которые вы можете использовать для вызова средства выбора учетных данных. Для этих целей присутствует три различных варианта pickAsync. Первый вариант принимает целевое имя (игнорируется) и строку сообщения, которая появляется вместо "Please enter your credentials" на рис. 8.1.:

Windows.Security.Credentials.UI.CredentialPicker.pickAsync(targetName, message)
.done(function (results) {
}
      

Второй вариант принимает те же аргументы вместе со строкой заголовка, которая появляется вместо текста "Credential Picker Sample" на рис. 8.1.

Windows.Security.Credentials.UI.CredentialPicker.pickAsync(targetName, message, caption)
.done(function (results) {
}
      

Третий вариант принимает объект CredentialPickerOptions (http://msdn.microsoft.com/library/windows/apps/windows.security.credentials.ui.credentialpickeroptions.aspx ), который имеет те же свойства:строки targetName, message, и caption , вместе со следующими:

  • previousCredential Значение типа IBuffer с непрозрачной информацией об учетных данных, которые были предоставлены при предыдущем запуске средства (смотрите CredentialPickerResults.credential выше).
  • alwaysDisplayDialog Логическое значение, указывающее на то, отображается ли диалоговое окно. Значение по умолчанию – false, но это применимо лишь в том случае, если вы заполнили свойство previousCredential (с исключением для компьютеров, подключенных к домену – смотрите таблицу ниже). Цель его использования заключается в том, чтобы показать диалоговое окно, когда сохраненные учетные данные могут быть неверными, и от пользователя ожидается предоставление новых данных.
  • errorCode Числовое значение кода ошибки Win32 (http://msdn.microsoft.com/library/windows/desktop/ms681381%28v=vs.85%29.aspx ) (по умолчанию ERROR_SUCCESS) которое можно отформатировать и показать в диалоговом окне. Это значение используют, когда учетные данные сначала получены от средства их выбора, но оказалось, что эти учетные данные подходят и нужно снова запустить диалоговое окно для их ввода. Вместо того, чтобы предоставлять собственное сообщение, вы можете просто получить код ошибки и позволить системе сделать все остальное. Наиболее часто встречающиеся здесь ошибки имеют следующие коды: 1326 (ошибка входа), 1330 (истек пароль), 2202 (неправильное имя пользователя), 1907 или 1938 (нужно изменить пароль/требуется смена пароля), 1351 (невозможно получить доступ к информации о домене), и 1355 (нет такого домена). На самом деле, существует более 15000 кодов ошибок Win32, но это позволит вам найти справочную информацию по тем, которые упомянуты здесь (или произвести поиск в файле winerror.h , который обычно можно найти в папке Program Files (x86)\Windows Kits\8.0\Include\shared). Удачной охоты!
  • callerSavesCredential Логическое значение, указывающее на то, что приложение сохранит учетные данные, а средство выбора учетных данных – нет. Значение по умолчанию - false. Когда свойство установлено в true, учетные данные сохраняются в защищенное системное расположение (не в хранилище учетных данных), если у приложения объявлена возможность Корпоративная аутентификация (Enterprise Authentication) (смотрите ниже).
  • credentialSaveOption Значение из перечисления CredentialSaveOption (http://msdn.microsoft.com/library/windows/apps/windows.security.credentials.ui.credentialsaveoption.aspx ), показывающее изначальное состояние флага Сохранить учетные данные (Remember My Credentals): unselected, selected, или hidden.
  • authenticationProtocol Значение из перечисления AuthenticationProtocol(http://msdn.microsoft.com/library/windows/apps/windows.security.credentials.ui.authenticationprotocol.aspx): basic, digest, ntlm, kerberos, negotiate (по умолчанию), credSsp, и custom (в подобном случае вы должны предоставить строку в свойстве customAuthenticationProcotol). Обратите внимание на то, что в случае использования видов протокола аутентификации basic и digest, данные в CredentialPickerResults.credentialPassword не будут зашифрованы, к ним применимы те же соображения по обеспечению безопасности, что и пароль в виде обычного текста, который вы можете получить из собственного интерфейса.

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

var options = new Windows.Security.Credentials.UI.CredentialPickerOptions();
options.message = "Please enter your credentials";
options.caption = "Sample App"; options.targetName = "Target"; options.alwaysDisplayDialog = true;
options.errorCode = 1326; // Выводит "The username or password is incorrect." options.callerSavesCredential = true;
options.authenticationProtocol = Windows.Security.Credentials.UI.AuthenticationProtocol.negotiate;
options.credentialSaveOption = Windows.Security.Credentials.UI.CredentialSaveOption.selected;

Windows.Security.Credentials.UI.CredentialPicker.pickAsync(options)
.done(function (results) {
}
      

Для того, чтобы прояснить взаимосвязь между свойствами callerSavesCredential, credentialSaveOption, и credentialSaved, следующая таблица перечисляет особенности их сочетаний:

Возможность "Корпоративная аутентификация" Значение callerSavesCredential Значение credentialSaveOption Средство выбора сохраняет учетные данные Приложение сохраняет данные в хранилище учетных данных
Нет true Selected Нет Да
unselected или hidden Нет Нет
false Selected Нет Да
unselected или hidden Нет Нет
Да true Selected Нет Да
unselected или hidden Нет Нет
false Selected Да (credentialSaved будет иметь значение true) Не обязательно
unselected или hidden Нет Нет

Первый столбец относится к возможности Корпоративная аутентификация (Enterprise Authentication) в манифесте приложения, что указывает на то, что приложение может работать с ресурсами корпоративной сети, которые требуют доменные учетные данные (подразумевается, что приложение исполняется на Windows 8 Enterprise Edition). В подобных случаях у средства выбора учетных данных есть другое безопасное хранилище (не относящееся к хранилищу учетных данных) в котором можно хранить учетные данные, таким образом приложению не нужно сохранять их самостоятельно. Более того, если средство выбора учетных данных сохраняет учетные данные и приложение вызывает его с параметром alwaysDisplayDialog установленным в false, параметр previousCredential может быть пустым, так как учетные данные будут загружены автоматически. Но без компьютера, подключеного к домену и вышеозначенной возможности, объявленной в манифесте, приложение должно поддерживать previousCredential для того, чтобы средство выбора файлов не появилось.

< Лекция 7 || Лекция 8: 1234 || Лекция 9 >
Алена Дьякова
Алена Дьякова
Россия, Тамбов, ТГТУ, 2009
жанна парак
жанна парак
Казахстан, Павлодарский облость