Планирование инфраструктуры, необходимой для новой модели приложений в SharePoint 2013

  • Article

Дата публикации исходной статьи: вторник, 4 сентября 2012 г.

В SharePoint 2013 представлена новая модель приложений, которую мы кратко называем "моделью приложений" или "облачной моделью приложений". Она предоставляет ряд новых возможностей с точки зрения разработки, но при этом и накладывает определенные требования, которые необходимо учитывать и выполнять для поддержки этих новых возможностей. Когда я думаю о модели приложений, я рассматривают три основных компонента:

  1. Модель разработки связана с процессом разработки приложения, новыми функциями, которые я буду использовать и т. д. Этим, в основном, занимаются разработчики.
  2. Модель безопасности — для новых приложений это интересная комбинация различных элементов. Вам доступа новая концепция app-principal, которая определяет права для приложений. Здесь есть модель OAuth, которая определяет, какой контент вы можете получить, а также механизм для предоставления SharePoint маркера, описывающего вас (это очень похоже на утверждения для приложений). Модель безопасности и средства создания и предоставления этих маркеров зависит от того, размещается ли ваше приложение в SharePoint или в другом месте, используете ли вы службы управления доступом (ACS) в качестве посредника доверия или нет. Эта модель состоит из многих компонентов, не все из которых я опишу в этой записи блога, и она используется разработчиками и ИТ-специалистами.
  3. Инфраструктура — здесь мы говорим о всех "кирпичиках", которые заставляют приложения работать в организации. Она включает в себя конфигурацию приложений, домена и префикса приложений, DNS, SSL и веб-приложений. Она, в основном, используется ИТ-специалистами и является основой для этой записи блога. Эта запись также будет сфокусирована на приложениях, размещенных в SharePoint, а не на приложениях, размещенных на внешнем сайте или в облаке, например в Windows Azure. После установке приложения, размещенного в SharePoint, для него создается SPWeb. Таким образом каждое приложение получает собственный набор данных и не можете перезаписать данные для другого приложения. Это также обеспечивает уровень безопасности, чтобы все с правами для одного приложения не могли применить зловредный код, использующий права текущего пользователя, для доступа к данным на другом сайте в ферме. Эта важный базовый принцип приложений в новой модели приложений, который нужно запомнить — если они размещаются в SharePoint, одно приложение = один SPWeb.

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

Итак, как создаются эти URL-адреса? Что ж, все начинается с настройки приложений в центре администрирования. Если перейти в центр администрирования, вы найдете новый раздел "Приложения (Apps)". Если щелкнуть его, вы увидите параметр "Настроить URL-адреса приложений (Configure App Urls)". Там вы увидите два значения, которые используются для создания URL-адреса приложения: "Домен приложения (App Domain)" и "Префикс приложения (App Prefix)". Домен приложения аналогичен имени узла, который будет использоваться для всех приложений в ферме. Далее представлены три вопроса, которые необходимо учитывать при планировании:

  1. Так как это имя используется для всей фермы, его необходимо спланировать и продумать на таком же уровне, что и для других веб-приложений.
  2. Помимо того, что это должно быть полное доменное имя, применение имени NetBIOS не будет работать для разрешения имен.
  3. Наконец, оно НЕ должно быть дочерним доменом ваших веб-приложений.

Итак, давайте рассмотрим конкретный пример. Предположим, ваши веб-приложения используют имена team.contoso.com, my.contoso.com и portal.contoso.com. Во-первых, вы, наверное, не захотите использовать "contoso.com" в качестве домена приложений, так как для этого придется создать DNS-запись с подстановочными знаками для ВСЕГО домена contoso.com, который указывает на конечную точку ваших приложений (подробнее об этом см. дальше). Кроме того, не следует использовать имя наподобие "apps.contoso.com", так как это дочерний домен для домена, используемого для веб-приложений (корневой домен которых расположен в "contoso.com"). Поэтому лучше выбрать имя "contosoapps.com" в соответствии с этими правилами.

Значение "Префикс приложения (App Prefix" может быть любым, оно добавляется в первую часть URL-адреса приложений, о чем мы поговорим далее.

Я упоминал об использовании DNS-записи с подстановочными знаками выше, об этом мы поговорим сейчас. Если приложение устанавливается и размещается в SharePoint, оно получит URL-адрес наподобие следующего: https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx. URL-адрес состоит из следующих элементов:

  • “apps” — это значение префикса приложения, о котором я говорил ранее, введенное в центре администрирования.
  • “87e90ada14c175” — это уникальное значение, основанное на семействе сайтов и и месте установки приложения
  • “contosoapps.com” — это значение домена приложения, введенное в центре администрирования.
  • “myapp” — это имя установленного приложения. Остальная часть URL-адреса (pages/default.aspx) — это то, что содержится в SPWeb в месте установки приложения.

Если рассмотреть URL-адрес и то, как он формируется, можно понять, почему следует использовать DNS-запись с подстановочными знаками. Так как первая часть URL-адреса будет отличаться для каждого устанавливаемого экземпляра приложения (даже если одно приложение устанавливается в нескольких семействах сайтов), будет невозможно постоянно обновлять DNS для каждого экземпляра. С учетом этого для описанного сценария следует использовать DNS-запись с подстановочными знаками для *.contosoapps.com. IP-адрес, на который указывает эта DNS-запись, мы опишем далее.

С DNS-записью с подстановочными знаками связана SSL-запись с подстановочными знаками. Чтобы все было предельно ясно — если вы используете приложения, вы должны применять SSL. Модель приложений применяет процесс передачи маркеров доступа OAuth, которые описывает, кем являются текущий пользователь и приложение. Как и в случае с передачей маркеров SAML для пользователя, вы хотите шифровать канал, по которому эти маркеры передаются, чтобы предотвратить атаки типа "воспроизведения", которые предоставляют доступ к контенту тем, кто может осуществлять прослушивание сетевого трафика. Протокол SSL предотвращает реализацию таких сценариев, а так как вы видели, что URL-адреса приложений будут отличаться для каждого установленного экземпляра, для обеспечения управляемости вам потребуется групповой сертификат SSL. Опять же, в нашем сценарии мы получаем групповой сертификат SSL для *.contosoapps.com.

Итак, мы поговорили о необходимых приложениях-службах, конфигурации, требуемой для домена и префикса приложения, о формировании URL-адресов и необходимых записях DNS и SSL. Чтобы связать все воедино, мы должны поговорить о том, как маршрутизируются запросы приложений. В целом, вам требуется отдельное веб-приложение SharePoint только для маршрутизации запросов приложений. Рассмотрим, почему это так. Предположим, что у вас три веб-приложения, которые определены следующим образом и используют SSL, поэтому мы применяем уникальные IP-адреса для каждого из них:

  • team.contoso.com — 192.168.1.10
  • my.contoso.com — 192.168.1.11
  • portal.contoso.com — 192.168.1.12

Как описано выше, в ферме может быть только один домен приложений, который не должен быть дочерним доменом. Это вызывает две очень серьезные проблемы для представленных выше приложений:

  • Если установить приложения в каждом из этих веб-приложений, как сделать так, чтобы запросы приложений направлялись в соответствующее веб-приложение? У нас всего один домен приложений, но три веб-приложения.
  • Если попытаться направлять запросы приложений в одно из существующих веб-приложений, то в SSL возникнет ошибка. Почему? Так как мы используем SSL во всех наших веб-приложениях (поскольку мы применяем приложения), у всех них есть сертификат SSL наподобие *.contoso.com. Итак, мы не можем направлять запросы приложений веб-приложениям, так как вы не можете получить групповой сертификат SSL, который работает и для домена *.contoso.com, и для *.contosoapps.com, которые будут использовать наши приложения.

Для решения этой проблемы необходимо создать четвертое веб-приложение. Вы можете сделать это без имени заголовка узла и назначить ему общий IP-адрес 192.168.1.13. DNS-запись для *.contosoapps.com будет указывать на 192.168.1.13. В итоге веб-приложение ваших приложений будет "прослушивать" этот IP-адрес, а HTTP-модуль SharePoint, отвечающий за маршрутизацию, будет подбирать запросы приложения. Затем используется приложение-служба управления приложениями для определения того, в каком веб-приложении размещается данное приложение, после запрос будет направлять в это веб-приложение. После этого запрос обслуживается в веб-приложении, семействе сайтов и SPWeb, в котором расположено само приложение, поэтому все параметры безопасности и проверки подлинности будут правильно применены.

Теперь конфигурация нашей фермы выглядит следующим образом:

  •  Конфигурация приложений
    • Домен приложения — contosoapps.com
    • Префикс приложения — apps
  • Веб-приложения

    • team.contoso.com

      • IP-адрес: 192.168.1.10
      • Сертификат SSL: *.contoso.com

    • my.contoso.com

      • IP-адрес: 192.168.1.11
      • Сертификат SSL: *.contoso.com

    • portal.contoso.com

      • IP-адрес: 192.168.1.12
      • Сертификат SSL: *.contoso.com

    • Заголовка узла нет или же можно использовать что-то наподобие contosoapps и т. д. — это, на самом деле, не важно, так как маршрутизация основывается не на заголовке узла, а на IP-адресе. ОДНАКО, если заголовки узла используются и все веб-приложения применяют один IP-адрес, у этого прослушивающего веб-приложения вообще не должно быть значения заголовка узла! В противном случае службы IIS не будут принимать запросы приложений для всех веб-приложений.

      • IP-адрес: 192.168.1.13
      • Сертификат SSL: *.contosoapps.com
  • DNS
    • team.contoso.com — 192.168.1.10
    • my.contoso.com — 192.168.1.11
    • portal.contoso.com — 192.168.1.12
    • *.contosoapps.com — 192.168.1.13

После обсуждения всех аспектов настройки инфраструктуры для приложений необходимо рассмотреть и запомнить пару других вопросов, учитываемых при планировании развертывания новых приложений для SharePoint 2013:

  • Приложения SharePoint не работают с веб-приложениями, использующими SAML. Если вы применяете проверку подлинности SAML, вы не сможете использовать приложения SharePoint в этих веб-приложениях. Надеемся, что эта проблема будет устранена в будущем пакете обновлений или другом исправления, но в RTM-версии SharePoint 2013 данное ограничение присутствует.
  • Приложения SharePoint не поддерживают множество зон (т. е. AAM); все запросы обслуживаются из зоны по умолчанию. Если вы применяете AAM для поддержки нескольких зон, вы, скорее всего, не сможете использовать приложения SharePoint. Все запросы обслуживаются из зоны по умолчанию, поэтому если в теории зона по умолчанию будет доступна всем и вы будете использовать один механизм проверки подлинности в каждой зоне (с определенными ограничениями, которые слишком сложны, чтобы касаться их здесь и сейчас), то это может сработать. Но опять же, если вы используете зоны, то это вызвано тем, что а) вы не хотите, чтобы каждая конечная точка была доступна всем, или б) вы ХОТИТЕ использовать разные методы проверки подлинности. Опять же, это может измениться в будущем, но в в RTM-версии SharePoint 2013 используется именно такое поведение.

 

Еще одно важное и заключительное примечание: похоже на то, что вам необходимо выполнить много операций настройки, и это так. Но следует помнить, что если вы используете Office 365, все это делается автоматически — никакой суеты, вы просто устанавливаете и используете приложения. При взвешивании доступных вариантов это необходимо учитывать.

Итак, приложения SharePoint являются большой частью SharePoint 2013, но для их применения необходимо определенное планирование и проектирование, чтобы настроить инфраструктуру для их поддержки.

 

Это локализованная запись блога. Исходная статья находится по адресу Planning the Infrastructure Required for the new App Model in SharePoint 2013