Построение гибридных приложений в облаке на платформе Windows Azure patterns & practices



Pdf просмотр
страница19/33
Дата28.11.2016
Размер8.44 Mb.
Просмотров6384
Скачиваний0
1   ...   15   16   17   18   19   20   21   22   ...   33
Мнение По
Недостаточно тщательно проработанные или неудачно реализованные функции аутентификации могут стать узким местом с точки зрения производительности приложения.
Пользователи не хотят тратить много времени на аутентификацию, она не должна создавать препятствия для использования приложений.
Аутентификация публичных пользователей
Общедоступные приложения, такие как интернет-магазины и форумы, как правило, должны аутентифицировать большое количество пользователей, о которых в приложении изначально нет никаких сведений. Пользователи проходят регистрацию на сайте, предоставляя требуемую информацию, например имя и адрес, но ключевой задачей является обеспечение возможности однозначной идентификации каждого пользователя, чтобы можно было предоставить ему правильную информацию при следующем посещении.
Приложения могут сохранить учетные данные пользователя, чтобы в дальнейшем сверять их с той информацией, которую он вводит. Однако, в случае с общедоступными приложениями, целесообразно предоставить пользователю возможность войти в систему при помощи учетных данных, которые он использует для других веб-сайтов и приложений, чтобы ему не пришлось запоминать еще одно имя пользователя и пароль. С помощью федеративной аутентификации приложение может делегировать выполнение этой задачи внешнему поставщику удостоверений, который хранит учетные данные и проверяет их, когда пользователь входит в систему. Такой подход также позволяет снять с вашего приложения ответственность за хранение конфиденциальной учетной информации, поскольку теперь за это отвечает поставщик удостоверений.
Примечание
Более подробная информация представлена в разделе «Федеративная аутентификация» далее в данном приложении.
Аутентификация корпоративных пользователей и пользователей из
организаций-партнеров
К приложениям, используемым лишь ограниченным набором известных пользователей, как правило, предъявляются иные требования, отличные от требований к общедоступным приложениям. Обычно пользователям не нужно регистрироваться, чтобы получить доступ к своей учетной записи, пользователи предполагают, что организация уже создала и настроила учетную запись для них. Кроме

249 того, такая учетная запись будет содержать более подробную информацию, по сравнению с данными в общедоступных приложениях или у поставщика удостоверений, при этом учетная запись не доступна для редактирования пользователем. Например, учетная запись, как правило, определяет принадлежность к группе безопасности и адрес корпоративной электронной почты пользователя.
Рассматриваемый подход обычно характерен для «внутренних» или корпоративных учетных записей большинства организаций, доступ к соответствующим функциям приложения получают при помощи встроенных в операционную систему инструментов и службы каталогов. Однако, если требуется предоставить возможность входа в систему для известных пользователей из организаций-партнеров, необходима служба-посредник, которая доступна за пределами организации и может создавать маркеры для аутентификации на основе утверждений. С этой целью также можно использовать методы федеративной аутентификации, рассматриваемые далее в данном приложении.
Авторизация действий пользователя
Идентификация пользователей представляет собой лишь часть этого процесса. После аутентификации пользователей приложение должно контролировать их действия. Используемый для аутентификации на основе утверждений маркер, который пользователь получил от выбранного им поставщика удостоверений, может содержать утверждения, определяющие роль или разрешения для пользователей.
Однако это обычно актуально только в том случае, когда пользователь прошел аутентификацию у надежного поставщика удостоверений, например у корпоративной службы каталогов, и, следовательно, учетная запись пользователя содержит сведения о его роли (например, «Менеджер» или «Бухгалтер»).
Поставщики удостоверений социальных сетей, такие как Windows Live ID и Google, как правило, учитывают только утверждение, представляющее собой уникальный идентификатор пользователя, и, возможно, его имя. Поэтому в данном случае вам придется реализовать механизм сопоставления идентификатора пользователя с данными, присутствующими в вашем приложении или находящимися в центральном репозитории пользовательских учетных данных.
Репозиторий должен содержать информацию о ролях, разрешениях или правах для каждого пользователя, эти данные приложение может использовать для авторизации действий пользователей.
В случае с общедоступными приложениями, такими как интернет-магазин, хранилище, как правило, должно содержать информацию, предоставленную пользователями при регистрации (например, адрес и платежные реквизиты), что позволяет сопоставлять пользователя с его учетной записью, когда он входит в систему.
Мнение Джаны
Решения на основе утверждений и федеративной идентификации позволяют четко разделить задачи аутентификации и авторизации, поэтому изменения в одном решении не повлияют на другое. Такое разделение упрощает поддержку и обновление приложений в соответствии с новыми требованиями.
Доступ к службе аутентификации для клиентов вне браузера
Методы аутентификации на основе утверждений отлично работают в веб-браузерах, поскольку они предоставляют средства автоматического перенаправления, и с точки зрения пользователя этот процесс полностью автоматизирован, все происходит абсолютно беспрепятственно. Для клиентов вне браузера, например других приложений, которые отправляют запросы на обслуживание вашим веб-службам, вы должны публиковать информацию, позволяющую клиенту узнать, как получить необходимый маркер и сведения о принятых форматах и утверждениях, которые маркер должен содержать.

250
Клиент отвечает за получение необходимого маркера у подходящего поставщика удостоверений и STS, он должен представить этот маркер по запросу. Когда приложение получит маркер, оно может использовать содержащиеся в нем утверждения для авторизации доступа. Если маркер содержит только уникальный идентификатор, приложению, как правило, приходится сопоставлять его с существующей учетной записью, чтобы получить информацию о ролях, применимых к данному клиенту.
Авторизация доступа к очередям шины интеграции
Гибридные приложения, которые используют очереди шины интеграции Windows Azure, должны быть готовы к аутентификации пользователей, а также клиентских и партнерских приложений, запрашивающих доступ к очередям. Доступ к очереди шины интеграции предоставляется клиентам в соответствии с параметрами одного из трех режимов: отправка, прием или управление. С точки зрения безопасности очень важно определить разрешения, соответствующие клиентам, подключающимся к очереди, чтобы предотвратить несанкционированное чтение или отправку сообщений.
Мнение Маркуса
Топики и подписки шины интеграции работают так же, как и очереди, с точки зрения системы безопасности; аутентификация пользователей и авторизация доступа осуществляются аналогичным образом.
Авторизация доступа к конечным точкам службы Service Bus Relay
Гибридные приложения, которые используют службу Windows Azure Service Bus Relay, должны быть готовы к аутентификации пользователей, а также клиентских и партнерских приложений, запрашивающих доступ к конечным точкам службы Service Bus Relay. Клиенты, которые запрашивают доступ к конечной точке этой службы, должны предоставить подходящий маркер, если эта конечная точка не поддерживает анонимный доступ (без аутентификации). Служба должна находиться внутри корпоративной сети или защищенного периметра, поэтому в целях безопасности очень важно организовать проверку наличия у клиентов соответствующих разрешений при попытке получения доступа к службе Service Bus Relay.
Шина интеграции взаимодействует со службой Windows Azure Access Control, которая выступает в качестве системы идентификации по умолчанию для очередей шины обслуживания и конечных точек службы Service Bus Relay. Однако вы можете настроить шину интеграции на взаимодействие с другими поставщиками удостоверений.
Взаимосвязанные проблемы
Механизмы аутентификации и авторизации должны, по определению, быть безопасными и надежными, защищая приложения от несанкционированного доступа и неразрешенных операций. Тем не менее другие требования также важны, и их необходимо учитывать в ходе реализации системы аутентификации и авторизации в гибридных приложениях Windows Azure.
Безопасность
Личность пользователя или клиента необходимо устанавливать точно и однозначно со степенью уверенности, позволяющей исключить спуфинг и другие виды атак, которые могут нарушить точность результата проверки. При использовании федеративной аутентификации и делегировании

251 ответственности за проверку удостоверения пользователя, вы должны выбрать надежного поставщика удостоверений и службы-посредники.
Доступ к STS и поставщикам удостоверений необходимо организовать через защищенное соединение
(протокол Secure Sockets Layer (SSL) или Transport Layer Security (TLS)), чтобы противостоять атакам методом перехвата сообщений и подмены ключей и предотвратить перехват учетных данных или маркеров аутентификации при отправке их по сети.
Многие STS могут зашифровать возвращаемые маркеры аутентификации, это должно рассматриваться в качестве дополнительного уровня безопасности, помимо защищенных соединений.
Если используется внутренний репозиторий с учетными данными пользователей, его необходимо защищать от внешнего несанкционированного доступа по сети и от внутренних атак, связанных с физическим доступом к серверам, нужно настроить соответствующие разрешения для таблиц и содержимого хранилища. Вся конфиденциальная информация должна быть зашифрована, чтобы ее было бесполезно похищать.
Вы должны учитывать юридические и договорные обязательства в отношении личной информации (PII) о пользователях, которая содержится в хранилище.
Время отклика
Механизмы аутентификации могут стать узким местом в приложениях, которые должны авторизовать большое количество пользователей одновременно, например в начале рабочего дня. Ваша система должна быстро обрабатывать запросы даже в периоды пиковой нагрузки. Имейте в виду, что этот процесс может включать несколько переходов между различными сетями, объединяющими поставщиков удостоверений и STS, и любой из этих переходов может стать слабым звеном в цепи событий.
Надежность
Механизмы аутентификации часто превращаются в единственную точку отказа. Достаточно просто добавить к приложению несколько новых серверов, чтобы обеспечить дополнительную пропускную способность приложений. С механизмами аутентификации ситуация сложнее, поскольку все они должны получать доступ к единому хранилищу или использовать внешнего поставщика удостоверений, над которым вы не имеете никакого контроля. В случае возникновения сбоя в работе системы аутентификации, пользователи не смогут работать с приложением.
Совместимость
Протоколы и механизмы аутентификации на основе утверждений обеспечивают совместимость по умолчанию. Они используют основанные на стандартах протоколы и форматы для передачи и защиты маркеров. Некоторые STS и поставщики удостоверений могут предоставлять маркеры только одного типа, например Simple Web Token (SWT), в то время как другие системы могут принимать или возвращать маркеры других типов, например Security Assertions Markup Language (SAML). Необходимо убедиться, что выбранные вами поставщики и службы соответствуют требованиям и совместимы между собой.

252
Технологии аутентификации и авторизации на основе
утверждений
В данном разделе приводится краткий обзор технологий аутентификации и авторизации, которые обычно используются в приложениях для Windows и приложениях, размещаемых в Windows Azure. Основное внимание уделяется аутентификации на основе утверждений, поскольку такой подход представляется наиболее подходящим для гибридных приложений.
Рассматриваются следующие темы:

Федеративная аутентификация, службы маркеров безопасности и поставщики удостоверений.

Платформа Windows Identity Foundation (WIF).

Служба Windows Azure Access Control (ACS).
Федеративная аутентификация
В традиционных приложениях аутентификация и авторизация, как правило, осуществляются при помощи функций операционной системы, которые используют службы корпоративных каталогов, такие как Microsoft Active Directory, а также при помощи инструментов для настройки разрешений на доступ к ресурсам, таких как списки контроля доступа (Access Control Lists, ACL). Современные платформы и технологии, например Microsoft ASP.NET, предоставляют встроенные механизмы для реализации аналогичного подхода в веб-приложениях.
Все перечисленные подходы требуют наличия каталога пользователей, который определяет, кто может получить доступ к приложению или службе, и какие операции разрешено выполнять. Задача ведения таких списков связана с многочисленными трудностями, часто могут возникать ошибки или бреши в системе безопасности. Например, если у вас хранится список пользователей партнерской организации, которые могут получать доступ к приложению, партнер должен уведомлять вас, когда какой-либо пользователь покидает компанию или вносятся изменения в разрешения для конкретных пользователей.
Вместо этого вы можете довериться партнеру и делегировать ему задачу ведения списка пользователей и их ролей. Вы по-прежнему сохраняете контроль над авторизацией и перечнем задач, которые пользователи могут выполнять в приложении, но вы освобождаетесь от необходимости аутентификации каждого пользователя и определения его принадлежности к соответствующим ролям или группам.
Подход, подразумевающий делегирование ответственности за аутентификацию, требует наличия стандартного механизма для формирования запросов к хранилищам информации о пользователях и распространения маркеров, которые содержат утверждения. Службы маркеров безопасности (Security
Token Services, STS), такие как служба федерации Active Directory (Active Directory Federation Service,
ADFS) и служба Windows Azure Access Control Service, предоставляют необходимые возможности. Кроме того, для других платформ и операционных систем доступны совместимые STS.
Каждая STS взаимодействует с поставщиками удостоверений (Identity Providers, IdPs), которые отвечают за аутентификацию пользователей. После того, как поставщик удостоверений выполнит аутентификацию пользователя, STS создаст для него маркер, содержащий утверждения. При использовании веб-браузера этот маркер сохраняется в виде файла cookie, а для смарт-клиентов и приложений служб маркер включается в ответ службы (в зависимости от используемого протокола).
STS может также предоставить файлы cookie веб-браузеру, что означает, что пользователь прошел

253 аутентификацию и может получить доступ к другим приложениям без необходимости заново вводить учетные данные. Таким образом организован единый вход в систему (single sign-in, SSO).
Мнение Бхарата
ADFS выступает в роли IdP и STS одновременно, поскольку может использовать Active
Directory для проверки пользователя на основе предоставляемых им учетных данных. ACS использует внешние IdPs, такие как Windows Live ID, Google, Facebook и OpenID, но вы также можете создать идентификаторы служб в ACS, позволяющие клиентам пройти аутентификацию без использования внешнего IdP.
Вы должны выбрать надежную службу STS для своего приложения. Это может быть ваша собственная служба STS, например ADFS, подключенная к вашему корпоративному каталогу Active Directory. Также можно использовать внешнюю службу STS, такую как ACS. Вы также можете настроить STS на взаимодействие с другой STS, и пользователи смогут проходить аутентификацию при помощи любой службы STS в цепочке отношений доверия, как показано на рисунке 1.
Рисунок 1
Цепочка отношений доверия для аутентификации, которая может поддерживать
федеративные удостоверения и единый вход
Обзор процесса аутентификации на основе утверждений
Служба STS выбирает IdP, который будет выполнять аутентификацию пользователя с учетом его домашней области или домена. Например, домашней областью пользователя будет Google, если этот пользователь имеет удостоверение, которое управляется и аутентифицируется Google. Если учетная запись пользователя принадлежит к корпоративному каталогу Active Directory, домен компании будет его домашней областью. Когда пользователь проходит аутентификацию через веб-браузер, STS направляет его к соответствующему IdP. Если пользователь может успешно пройти аутентификацию, IdP возвращает маркер с утверждениями (информацией) для этого пользователя в службу STS. Служба STS затем генерирует маркер для конкретного приложения, который может содержать эти утверждения или их расширенную версию, и перенаправляет пользователя в приложение вместе с этим маркером.
Приложение может использовать утверждения в данном маркере для авторизации действий пользователя. На рисунке 2 показана упрощенная схема процесса, ACS используется в качестве поставщика маркера.

254
Рисунок 2
Упрощенное представление процесса аутентификации через браузер с использованием ACS
и поставщиков удостоверений социальных сетей
В целях поддержки единого входа, STS может сохранить в рабочих каталогах браузера дополнительный файл cookie, содержащий маркеры для конкретной STS, чтобы подтвердить тот факт, что пользователь успешно прошел аутентификацию. Когда пользователь пытается получить доступ к другому приложению, которое доверяет той же службе STS, эта STS может создать подходящий маркер, не требуя от пользователя повторной аутентификации в системе IdP.
Авторизация запросов веб-службы
Описанный выше процесс автоматического перенаправления применим только к задаче аутентификации запросов, поступающих из веб-браузера. Запросы к веб-службе могут быть созданы кодом, выполняемым в другом приложении, например в клиентском смарт-приложении или приложении-службе. В подобной среде, вне веб-браузера, функция перенаправления запросов и файлы cookie не могут использоваться для того, чтобы направить запрос по цепочке из нескольких STS и IdP.
При использовании аутентификации на основе утверждений в клиентском смарт-приложении или веб- службе, клиент должен запрашивать маркеры, необходимые на каждом этапе, и отправлять эти маркеры вместе с запросом к следующему звену в цепочке аутентификации. На рисунке 3 показана упрощенная схема этого процесса для смарт-клиента или веб-службы, ACS используется в качестве поставщика маркера.

255
Рисунок 3
Упрощенное представление процесса аутентификации для смарт-клиента или веб-службы
с использованием ACS и поставщиков удостоверений социальных сетей
Аутентификация на основе утверждений для веб-браузеров называется пассивной, потому что браузер автоматически выполняет перенаправление и предоставляет маркеры на соответствующих узлах цепочки событий, связанных с аутентификацией. Аутентификация вызовов служб, когда этот процесс управляется кодом приложения, называется активной.
Более подробная информация об активной аутентификации представлена в статье «Claims
Enabling Web Services» на сайте http://msdn.microsoft.com/en-us/library/hh446528.aspx
Платформа Windows Identity Foundation
Microsoft предоставляет специализированную платформу, которая позволяет легко реализовать аутентификацию и авторизацию на основе утверждений в веб-приложении и приложении-службе.
Платформа Windows Identity Foundation (WIF) — базовый компонент службы управления идентификацией и доступом Microsoft на базе каталога Active Directory, служб федерации Active
Directory, служб Windows Azure Access Control Services, а также технологии федеративной аутентификации на основе утверждений.
Платформа WIF автоматически проверяет запросы на наличие необходимых маркеров на основе утверждений и выполняет перенаправление в веб-браузерах к указанной STS, где они могут быть получены.
Платформа также предоставляет утверждения в действующих маркерах коду приложения, который позволяет принимать решения об авторизации на основе этих утверждений. Платформа WIF включает мастер, который разработчики могут использовать в среде разработки Visual Studio или в командной строке, для настройки приложений на поддержку проверки подлинности на основе утверждений.
Компоненты WIF генерируют события в ходе обработки запросов, позволяя разработчикам контролировать этот процесс по мере необходимости. Платформа WIF также включает элементы управления, которые могут быть встроены в пользовательский интерфейс приложения с целью реализации функций входа в систему и выхода из нее.

256
Примечание
Дополнительная информация о платформе Windows Identity Foundation представлена на домашней странице об управлении удостоверениями http://msdn.microsoft.com/en- us/security/aa570351.aspx
, а также в подготовленном группой Patterns & Practices руководстве «Claims Based Identity & Access Control Guide» (
http://claimsid.codeplex.com/
).
Служба Windows Azure Access Control
Windows Azure Access Control Service (ACS) — это облачная служба, которая упрощает аутентификацию и авторизацию веб-сайтов, приложений и пользователей службы. Она совместима с большинством самых распространенных сред программирования и выполнения. Служба ACS интегрируется с инструментами и средами WIF и службами федерации Microsoft Active Directory (ADFS), а также поддерживает целый ряд протоколов, включая OAuth, OpenID, WS-Federation и WS-Trust.
Аутентификация возможна с использованием множества популярных корпоративных и интернет- поставщиков удостоверений.
Когда пользователь запрашивает аутентификацию через веб-браузер, ACS получает запрос от веб- приложения и представляет страницу обнаружения домашней области, где перечислены поставщики удостоверений, которым веб-приложение доверяет. Пользователь выбирает поставщика удостоверений, и ACS перенаправляет его на соответствующую страницу входа. Пользователь входит в систему и возвращается к ACS с маркером, содержащим утверждения, которые пользователь предоставил этому поставщику удостоверений. Служба ACS затем применяет соответствующие правила для преобразования утверждений и создания на их основе нового маркера. Правила, настроенные в ACS, позволяют выполнять преобразование протоколов и утверждений в соответствии с требованиями веб-приложения. Пользователь перенаправляется в веб-приложение с маркером ACS. Веб-приложение может использовать содержащиеся в маркере утверждения, чтобы применить подходящие для данного пользователя правила.
ACS принимает маркеры в формате SAML 1.1, SAML 2.0 и SWT, и выдает в формате SAML 1.1,
SAML 2.0 или SWT.
Процесс аутентификации запросов от смарт-клиентов и других приложений-служб отличается отсутствием взаимодействия с пользователем. Вместо этого служба должна получить подходящий маркер от поставщика удостоверений, потом предоставить этот маркер ACS для преобразования, а уже преобразованный — доверенному участнику.
Служба ACS также выступает в качестве поставщика удостоверений для шины интеграции Windows Azure.
Вы можете настроить роли и разрешения для очередей шины интеграции и конечных точек службы
Service Bus Relay при помощи ACS. Шина интеграции автоматически связывается с ACS и использует эту службу для проверки доступа и операций над очередями и конечными точками.
ACS настраивается через интерфейс службы при помощи API на основе OData или через веб-портал, который предоставляет графические интерактивные инструменты администрирования. Для настройки
ACS вы также можете использовать командлеты интерфейса командной строки Windows Azure
PowerShell. Эти командлеты предоставляют упаковщики для OData API и позволяют создавать сценарии, которые можно использовать для автоматизации многих задач для конфигурирования ACS.

Каталог: download
download -> Составление простейшей программы в среде lego education. Запуск модели «Обезьянка барабанщица», «Рычащий лев», «Автомобиль»
download -> Функциональные части компьютера, история развития, базовая конфигурация
download -> Компьютер: друг или враг?
download -> Лекция №2 «Теоретические основы игры дошкольника» Зарубежные и отечественные теории игры
download -> Доклад муниципальное образовательное
download -> Литература для воспитанников стр. Приложения стр
download -> Министерство здравоохранения Республики Беларусь
download -> Игра как средство активизации познавательной активности учащихся в ходе изучения темы Алгоритмизация и программирование


Поделитесь с Вашими друзьями:
1   ...   15   16   17   18   19   20   21   22   ...   33


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал