Архитектура сервисов аутентификации и авторизации и сетевая идентификация в Интернет
Architecture of Authentication and Authorisation services and Network Identity

Юрий Демченко
NLnet Labs, Амстердам
demch@nlnetlabs.nl

Аннотация
В докладе рассматриваются современные технологии построения сервисов аутентфикации и авторизации для Интернет приложений и использование сетевой идентификации для единого входа в распреденные сетевые приложения. Основное внимание уделяется использованию современных стандартов для обеспечения безопасного взаимодействия распределенных сетевых приложений, основанных на XML (SAML, Liberty, XML Signature, и др.). Приведены примеры существующих систем для распределенной аутентификации и авторизации.


1. Введение
2. Современная архитектура сервисов аутентификации и авторизации
3. Cетевая идентификация и Single-Sign-On (SSO)
4. Примеры систем распределенной аутентификации и авторизации
5. Выводы
6 Литература


1. Введение

Эффективная реализация сервисов аутентификации и авторизации (AuthN, AuthZ) является важным фактором построения эффективных веб-приложений и, в частности, веб-сервисов (Web Services). Большинство современных веб-приложений обьединяют множество отдельных сервисов, часто распределенных географически и в сети. Необходимость аутентификации пользователя/клиента каждым из приложений при предоставлении комплексных услуг составляет серьезное ограничение для современного электронного бизнеса (в частности, B2B-приложений). В свою очередь развитие веб-сервисов, которые очень сильно зависят друг от друга, в принципе ставит задачу обеспечения единой аутентификации пользователя для всего сервиса/задания, реализованного через веб-сервисы.

Современные коммерческие и некоммерческие решения основаны на использовании Инфраструктуры Открытых Ключей (PKI – Public Key Infrastructure), обеспечивающей функцию идентификации пользователя, директорий и интегрирующих их мета-директорий (в большинстве случаев на основе LDAP), реализующих соответственно функции аутентификации пользователя и интеграции распределенных идентификаторов пользователя. Однако такие решения работают только в иерерахических PKI-структурах и в пределах одного административного или доверительного домена (trust domain), и в большинстве случаев только в рамках одного предприятия, хоть и распределенного. При доступе пользователя к определенным сервисам или ресурсам в таких случаях требуется его аутентификация службой доступа ресурса или сервиса, что часто выливается во множественных мандатах (credentials), удостоверяющих личность (identity) пользователя.

2. Современная архитектура сервисов аутентификации и авторизации

Эффективное решение проблемы множественной идентификации пользователей требует изменения основной парадигмы в построении инфраструктуры безопасности приложений, основанных на веб-сервисах, по сравнению с традиционной архитектурой безопасности сетевых приложений, основанной на ISO7498-2. Главное отличие состоит в том, что существующая архитектура безопасности ориентирована на взаимодействие сетевых обьектов или субьектов, которые могут быть компьютеры, хосты, пользователи, клиенты или серверы, и обеспечивает безопасность коммуникаций между конечными точками (end-to-end или peer-to-peer). В том время как распределенные сетевые приложения и веб-сервисы с распределенными ресурсами требуют новую архитектуру безопасности, которая в основу архитектуры ставит семантический обьект - документ, сообщение, задание, связанные с инициировавших их субьектом или другим приложением, - который может перемещаться между множественными серверами, сервисами и доверительными доменами.

Другой чертой новой архитектуры безопасности, ориентированной на веб-сервисы, является разделение функций аутентификации и авторизации и использование инфраструктуры управления привилегиями, основанной на политике и управлении доступом на основе ролей (Policy/Role Based Access Control (RBAC) и Privilege Management Infrastructure (PMI)), определенной также, как и PKI, стандартом X.509, а также ISO 10181-3 Access Control Framework. Элементами такой архитектуры являются: сервис/функция аутентификации (AuthN), функция контроля доступа (Access Enforcement Function (AEF) или Policy Enforcement Point (PEP)), функция принятия решения о доступе (Access Decision Function (ADF) или Policy Decision (PDP)), политика доступа (Access Control Information (ACI) или Policy).

Архитектура аутентификации, авторизации и учета (AAA – Authentication, Authorisation, Accounting), в основном ориентированная на мобильные сетевые приложения, описана группой стандартов IETF RFC 2902-2906. Предложенная архитектура определяет базовый протокол AAA, и включает распределенные AAA-серверы, AAA-менеджеры ресурсов (ASM – Application Specific Module), модули политики (RP – Policy and event Repository), удостоверяющие центры (CA – Certification Authority), формирующие административные или доверительные домены (далее домены). Такая архитектура может работать в много-доменной среде, однако сложность ее практического применения, кроме мобильной связи, усложняется необходимостью интегрального ААА-протокола, в то время как архитектура безопасности веб-сервисов требует раздельных функций AuthN и AuthZ, которые соответственно должны относиться к субьекту и ресурсу.

Авторизация или контроль доступа в целом осуществляется ресурсом, к которому запрашивается доступ, и решение принимается на основе принятой политики доступа в соответствии с предоставленными пользователем мандатами, которые могут включать удостоверяющие идентификаторы, полномочия или ролевые функции и другие данные, предоставляемые службой аутентификации. При этом все или часть исходных данных могут быть предоставлены сами пользователем (push-модель) или запрошены службой авторизации (pull-модель), соответственно функции/модули ADF/PDP также могут работать в режимах push или pull.

3. Cетевая идентификация и Single-Sign-On (SSO)

Важным развитием сетевой услуги аутентификации является обеспечение сервиса единого доступа (SSO – Single-Sign-On), который позволяет пользователю предоставлять удостоверяющие данные (мандат) только один раз при входе в группу сервисов, обьединенных доверительными отношениями. Сущуествующие решения позволяют осуществлять SSO только в пределах одного административного или доверительного домена и используют централизованную службу аутентификации на основе централизованных директорий или мета-директорий. Первой попыткой создать глобальную систему SSO было предложение Microsoft Passport, однако это решение основано на существовании центральной директории, хранящей набор данных о пользователях, как например, адрес, предпочтения при выборе услуг, и оно не нашло широкой поддержки в среде бизнеса, широко использующего распределенные веб-сервисы. Это стало причиной возникновения широкой инициативы среди ведущих ИТ фирм Liberty Alliance Project (LAP), который насчитывает в данный момент более 150 участников.

Стандартный механизм SSO, разработанный LAP, позволяет решить проблему единого входа для веб-сайтов и для веб-сервисов. Предлагаемый механизм SSO основан на доверительных отношениях, которые существуют между отдельными бизнесами или провайдерами, которые могут формировать «круг доверия» (circle-of-trust), который инициируется пользователем и формируется посредством провайдера идентификации (Identity Provider), который осуществляет начальную аутентификацию пользователя. LPA определяет отношения и формат сообщений, которыми обмениваются пользователь, провайдер идентификации и сервис-провайдер. Особенностью данного подхода является то, что пользователь инициирует создание круга доверия и осуществляет полный контроль над использованием/распространением своих данных. Кроме создания круга доверия, который может существовать на время выполнения определенной задачи и разрушается после выхода пользователя из системы, пользователь может создать «федеративную» идентификацию, которая будет обьединять многие частные мандаты и сетевые удостоверения пользователя между провайдерами и сервисами, которые «доверяют» друг другу и которым доверяет пользователь, что является существенным отличием от предыдущих решений.

Предлагаемое LPA решение основано на использовании стандартного языка SAML (Security Assertion Markup Language), основанного на XML. Стандарт SAML разрабатывается авторитетной промышленной организацией по стандартизации OASIS (Organization for the Advancement of Structured Information Standards). SAML используется для описания контекста и деклараций безопасности, которые могут встраиваться в сообщения или другие семантические обьекты в формате XML, обменивамые между системами в процессе выполнения функций AuthN/AuthZ. SAML определяет формат таких деклараций, протокол для обмена и запроса деклараций безопасности, а также использование транспортных протоколов SOAP (Simple Object Access Protocol) и HTTP.

Декларации SAML включают:

SAML также определяет формат запроса, назначение и формат которого опредляются предоставленными декларациями, например: «Разрешено ли действие Y в отношении ресурса Z пользователем S».

Как с примером Liberty Alliance Project, предполагается, что SAML станет базовым форматом для других сервисов безопасности, включая веб-сервисы (Web Services Security) и Грид-сервисы (Open Grid Services Architecture (OGSA) Security). В этом плане SAML предоставлет серьезную альтернативу существующими сервисам AuthN/AuthZ на основе X.509 и LDAP. Однако посредством цифровой подписи в формате XML (XML Signature), которая является компонентом SAML, SAML позволяется использовать сертификаты открытых ключей X.509 и сертификаты атрибутов (Attribute Certificate) в качестве деклараций аутентификации и авторизации.

4. Примеры систем распределенной аутентификации и авторизации

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

1) PERMIS (Privilege and Role Management Infrastructure Standards validation)

PERMIS построен, исходя из базовой концепции разделения функций аутентификации и авторизации, и использует архитектуру авторизации на основе политики и ролей, которые определяются X.509 Attribute Certificate (AC). Основные черты системы:

2) SPOCP (Simple Policy Control Protocol)

SPOCP формирует решение об авторизации доступа на основе запроса от своих клиентов, используя следующую информацию:

SPOCP использует LISP-выражения для описание политики доступа и формирования решения о доступе. SPOCP использует упрощенный протокол и формат сообщений по сравнению с SAML и XACML, однако может «понимать» и «говорить» посредством SAML.

3) Shibboleth и WebISO/Pubcookie

Shibboleth и WebISO/Pubcookie разработаны в рамках проекта Internet2 и используются университетами США для меж-университетской аутентификации и авторизации и единого доступа к ресурсам, распределенными между университетами.

Shibboleth обеспечивает авторизацию, основанную на атрибутах пользователя, и использует SAML в качестве формата деклараций AuthN/AuthZ и протокола. Особенностью Shibboleth является забота/контроль конфиденциальности пользователя: данные о пользователе хранятся в его родной организации и процедура авторизации запрашивает только минимальный набор данных, необходимых для принятия решения; таким образом Shibboleth имеет возможность использовать внешние сервисы аутентификации.

Система WebISO разработана с целью дать возможность пользователям со стандартным броузером осуществлять доступ к распределенным сервисам, включающим множественными веб-серверы, используя обычную центральную службу аутентификации (ка правило, посредством имени/пароля).

4) Другие системы: A-Select, PAPI

A-Select предлает службу аутентификации для веб-приложений, относящихся к одному административному или доверительному домену. Дальнейшее развитие системы и использование SAML позволят осуществлять меж-доменную аутентификаци и предоставлять услуги аутентификации другим системам.

PAPI (Point of Access to Provider of Information) я вляется системой, обеспечивающей контроль доступа к ресурсам с ограниченным доступом. PAPI использует локальную аутентификацию пользователя для формирования авторизационного маркера (token), передаваемого пользователю в качестве cookie. PAPI является достаточно простой системой, но ее дальнейшее развитие на основе использования SAML позволит ей успешно интегрироваться с другими системами.

5. Выводы

Дальнейшее развитие услуг аутентификации и авторизации основано на использовании модели управления доступом на основе ролей или атрибутов пользователя и политики доступа, определяемой ресурсом. Аутентификация пользователя для доступа к множественным связанным веб-сервисам осуществляется на основе обьединения («федерации») множественных идентификаторов пользователя, предоставляемых провайдерами идентификации. Основой для развития новой архитектуры безопасности и сетевых услуг аутентификации и авторизации является технология безопасности XML, которая включает SAML, XACML, Web Services Security, и др., и позволяет включать декларации и контекст безопасности в семантические обьекты типа сообщений или документов.

6 Литература

  1. Demchenko Y. Overview of existing and developing systems for Authentication and Authorisation and Policy/Role based Privilege Management - http://www.uazone.org/demch/analysis/aaa-pmi-overview.html
  2. Demchenko Y. Security Architecture for Open Grid Services and related developments GGF5 and follow-on developments overview - http://www.uazone.org/demch/analysis/ggf5ogsa-security.html
  3. Demchenko Y. Global Grid Forum: Moving to Open Grid Services Architecture (OGSA) - Overview of GGF4 and follow-on developments - Yuri Demchenko, May 2002 - http://www.uazone.org/demch/analysis/ggf4ogsa-overview.html
  4. XML Web Services Security Overview. - Seminar at IIDS Group, Vrije Universiteit. - 27 March, 2003 - http://www.uazone.org/demch/presentations/ws-xml-sec.ppt
  5. XML Security in IODEF. - INCH WG, IETF56. - March 19, 2003 - http://www.ietf.org/proceedings/03mar/slides/inch-3/index.html
  6. Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC 3280) - http://www.ietf.org/rfc/rfc3280.txt
  7. An Internet Attribute Certificate Profile for Authorization (RFC 3281) - http://www.ietf.org/rfc/rfc3281.txt
  8. RFC2902-RFC2906 – Authentication, Authorisation, Accounting Framework http://www.ietf.org/rfc/rfc2902.txt - rfc2906.txt
  9. Internet X.509 Public Key Infrastructure Proxy Certificate Profile - http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-05.txt
  10. ITU-T Rec. X.812(1995) | ISO/IEC 10181-3:1996, Information technology - Open systems interconnection - Security frameworks in open systems: Access control framework.
  11. XML-Signature Syntax and Processing. W3C Recommendation. 12 February 2002 - http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
  12. Security Assertion Markup Language (SAML) v1.0 - OASIS Standard, 5 November 2002 - http://www.oasis-open.org/committees/documents.php?wg_abbrev=security
  13. eXtensible Access Control Markup Language (XACML) Version 1.0 - OASIS Standard, 18 February 2003 - http://www.oasis-open.org/committees/documents.php?wg_abbrev=xacml
  14. SOAP Version 1.2 Part 0: Primer - http://www.w3.org/TR/2002/CR-soap12-part0-2002121
  15. Web Services Security: SOAP Message Security Draft 11 – March 2003 - http://www.oasis-open.org/committees/download.php/1044/WSS-SOAPMessageSecurity-11-0303-merged.pdf
  16. European Electronic Signature Standardisation Initiative (EESSI) - http://www.ict.etsi.org/EESSI/EESSI-homepage.htm
  17. PERMIS (Privilege and Role Management Infrastructure Standards
    validation) - http://sec.isi.salford.ac.uk/permis/
  18. SPOCP (Simple POlicy Control Protocol) - http://www.spocp.org/
  19. Shibboleth - http://shibboleth.internet2.edu/
  20. WebISO/Pubcookie - http://middleware.internet2.edu/webiso/
  21. A-Select - http://a-select.surfnet.nl/
  22. The Security Architecture for Open Grid Services - http://www.globus.org/ogsa/Security/