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

Режим единого входа в службу Live Connect

Так как различные службы Microsoft, такие, как Hotmail, являются поставщиками OAuth, возможно использовать брокер веб-проверки подлинности с учетной записью Microsoft (с такой, как учетные записи Hotmail, Live, и MSN). (У меня все еще есть учетная запись электронной почты @msn.com, которую я получил в 1996!). Подробности можно найти на странице "OAuth 2.0" ( http://msdn.microsoft.com/library/live/hh243647.aspx) в Центре разработчиков Live Connect.

Тем не менее, учетные записи Live Connect находятся в более привилегированном положении, так как их можно использовать для входа в Windows, или подключить к доменной учетной записи для той же цели. Многие из встроенных приложений, такие, как Mail (Почта), Calendar (Календарь), SkyDrive, People (Люди) и Магазин Windows, работают с той же учетной записью. Таким образом, это то, чем, возможно, захотят воспользоваться многие другие приложения, так как подобная аутентификация дает доступ к тем же данным служб Live, с которыми работают встроенные приложения. API Live Services выглядит как WL.login, он доступен при Live SDK и добавляет в проект соответствующие ссылки. Для того, чтобы начать работу, посетите страницу документации по Live Connect (http://msdn.microsoft.com/ru-ru/library/live/ff621314.aspx ) и почитайте следующие материалы:

• Live Connect, домашняя страница (http://msdn.microsoft.com/library/windows/apps/hh770845.aspx )
• Центр разработчиков Live Connect (http://msdn.microsoft.com/library/live/hh826551.aspx )
• Руководство по единому входу и подключенным учетным записям ( http://msdn.microsoft.com/library/windows/apps/jj193591.aspx)
• Руководство по взаимодействию с пользователем при входе в учетную запись Майкрософт (http://msdn.microsoft.com/library/windows/apps/hh968443.aspx )
• Единый вход с учетной записью Майкрософт (http://msdn.microsoft.com/library/windows/apps/hh465097.aspx )
• Краткое руководство: персонализация приложения (http://msdn.microsoft.com/library/windows/apps/hh920269.aspx )
• Пример "Авторизация с учетной записью Microsoft" (http://code.msdn.microsoft.com/windowsapps/Windows-account-authorizati-7c95e284 )
• Материалы блога для разработчиков приложения для Windows 8 "Внедрение функций единого входа и SkyDrive в приложения для Windows 8 с помощью Live SDK" (http://blogs.msdn.com/b/windowsappdev_ru/archive/2012/03/22/skydrive-windows-8-live-sdk.aspx ) и "Рекомендации по добавлению функции единого входа в приложения с помощью Live SDK" ( http://blogs.msdn.com/b/windowsappdev_ru/archive/2012/07/02/live-sdk.aspx).

Вы можете видеть, что работа со службами Live – весьма обширная тема, поэтому я оставляю ее вышеприведенным ресурсам. Хочу упомянуть один из ключевых моментов. Пользователь может войти в Windows с использованием доменной учетной записи, которая не подключена к учетной записи Microsoft в разделе Параметры ПК > Пользователи (PC Settings > Users). В подобном случае первый вызов WL.login, исходящий от любого приложения, отобразит диалоговое окно для входа в учетную запись Microsoft, как показано на рис. 8.4. Как только пользователь введет здесь учетные данные, осуществится вход и во все остальные приложения, которые используют учетную запись Microsoft.

Рис. 8.4. Диалоговое окно входа в учетную запись Microsoft

Профиль пользователя (и изображение экрана блокировки)

Любой разговор об учетных данные пользователя вызывает вопрос о доступе к дополнительной информации пользователя. То, что доступно приложениям для Магазина Windows, предоставляется с помощью API Windows.System.UserProfile (http://msdn.microsoft.com/library/windows/apps/windows.system.userprofile.aspx ), где мы можем найти классы, относящиеся к предмету нашего интереса.

Первый – это класс LockScreen(http://msdn.microsoft.com/library/windows/apps/windows.system.userprofile.lockscreen.aspx), с помощью которого можно получить или установить изображение экрана блокировки (и ничего больше). Изображение доступно через свойство originalImageFile (оно возвращает StorageFile) и метод getImageStream (возвращает IRandomAccessStream). Задать изображение можно с помощью setImageFileAsync (используя StorageFile) и setImageStreamAsync (используя IRandomAccessStream). Это можно использовать в приложении для редактирования фото, у которого есть команда для использования изображения для экрана блокировки. Посмотрите пример "Персонализация экрана блокировки" (http://code.msdn.microsoft.com/windowsapps/Personalization-App-sample-9ebfe147 ) для того, чтобы увидеть демонстрацию этого.

>Второй – это объект GlobalizationPreferences ( http://msdn.microsoft.com/library/windows/apps/windows.system.userprofile.globalizationpreferences.aspx), к которому мы вернемся к Главе 6.

Третий – это класс UserInformation (http://msdn.microsoft.com/library/windows/apps/windows.system.userprofile.userinformation.aspx ), возможности которого отражены на странице Параметры ПК > Персонализация > Аватар (PC Settings > Personalize > Account picture):

• Имя пользователя (User name) Если свойство nameAccessAllowed установлено в true, приложение может вызывать методы getDisplayNameAsync, getFirstNameAsync, и getLastNameAsync, каждый из которых предоставляет строку в обработчик завершения. Если nameAccessAllowed установлено в false, эти методы выполняются, до завершения, но возвращают пустой результат. Кроме того, обратите внимание на то, что получение имени (first name) и фамилии (last name) доступно лишь из учетной записи Microsoft
• Изображение пользователя (User picture) Его можно получить, воспользовавшись методом getAccountPicture, который возвращает StorageFile для изображения. Метод получает значение из AccountPictureKind (http://msdn.microsoft.com/library/windows/apps/windows.system.userprofile.accountpicturekind.aspx ): smallImage, largeImage, и video.
• Если свойство accountPictureChangeEnabled установлено в true, вы можете воспользоваться одним из четырех методов для того, чтобы задать изображение(я): setAccountPictureAsync (для задания одного изображения из StorageFile), setAccountPicturesAsync (для того, чтобы задать маленькое и большое изображения, а так же видео из объектов StorageFile), и методамиsetAccountPictureFromStreamAsync и setAccountPicturesFromStreamAsync (они выполняют те же функции, но с использованием объектов IRandomAccessStream). В каждом случае результат асинхронной операции – это значение SetAccountPictureResult (http://msdn.microsoft.com/library/windows/apps/windows.system.userprofile.setaccountpictureresult.aspx ): success, failure, changeDisabled (accountPictureChangeEnabled установлено в false), largeOrDynamicError (изображение слишком велико), fileSizeError (файл слишком велик), или videoFrameSizeError (размер кадра видео слишком велик),
• Событие accountpicturechanged вызывается, когда изображение (или изображения) пользователя изменяется. Помните о том, что так как это – событие, исходящие из WinRT, вам следует вызвать removeEventListener, если вы не намерены прослушивать это событие во время работы приложения.

Демонстрацию этих возможностей можно найти в примере "Имя пользователя и изображение учетной записи" (http://code.msdn.microsoft.com/windowsapps/Account-picture-name-sample-912baff1 ). Сценарий 1 получает отображаемое имя, Сценарий 2 получает имя и фамилию пользователя (если они доступны), Сценарий 3 получает изображение учетной записи и видео, Сценарий 4 позволяет изменить изображения и видео, и прослушивать событие изменения изображений.

Совет. Для того, чтобы получить изображение профиля из Live Connect, можно воспользоваться следующим вызовом API: https://apis.live.net/v5.0/me/picture?access_token=<ACCESS_TOKEN> Кроме того, этот пример показывает объявление Поставщик изображений для учетных записей(Account Picture Provider), благодаря чему приложение отображается в окне Параметры ПК > Персонализация, в разделе Приложения для создания аватара (Create an Account Picture):

В данном случае приложение-пример не предоставляет изображение напрямую, но активируется со Сценарием 4. Реальное приложение, такое, как Camera (Камера), которая есть в Параметрах ПК по умолчанию, автоматически задаст изображение учетной записи, когда оно будет получено с помощью его интерфейса. Откуда приложение знает, как это сделать? Ответ находится в специальной схеме URI, посредством которой активируется приложение. Таким образом, если вы сделали объявление Поставщик изображений для учетных записей(Account Picture Provider) в манифесте, приложение будет активировано с видом активации protocol (смотрите Главу 1), где схема URI начинается с ms-accountpictureprovider. Вы можете увидеть, как обрабатывается такая активация в файле js/default.js:

if (eventObject.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.protocol) {
// Проверяет, совпадает ли protocol со схемой "ms-accountpictureprovider"
if (eventObject.detail.uri.schemeName === "ms-accountpictureprovider") {
// Приложение было активировано с помощью команды задания аватара в разделе Персонализация в Параметрах ПК.
// Здесь можно выполнить действия по предоставлению пользователю интерфейса для
// выбора изображения учетной записи.
}
      

Возвращаясь к классу UserInformation, можно сказать, что так же он предоставляет немного больше подробностей для доменных учетных записей, предполагая, что у приложения, в манифесте, объявлена возможность Корпоративная аутентификация (Enterprise Authentication):

• getDomainNameAsync предоставляет полностью определенное доменное имя пользователя в виде строки, в форме

  <domain>
    \<user>
     где <domain>

  Это полное имя контроллера домена, как, например, mydomain.corp.ourcompany.com.
• getPrincipalNameAsync Предоставляет имя субъекта в виде строки. В применении к Active Directory, это имя для входа, в интернет-стиле (известное как имя субъекта-пользователя (user principal name), или UPN), которое короче и проще, чем доменное имя, объединяя имя для входа в систему и адрес электронного почтового ящика. Обычно – это адрес электонной почты наподобие user@ourcompany.com.
• getSessionInitiationProtocolUriAsync Предоставляет URI протокола инициализации сеанса, который связан с данным пользователем. Для того чтобы узнать подробности, обратитесь к материалу из Википедии "Протокол инициализации сеанса" (http://en.wikipedia.org/wiki/Session_Initiation_Protocol ).

Использование этих методов показано в примере "Доменное имя пользователя" (http://code.msdn.microsoft.com/windowsapps/User-domain-name-sample-85ce3e49 ).

Шифрование, расшифровка, защита данных и сертификаты

Авторизация и учетные записи – это темы, связанные с безопасностью, поэтому хорошо будет завершить этот раздел кратким разбором других API, которые находятся в пространстве имен Windows.Security, одно из которых, брокер веб-проверки пользователей, мы уже рассматривали.

Первое - это Windows.Security.Cryptography (http://msdn.microsoft.com/library/windows/apps/windows.security.cryptography.aspx ). Здесь вы можете найти класс CryptographicBuffer, который позволяет кодировкить и декодировать строки в шестнадцатеричном формате и в формате base64 (UTF-8 или UTF-16), предоставляет набор случайных числе и байтовый массив, полный таких чисел. Обратитесь к Сценарию 1 примера "Криптография в WinRT" (http://code.msdn.microsoft.com/windowsapps/CryptoWinRT-54ff3d9f ) чтобы увидеть демонстрацию его применения, а так же, к Сценариям 2 и 3 примера "Брокер веб-проверки подлинности". Кодировка base64 WinRT полностью совместима с функциями JavaScript atob и btoa.

Далее, это Windows.Security.Cryptography.Core (http://msdn.microsoft.com/library/windows/apps/windows.security.cryptography.core.aspx ), который применим к шифрованию и расшифровке с использованием различных алгоритмов. Смотрите материал "Шифрование" ( http://msdn.microsoft.com/library/windows/apps/hh464976.aspx), Сценарии 2 – 8 примера "Криптография в WinRT", и, снова Сценарии 2 и 3 примера "Брокер веб-проверки подлинности"

Третье – Windows.Security.Cryptography.DataProtection (http://msdn.microsoft.com/library/windows/apps/windows.security.cryptography.dataprotection.aspx ), единственный класс которого, DataProtectionProvider, работает с шифровкой и расшифровкой статических данных и потоков данных. Это применимо только к приложениям, которые объявили возможность Корпоративная аутентификация (Enterprise Authentication). Для того, чтобы узнать подробности, обратитесь к материалу "API защиты данных" ( http://msdn.microsoft.com/library/windows/apps/hh464970.aspx) и к сценариям 9 и 10 примера "Криптография в WinRT".

Четвертое - Windows.Security.Cryptography.Certificates (http://msdn.microsoft.com/library/windows/apps/windows.security.cryptography.certificates.aspx ) предоставляет несколько классов, с помощью которых можно создавать запросы сертификатов и устанавливать отклики сертификатов. Обратитесь к материалу "Работа с сертификатами" (http://msdn.microsoft.com/library/windows/apps/hh465044.aspx ) и к примеру "Работа с сертификатом" (http://code.msdn.microsoft.com/windowsapps/Certificate-Enrollment-SDK-7ecf4976 ) для того, чтобы узнать подробности.

И, наконец, полезно по меньшей мере упомянуть API из Windows.Security.ExchangeActiveSyncProvisioning (http://msdn.microsoft.com/library/windows/apps/windows.security.exchangeactivesyncprovisioning.aspx ), имеется пример "EAS-политики для почтового клиента" (http://code.msdn.microsoft.com/windowsapps/Web-authentication-for-b9b8ed1a ). Думаю, вы знаете, зачем вам это может понадобиться.