Защита и управление идентификациями средствами Azure Mobile Services

Сатья Наделла (Satya Nadella) четко сформулировал новые планы Microsoft. Он заявил, что мы живем в мире, который является «Mobile-First/Cloud-First». Это неудивительно. Microsoft занимается мобильными и облачными технологиями уже несколько лет. Индустрия меняется, и давление на лидеров в области IT, заставляющее их принять революционную концепцию использования собственных устройств сотрудников (bring-your-own-device, BYOD), становится как никогда сильным.

Поддержка совершенно нового мира BYOD на предприятии является высшим приоритетом. В этой статье мы разъясним, как облако может помочь разработчикам специализированных бизнес-приложений (line-of-business, LOB) создавать и поддерживать приложения Apple iOS, Google Android и Windows Phone. Мы будем рассматривать и решать задачи управления устройствами, с которыми сталкиваются компании любых масштабов. Мы также покажем некоторый низкоуровневый код на Objective-C, который понадобится вам для корректного управления маркерами OAuth 2.0 из Azure Mobile Services. Главная возможность — безопасное сохранение маркера на мобильном устройстве, чтобы пользователям не приходилось входить в систему всякий раз, когда им потребуется работать с каким-либо приложением.

Ключевые характеристики LOB-приложений

При создании LOB-приложений нужно учитывать много проблем. Одна из наиболее важных — управление идентификациями (рис. 1). Мы говорим об идентификации не только пользователя, но и устройства. Эти два фактора в сочетании часто называют составной идентификацией (compound identity). Это имеет смысл, так как LOB-приложения обычно имеют доступ к конфиденциальным корпоративным ресурсам.

Управление устройствами

При централизации IT очевидно одно: необходимо вводить какой-то тип контроля над персональными устройствами. В идеальном мире IT можно заставить пользователей выполнять полную процедуру присоединения их устройств к домену. Менее экстремальная версия контроля называется присоединением к рабочей области (Workplace Join), которое можно рассматривать как облегченную версию полного присоединения устройства к домену.

Цель любого IT-администратора должна заключаться в обеспечении защищенного, зашифрованного взаимодействия между корпоративными ресурсами и самим устройством. Установка сертификата устройства как этап процесса подготовки (provisioning process) — один из способов для корпорации надежно и безопасно управлять устройством.

Подготовка рабочей области

TПервая задача этого процесса — аутентификация пользователя в доверяемой службе каталогов. Успешная подготовка устройства (или регистрация) завершается получением маркера на основе JSON, сохраняемым на устройстве. Этот маркер помогает обеспечить защищенную коммуникацию между пользователями и корпоративной сетью (рис. 2).

Многоуровневая идентификация

Забота о наборе уровней защиты вполне целесообразна (рис. 3). Хотя бы потому, что какая-то часть корпоративной информации является более конфиденциальной. Для защиты таких данных часто требуются дополнительные меры.

Большинство уже знакомо с аутентификацией пользователей. На этом самом базовом уровне защиты пользователь входит в систему по своему имени и паролю. Второй уровень — аутентификация устройства с возможным применением многофакторной аутентификации (multi-factor authentication). Комбинируя идентификации пользователя и устройства (например, с применением SMS), можно сформировать составную идентификацию.

Служба сведений о подключенных сетях

Другая важная задача при выполнении приложений на персональных устройствах — применение службы сведений о подключенных сетях (Network Location Awareness, NLA). Когда принятый запрос обращается к защищенному сетевому ресурсу, вы можете определить, исходит ли этот запрос извне корпоративной сети. NLA предоставляет дополнительный уровень защиты, так как помогает вводить дополнительные правила, такие как многофакторная аутентификация для запросов, генерируемых извне корпоративной сети.

Реализация транспарентности местонахождения сети, как правило, означает, что вы создаете какую-то разновидность веб-сервиса прокси в демилитаризованной зоне (DMZ). DMZ — это сеть, которая предоставляет сервисы организации, обращенные вовне для более крупной и недоверяемой сети, например для Интернета. Вы можете использовать эти прокси для введения в действие дополнительных правил и изоляции закрытых ресурсов в какой-либо сети от внешнего доступа. Microsoft располагает специфическими технологиями, которые поддерживают такие сценарии. Узнать больше о них можно по ссылке bit.ly/1v50JPq.

Поддержка идентификации с помощью «родного» для iOS кода

Мы проиллюстрируем некоторые низкоуровневые способы использования «родных» для iOS возможностей. Однако, прежде чем углубляться в этот предмет, мы дадим некоторую необходимую информацию об Azure Mobile Services. Azure Mobile Services предоставляет клиентским программам несколько часто используемых возможностей. Клиентские программы могут быть рассчитаны на iOS, Android, Windows Phone, HTML/JavaScript, выполняемый в браузере, или Windows.

Любая клиентская платформа, способная вызывать REST API, может использовать Azure Mobile Services. Этот сервис предоставляет варьируемые уровни библиотечной поддержки между этими клиентами. К другим возможностям относятся федеративная идентификация, доступ к хранилищу, автономная синхронизация данных и уведомления, поступающие с серверной стороны. Некоторые возможности реализованы в серверной части, а другие — в клиентской. А в качестве серверной части используется либо Microsoft .NET Framework, либо Node.js.

Одна из наиболее трудных в реализации возможностей — сохранение маркера защиты на устройстве с iOS. Маркер изначально принимается от Azure Mobile Services. ОС должна защищать этот маркер, и его нужно зашифровать. К счастью, механизм связки ключей (keychain mechanism), встроенный в iOS SDK, предоставляет такую возможность. Он позволяет надежно хранить маркер на устройстве сотрудника. Это «родной» для iOS подход, подразумевающий, что код нельзя будет использовать повторно.

Хранение маркера защиты локально на устройстве дает преимущества. Самое важное из них в том, что тогда пользователи могут обращаться к приложению, не выполняя каждый раз вход в систему. Приложения Azure Mobile Services способны использовать какой-то один или все провайдеры маркеров защиты, а также любые провайдеры идентификации, такие как Active Directory, Azure Active Directory, Facebook, Twitter и т. д. Каждый из них обеспечивает базовую аутентификацию, но уникален в других отношениях.

Одно из отличий — поддержка истечения срока действия маркеров. Active Directory и Azure Active Directory поддерживают это, а Twitter — нет. Эта поддержка важна для аутентификации, после которой выдаются права на доступ к корпоративным ресурсам, поэтому для такого уровня доступа в конечном счете лучше выбирать Active Directory и Azure Active Directory, чем Twitter.

В духе принципа «начинай с простого» мы опишем в этой статье процесс аутентификации через Twitter, а в будущей статье расскажем о таковом процессе на основе Azure Active Directory. Xcode — это IDE, используемая для разработки iOS-приложений. В чем-то она аналогична Visual Studio, но менее навороченная и менее функциональная. Традиционным языком кодирования iOS-приложений является Objective-C.

Чтобы понять эти методики, начните с учебного пособия по ссылке bit.ly/1vcxHMQ. Добавьте федеративную аутентификацию, используя сервиса провайдера идентификаций Twitter. Учебное пособие включает модули для серверной и клиентской частей. Вы можете выбрать любую серверную часть (.NET или JavaScript). Для клиентской части выберите вариант с Objective-C. Мы позаимствуем некоторый код из другого проекта-примера (iOS-LensRocket) на сайте GitHub для поддержки функционала KeyChain.

Особых изменений в проект Xcode клиентской части, предоставляемой Azure Mobile Services, вносить не требуется. Достаточно добавить код KeyChain и средства защиты из библиотеки security.framework. Когда пользователь запускает приложение, применяется базовая логика управления маркером. Приложение начинает с проверки маркера, вызывая KeyChain API. Если маркер имеется, он извлекается и используется. После этого пользователю больше не предлагается входить в Twitter.

Вот какие изменения мы внесем в код в Xcode IDE:

• выполним связывание с дополнительной библиотекой (подробнее о ней см. bit.ly/1x7Ajzz)
• добавим несколько файлов из iOS-LensRocket для поддержки функционала KeyChain;
• модифицируем код контроллера.

Рис. 4 демонстрирует, как мы будем использовать Azure Mobile Services и «родной» для iOS код, чтобы управлять доступом к базе данных SQL, используя маркер, кешированный на устройстве.

Учебное пособие доведет вас до того момента, когда вы сможете запустить «родное» для iOS приложение, которое может читать и записывать в базу данных SQL, размещенную в облаке. Вы получите работающий проект Xcode, написанный на Objective-C. Однако в нем недостает аутентификации — о ней мы поговорим позже. Существующая реализация использует ключ приложения, предоставляемый Azure Mobile Services:

// Инициализируем клиент Mobile Services ключом и URL
MSClient *client = [MSClient clientWithApplicationURLString:@
  "https://msdnmagazine.azure-mobile.net/"
  applicationKey:@"cctyYudYfxuczeRDMPcDBRCxDrOUIM73"];

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

В большинстве корпоративных сценариев не используют провайдеры идентификации на основе социальных сетей, такие как Facebook или Twitter. Тем не менее, это полезная отправная точка, позволяющая продемонстрировать нам некоторые базовые концепции для последующего использования идентификаций на предприятии с помощью Active Directory. Кроме того, многие бизнес-приложения работают с реляционными базами данных, и Azure Mobile Services предлагает встроенную функциональность для их поддержки.

Чтобы начать работу, нужно выполнить базовые задачи на портале Azure Management Portal и стороннем провайдере идентификаций (в данном случае — в Twitter). Создайте метаданные приложения на портале Twitter и связанные метаданные приложения на портале Azure Mobile Services. Затем получите URL приложения. Скопируйте этот URL в Twitter, а ключи Twitter API — в Azure Mobile Services. Вот так связываются провайдер идентификаций с приложением Azure Mobile Services (рис. 5).

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

1. Получаем URL для мобильного приложения, созданного на Azure Management Portal.
2. Регистрируемся и переходит на dev.twitter.com/apps/new
3. Создаем новое приложение Twitter.
4. Получаем API Key и API Secret для приложения Twitter.
5. Возвращаемся на Azure Management Portal.
6. Вставляем API Key и API Secret из Twitter.

Работа на портале

Как уже упоминалось, существует несколько подходов к созданию своей серверной части. Если вы выберете .NET Framework, вы получите больший контроль в Web API над авторизацией всех пользователей независимо от того, аутентифицированы они или нет. Если вы выберете Node.js, портал позволит использовать сразу два подхода: декларативный и на основе скриптов.

Что нам реально нужно, так это вернуться в Xcode IDE, выполняемую на Mac. Мы будем использовать ее для редактирования и компиляции исходного кода LOB-приложения под iOS, которое будет выполняться на мобильном устройстве.

В Xcode IDE мы внесем в код следующие изменения:

• добавим ссылку на библиотеку security.framework;
• скопируем из iOS-LensRocket по ссылке bit.ly/1pqvQ25 следующие четыре файла:
  • KeyChainWrapper.h;
  • KeyChainWrapper.m;
  • LensRocketConstants.h;
  • LensRocketConstants.m.

Здесь будет задействовано три ключевых функции/метода. Первая — viewDidLoad, куда мы добавляем вызов loadAuthInfo. Она загружает в память маркер, сохраненный ранее после успешного входа. Здесь мы должны загружать маркер с диска, а не заставлять пользователя снова входить в систему (рис. 6).

#import "KeychainWrapper.h"  // Добавляем эту строку

- (void)viewDidLoad
{
  // Код опущен для краткости
  [self loadAuthInfo];  // Добавьте эту строку
}

// Код опущен для краткости

///////////////////////////////////////////////////////////
//   Ниже добавляем viewDidAppear(), loadAuthInfo()
///////////////////////////////////////////////////////////

// --------------------------------------------------------
// Событие viewDidAppear. Когда приложение становится
// активным, проверяем удостоверения.
//
- (void)viewDidAppear:(BOOL)animated
{
  /////////////////////////////////////////////////////////
  // Проверяем, вошел ли текущий пользователь.
  // Если нет, отправляем для входа в Twitter.

  MSClient *client = self.todoService.client;
  if(client.currentUser != nil)   {
    return;
  }
  [client loginWithProvider:@"twitter"
    controller:self animated:YES
    completion:^(MSUser *user, NSError *error) {
    [self saveAuthInfo];
    [self refresh];
  }];

}
// --------------------------------------------------------
// Сохраняем маркер локально. Используем встроенные
// в iOS средства - Keychain – для сохранения
// ID пользователя и маркера
//
- (void) saveAuthInfo{
  // Сохраняем userId
  [KeychainWrapper createKeychainValue:self.todoService.
    client.currentUser.userId
    forIdentifier:@"userid"];
  // Сохраняем сам маркер
  [KeychainWrapper
    createKeychainValue:self.todoService.client.currentUser.
      mobileServiceAuthenticationToken
  forIdentifier:@"token"];
}

// --------------------------------------------------------
// Загружаем userID и token из Keychain. Не заставляйте
// пользователя снова входить в систему.
//
- (void)loadAuthInfo {
  NSString *userid = [KeychainWrapper
    keychainStringFromMatchingIdentifier:@"userid"];
  if (userid) {
    // Извлекаем userID и token из Keychain
    NSLog(@"userid: %@", userid);
    self.todoService.client.currentUser =
      [[MSUser alloc] initWithUserId:userid];
    self.todoService.client.currentUser.
      mobileServiceAuthenticationToken = [KeychainWrapper
      keychainStringFromMatchingIdentifier:@"token"];
  }
}

Мы также добавили функцию viewDidAppear, которая вызывается, когда приложение становится видимым или активным. Мы используем объект MSClient, чтобы проверить, вошел ли пользователь. Если нет, мы вводим в действие логин через Twitter, а затем сохраняем удостоверения (маркер) на лиск, используя возможности Keychain. Это будет правильнее реализовать в viewDidLoad.

Методы saveAuthInfo и loadAuthInfo просто используют код Keychain для сохранения маркера на диске и его загрузки с диска на мобильном устройстве. Подробнее о сервисах Keychain см. по ссылке bit.ly/1qqcNFm.

Вы можете последовать второму учебному пособию при реализации аутентификации (bit.ly/1B3Av0k). Чтобы разрешить федерацию в Azure Active Directory, следуйте аналогичному процессу.

1. Получаем URL для мобильного приложения, созданного на портале Azure Management Portal.
2. Переходим на страницы Active Directory (тоже в Azure Management Portal).
3. Создаем новое приложение.
4. Получаем Client ID и ключ.
5. Возвращаемся на страницу мобильного приложения в Azure Management Portal.
6. Вставляем Client ID и ключ из Active Directory.

О создании федерации в Active Directory на предприятии и в Azure Active Directory в облаке мы подробнее расскажем в следующей статье. Тем временем, вы можете посмотреть отличные примеры кода на bit.ly/1slQMz2 и bit.ly/1mK1LQF.

Заключение

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

Чтобы в полной мере задействовать все средства защиты на устройстве, вам придется часто обращаться к «родным» возможностям устройств, как в случае с сервисами Keychain в iOS. В следующих статьях мы продолжим исследовать трудные задачи поддержки мобильных устройств на предприятиях, стоящие перед руководителями IT-отделов, и сосредоточимся на идентификации, синхронизации данных и уведомлениях, посылаемых с серверной стороны (извещающих уведомлениях) (push notifications).