Post on 02-Jan-2016
description
transcript
Обеспечение гибкой системы контроля доступа
в Веб-сервисах и Грид-системах
RELARN2005 16 июня, 2005
Yuri Demchenko <demch@science.uva.nl>
AIRG, University of Amsterdam
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_2
Содержание
Услуги Аутентификации (AuthN) и Авторизации (AuthZ) в научных и образовательных сетях
Модель безопасности и контроль доступа в системах ориентированных на услуги (СОУ)
Система контроля доступа на основе политики (СКДП) и модель Role Based Access Control (RBAC)
Оптимизированные модели push-pull-agent и использование квитанций/билетов и маркеров авторизации (AuthZ tickets and tokens)
Отношения доверия в распределенной инфраструкутре контроля доступа Политика доступа и существующие форматы
Примеры систем распределенной аутентификации и авторизации
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_3
AuthN/AuthZ в научных и образовательных сетях
Доступ к многосайтовым Веб/Интернет ресурсам Система единого доступа (SSO – Single Sign On) и системы управления
идентификацией (IdM - Identity management)
Межуниверситетские ресурсы и доступ к внешним ресурсам или предоставление доступа для внешних пользователей
Распределенные университетские кампусы и дистанционное обучение Грид-центры и Грид-приложения
Различные административные домены и домены безопасности Продолжительные (транзитивные) задачи Динамические ресурсы и виртуальные ассоциации ресурсов и пользователей
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_4
Современная архитектура сервисов AuthN и AuthZ
Проблемы Множество логинов/паролей – на каждый ресурс/сайт Ограничение одним доменом безопасности или множество сертификатов
открытых ключей Сложность частичной динамической делегации полномочий
Требования к современной архитектуре AuthN/Z Разделение сервисов аутентификации (AuthN) и авторизации (AuthZ)
Аутентификация в «домашней» организации Авторизация ресурсом
Конфиденциальность, приватность и анонимность Контроль доступа к атрибутам на основе политики
Управление доступом на основе ролей и политики безопасности (RBAC) и инфраструктуры управления привелегиями (PMI)
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_5
Новая парадигма безопасности приложений
Традиционные модели безопасности (ISO7498-2) и POSIX: Host-to-host или point-to-point security Ориентированная на архитектуру Client/Server Основанные на соединение (connection-oriented) и нет (connectionless) В общем случае единый доверительный домен (на основе PKI)
Безопасность приложений основе XML Безопасность между конечными точками приложений (End-to-end) Ориентированная на документ (или семантический обьект)
Квитанции, мандаты и маркеры безопасности могут быть ассоциированы с документом или сообщением или их частью
Потенциально работает между различными доменами административными и безопасности
Позволяет создавать динамические и виртуальные ассоциации
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_6
Модель контроля доступа в СОУ
AuthN (SSO)
AttrA
Zone R1 Zone R0 Zone RN Zone RA Zone RAA
Resource IF/Agent Resource Manager
Resource (Local File System)
Internet/Network Access
Site AuthN Identity/Attributes
(TA/BA/VO Contx)
Site AuthZ (Policy Enforcement)
Resource/Service Site
UserDB
Req/User Client
PolicyA
AuthZ (Policy
Enforcemnt)
PEP
PDP
Resource IF/Agent (IntFW)
ACL
(ResAuthZ)
Resource/ Service
FW Appl Srvr/
Contnr
Data
Local FileSyst
Creds
Attrib
PolicyA
IdentP TA/BA
IdentP TA/BA
User HomeOrg
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_7
Архитектура безопасности Грид и Веб-сервисов
Communication/Transport Security: SSL/TLS, VPN, IPSec, Firewall, etc.
Intrusion Detection and
Incident Response
Policy Management
(AuthZ, Privacy, Trust,
Federation)
Key Management
Messaging Security: SOAP/WS- Security
Policy Expression and Exchange
Confidentiality and
Privacy Policy
Identity/ Federation Policy
Trust Management
Policy
Authorisation Policy
Services/Operational Security
Auditing and Notarisation
Authentication and Identity Management
Authorisation (Access Control)
Secure Context Management
Site Security Services
User Management
Secure Logging
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_8
Требования к Системе Контроля Доступа на основе Политики (СКДП)
Выражение политики для множества доменов и организаций (Multidomain and inter-institutional)
Множество форматов описания политики (multiple policy format) Комбинирование и агрегирование множества политик (policy combination
and aggregation) Множество центров удостоверения политики (multiple policy authority) Управление политикой независимо от управления основными функциями
(independent policy administration) Динамическое приложение/ассоциирование политики с основными
функциями (dynamic policy association)
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_9
СКДП и управление доступом на основе ролей
RBAC – Role Based Access Control Роль описывает функцию Права/привилегии определяют доступ к ресурсу в определенном режиме Правила доступа описаны в форме политики доступа
Возможно комбирирование множественных политик
Преимущества RBAC Легко управлять и контролировать Раздельное назначение ролей-пользователей и ролей-привилегий Поддерживает принцип минимально необходимых привилегий Масштабируемость, наследование и агрегирование привилегий/прав Возможность делегирования
ISO STD on PMI (Privilege Management Infrastructure) как основа для RBAC Строится на основе X.509 Сертификатов Атрибутов (AC – Attribute Certificate)
АС позволяет связать идентификатор пользователя с ролями и роли с привилегиями
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_10
(1) Generic AAA Architecture by AIRG (UvA)
Решение о доступе на основе политики Req {AuthNtoken, Attr/Roles,
PolicyTypeId, ConditionExt} RBE (Req + Policy) =>
=> Decision {ResponseAAA, ActionExt}
ActionExt = {ReqAAAExt, ASMcontrol}
ResponseAAA = {AckAAA/RejectAAA, ReqAttr, ReqAuthN, BindAAA (Resource, Id/Attr)}
Generic AAARBE
PolicyPolicyPolicy
Request/ResponseRequest/ResponseRequest/Response
ASMASMASM
•Преобразование logDecision => Action •Преобразование State => LogCondition
•Политика доступа определяется ресурсом
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_11
(2) RBAC: потоки данных и компоненты – Модель XACML
PEP/AEF - Policy Enforcement Point (authorisation enforcement function)
PDP/ADF - Policy Decision Point (authorisation decision function)
PIP - Policy Information Point
AA - Attribute Authority
PAP - Policy Authority Point
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_12
Служба авторизации сайта на основе RBAC и комбинированная модель pull-push
Важные вопросы:
• Комбинирование множества политик
• Последовательность PEP (chaining) и рекурентность PDP (nesting)
• Множество доменов доверия и административных (Multiple domains)
Requestor
AuthN and
IdentMngt
Site Services/Resources
Resource/ Service
PDP PDP
PDP (Master)
Attribute Authority
PAP
PEP1 PEP2
PDP (Secondary)
chain
PAP (local)
PAP
PDP (Secondary)
chain
PDP (local)
User login
IF
Srv Req
Srv Deliv AzTicket
AzTicket
Ext AuthZ
IF
AzReq
An Req/ Resp
AzTicket
PDP types call
Attr Req/Valid
AuthN Req/Valid
AuthN Req
Extern PDP chain
AzTicket
Az Tickt
Decision
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_13
Служба авторизации сайта на основе комбинированной модели agent-push для сложных ресурсов
Важные вопросы:
• Ресурсы, состоящие из множества компонентов и принадлежащих множеству доменов (Multi-component and multidomain resources)
• Включение политики в запрос и/или использование квитанций (Policy push and/or token based access control)
Requestor
AuthN and
IdentMngt
Site Services/Resources
Resource/ Service
PDP (Driving)
Attribute Authority
PAP
PEP1 (ASM)
PEP2 (ASM)
PAP
PDP2 (Driving)
Srv Req
Srv Req
AzTicket
AzTicket
AuthNReq
AzTicket
RecursPDP call
Attr Req/Valid
AuthN Req/Valid
AuthN Req
Recursive PDP
flow/chain
User login/ AuthZ
IF
Srv Req
Resource/ Service
AzTicket
Srv Req
SrvDeliv SrvDeliv
Srv Req
Srv Req
AzTicket
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_14
СКДП: Вопросы внедрения
PDP и PAP должны иметь общее пространство имен (namespace) Запрос (request message) должен содержать ссылку на Политику и соответствующий
PAP или эта информация должна быть известна PEP и PDP заранее Каждый PEP в цепочке приложения политики (policy enforcement) должен
обрабатывать запрос полностью, обращаясь к соответствующему главному PDP (master PDP). PEP не должен производить комбинацию множества решений нескольких PDP
Только один PDP должен формировать окончательное решение по исходному запросу Однако, PEP при этом может запрашивать различные типы PDP в зависимости от
семантики или пространства имен запроса и используемой политики В случае использования квитанций или билетов (ticket/token) для оптимизации
производительности контроля доступа, PEP должен понимать и иметь возможность проверять (validate) AuthZ-билеты, выданные доверительным PDP (trusted PDP) При этом AuthZ-билеты должны иметь ограниченный срок годности и назначение
(validity and usage restriction) и содержать информацию о принятом авторизационном решении и о ресурсе
Для ускорения процесса последующей проверки и повышения безопасности, PEP может кэшировать AuthZ-билеты
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_15
Что нужно сделать до установки СКДП
Исходные технические правила и соглашения Распределение ключей и установление доверительный отношений
(Key distribution and trust establishing) В настоящее время в процессе поиска простой и эффективной модели
Формат для описания политики, включая семантику и пространства имен для субьекта, атрибутов и ролей, акций
Совместимость с существующими форматами, например SAML, XACML Практически, формат политики может определяться используемым/наличным
PDP
Формат для мандатов/сертификатов безопасности Standard vs proprietary
Протоколы и форматы сообщений SOAP + XACML Request/Response SOAP + SAMLP + XACML
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_16
Отношения доверия в AuthN/Z системах
Получение необходимых прав доступа для выполнения запрашиваемой акции:
User => AuthN(HomeOrg.IdentP, (UserDB | TA)) => => AuthZ(AttrA.roles, Policy.permissions) =>
=> Resource.permissions
AuthN (SSO)
AttrA
Zone R1 Zone R0 Zone RN Zone RA Zone RAA
Resource IF/Agent Resource Manager
Resource (Local File System)
Internet/Network Access
Site AuthN Identity/Attributes
(TA/BA/VO Contx)
Site AuthZ (Policy Enforcement)
Resource/Service Site
UserDB
Req/User Client
PolicyA
AuthZ (Policy
Enforcemnt)
PEP
PDP
Resource IF/Agent (IntFW)
ACL
(ResAuthZ)
Resource/ Service
FW Appl Srvr/
Contnr
Data
Local FileSyst
Creds
Attrib
PolicyA
IdentP TA/BA
IdentP TA/BA
User HomeOrg Последовательность доверия/мандатов делегирования для основных модулей
User.Cred => => (HO.user[TA] | UserD)=> User.roles(AA)=> Role.permissions(PA) => Resource. permissions
Trust/credentials chain and delegation between major modules:
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_17
Пример использования: Система контроля доступа в демо-системе Collaboratory.nl (CNL2)
JNLP – Java Network Launch Protocol
CHEF – Collaborative tool
Surabaya – Collaborative Workspace environment
WebClient
gAAA Server
Remote CNLInstrumentSurabaya
InstrumentController
PDP
PEP
CHEF
3. JNLP
1. Login
2. JNLP
5,10 startSession()
11,14 goLeft()
Job Mgt.
4. getJobInfo() 6,9 startSession()
7,8 requestDecision()
Note: we assume SSL TCP connections all over.
12,13 checkAuthZStatus()
Locations/trust domains
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_18
CNL2 AuthZ policy: Resource, Actions, Subject, Roles
Actions (8) StartSession StopSession JoinSession ControlExperiment ControlInstrument ViewExperiment ViewArchive AdminTask
Roles (4) Analyst Customer Guest Administrator (CertifiedAnalyst)
Naming convention Resource - “http://resources.collaboratory.nl/Phillips_XPS1” Subject – “WHO740@users.collaboratory.nl” Roles - “role“ or “role@JobID”
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_19
AAA Policy and XACML Policy formats
PolicySet
Policy{Rules}
Target{S, R, A, (E)}
RBAC/XACML Policy
Policy{Rules}
…
Subject
Rules
Resource/Environment
CNL AAA Policy
Policy Target{S, R, A, (E)}
XACML Policy
Rule CombinationAlgorithm
Rule ID#1
Rule Target{S, R, A}
Condition
Match List
AttrDesignat
Rule ID#n
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_20
Oткрытые системы для AuthN/AuthZ
Разработаны в рамках проектов Internet2, FP5/FP6 и национальных научных сетей Internet2 проекты
Shibboleth - http://shibboleth.internet2.edu/ TERENA AAI (Authentication, Authorisation Initiative) и
ассоциированные проекты - http://www.terena.nl/tf-emc2/ A-Select - http://a-select.surfnet.nl/ PAPI - http://www.rediris.es/app/papi/index.en.html PERMIS - http://www.permis.org/ GEANT JRA5 AAI Framework - http://www.geant2.net/
Globus Toolkit 4.0 AuthZ Framework - GAAA_tk and GAAAPI (Generic AuthN, AuthZ API)
GAAA_tk - http://www.science.uva.nl/research/air/projects/aaa/ GAAAPI - http://staff.science.uva.nl/~demch/projects/aaauthreach/
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_21
Обсуждение и вопросы?
Обговорення і питання?
Discussion and Questions?
Bespreking and Vragen?
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_22
Дополнительная информация
Примеры AuthZ tickets and tokens Управление сессией авторизации Примеры политики в формате AAA и XACML GT4 Authorisation Framework
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_23
Модель контроля доступа в СОУ - Обмен AuthzTicket и AuthzToken
AuthN
Zone R1 Zone R0 Zone RN Zone RA Zone RAA
Resource IF/Agent Resource Manager
Resource (Local File System)
Internet/Network Access
Site AuthN (Identity/Attributes)
Site AuthZ (Policy Enforcement)
Resource/Service Site
UserDB
Requestor (User) System
PAP
AuthZ
PEP
PDP
Resource IF/Agent (SRM)
(Access Control
List)
Resource/ Service (DSE)
FW Appl Srvr/
Contnr
Data
Local FileSyst
UserDB
Attrib
PAP
SrvReq AzTickt
SrvResp AzTickt
IdentP TA/BA
AttrA
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_24
Mapping between CNLAuthzTicket, XACML Request/Response and SAML2.0 Authorization Assertion
SAML 2.0 vs SAML 1.1
• Better security features
• Issuer and Subject are top level elements
• Encrypted elements for Subject, Attributes, Evidence
• Special profile for XACML
General problems for AuthZ
• Attributes can be placed only as deep as 5 level down: Assert/AzStm/Evid/AttrAsrt/Attr/AttrValue
• Ambiguous location for PolicyURIs and SessionID
• SAML1.1 ConfirmationData element is extensible type – compatibility problems
PolicyRef
XACMLResponse
Result
ResourceID
Result
Decision
Status
Status/Msg
StatusDetail
Obligations
{Obligation}
{Resource}
ResContent
{ResAttribs}
XACMLRequest
Action
{ActionAttrs}
{Subject}
{Roles}
JobID
AuthnToken
SubjectID
Environment
{EnvirAttrs}
Subject
{Roles}
JobID
AuthnToken
SubjectID
Resource
ResourceID
Action
{Actions}
CNLAuthzTicket
Obligations
{Obligation}
Issuer
PolicyURIs
Decision
ResourceID
Subject
SubjConfirm
SubjNameID
Decision
AuthnToken
Evidence
AttrAssertion}
{Assertion}
SAML11AuthzStatm
Action
{ActionID}
Resource
Issuer
Subject
SubjConfirm
SubjNameID
SAML20AuthzAssertion
AuthnToken
Evidence
AttrAssertion}
{Assertions}
SAMLAuthzStatm
Action
{ActionID}
ResourceID
Decision
Advice
{Assertions}
OtherInfo
Conditions
AudienceRstr
{Condition}
Proxy/1Time
ValidityTime ValidityTime
SessionID
AuthnToken
Validity
ValidityTime ValidityTime
CommunRestr
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_25
Using SAML 1.1/2.0 for AuthzTicket expression
SAML 2.0 vs SAML 1.1 Better security features Issuer and Subject are top level elements Encrypted elements for Subject, Attributes, Evidence Special profile for XACMLAuthzStatement
General problems for Authorisation assertion Attributes can be placed only as deep as 5 level down:
Assertion/AuthzStatement/Evidence/AttributeAssertion/Attribute/AttributeValue Ambiguous location for PolicyURIs and SessionID Ambiguous mapping for XACML/Obligation to SAML/(Condition or Advice) SAML1.1 ConfirmationData element is an extensible type – compatibility problems XACML Obligation element
Can be mapped to SAML Condition element or SAML Advice element
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_26
CNLAuthzTicket example – 1011 bytes
<cnl:CNLAuthzTicket xmlns:AAA="http://www.AAAarch.org/ns/AAA_BoD" xmlns:cnl="http://www.aaauthreach.org/ns/#CNL" Issuer="http://www.AAAarch.org/servers/AAA" PolicyURIs="CNLpolicy01" SessionIndex="JobXPS1-2005-001" TicketID="c24d2c7dba476041b7853e63689193ad"><!-- Mandatory elements --><cnl:Decision ResourceID="http://resources.collaboratory.nl/Philips_XPS1">Permit</cnl:Decision><cnl:Validity NotBefore="2005-02-13T01:26:42.699Z" NotOnOrAfter="2005-02-14T01:26:42.699Z"/><!-- Additional elements --><cnl:Subject Id="subject">
<cnl:SubjectID>WHO740@users.collaboratory.nl</cnl:SubjectID><cnl:SubjectConfirmationData>SeDFGVHYTY83ZXxEdsweOP8Iok</
cnl:SubjectConfirmationData><cnl:JobID>CNL2-XPS1-2005-02-02</cnl:JobID><cnl:Role>analyst@JobID;expert@JobID</cnl:Role>
</cnl:Subject><cnl:Resource>http://resources.collaboratory.nl/Philips_XPS1</cnl:Resource><cnl:Actions>
<cnl:Action>cnl:actions:CtrlInstr</cnl:Action><cnl:Action>cnl:actions:CtrlExper</cnl:Action>
</cnl:Actions><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ... </ds:Signature></cnl:CNLAuthzTicket>
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_27
CNLAuthzTicket XML Signature element – 957 bytes (total signed ticket 1968 bytes)
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>nrNrZZDiw/2aDnKXFEHSeoixnsc=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>0IZt9WsJT6an+tIxhhTPtiztDpZ+iynx7K7X2Cxd2iBwCUTQ0n61Szv81DKllWsq75IsHfusnm56zT3fhKU1zEUsob7p6oMLM7hb42+vjfvNeJu2roknhIDzruMrr6hMDsIfaotURepu7QCT0sADm9IfX89Et55EkSE9oE9qBD8= </ds:SignatureValue>
<ds:KeyInfo> << ... snip ... >> </ds:KeyInfo>
</ds:Signature>
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_28
RSA <ds:KeyInfo> element – 1010 bytes (total signed ticket with KeyInfo - 3078 bytes)
<ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>
MIICADCCAWkCBEGX/FYwDQYJKoZIhvcNAQEEBQAwRzELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEENvbGxhYm9yYXRvcnkubmwxHTAbBgNVBAMTFEFBQXV0aHJlYWNoIFNlY3VyaXR5MB4XDTA0MTExNTAwNDYxNFoXDTA1MDIxMzAwNDYxNFowRzELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEENvbGxhYm9yYXRvcnkubmwxHTAbBgNVBAMTFEFBQXV0aHJlYWNoIFNlY3VyaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdDrBhVmr1nD9eqi7U7m4yjIRxfvjAKv33EpuajvTKHpKUgLjbcBC3jNJ4F7a0GiXQcVbuF/aDx/ydIUJXQktvFxK0Sm77WVeSel0cLc1hYfUSAg4mudtfsB7rAj+CzNnVdr6RLFpS9YFElv5ptGaNGSbwHjU02HnArEGL2K+0AwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBADHKqkOW4mP9DvOibMvf4oqXTth7yv8o3Zol7+nqlB9Tqf/bVNLMk8vNo5fWRHbpnHIFFgTk31nrJf8kEZEofvwAeW9s1gQtYfs1oxvsMPKHxFjJDiZlLkHRViJl/slz5a7pkLqIXLRsPFRziTksemRXB/fT8KDzM14pzQZgHicO
</ds:X509Certificate> </ds:X509Data> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>
3Q6wYVZq9Zw/Xqou1O5uMoyEcX74wCr99xKbmo70yh6SlIC423AQt4zSeBe2tBol0HFW7hf2g8f8nSFCV0JLbxcStEpu+1lXknpdHC3NYWH1EgIOJrnbX7Ae6wI/gszZ1Xa+kSxaUvWBRJb+abRmjRkm8B41NNh5wKxBi9ivtAM=
</ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue></ds:KeyInfo>
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_29
CNLAuthzToken example – 293 bytes
<cnl:CNLAuthzToken TokenID="ed9d969e1262ba1d3a7f33dbd670dd94">
<cnl:TokenValue>
0IZt9WsJT6an+tIxhhTPtiztDpZ+iynx7K7X2Cxd2iBwCUTQ0n61Szv81DKllWsq75IsHfusnm56
zT3fhKU1zEUsob7p6oMLM7hb42+vjfvNeJu2roknhIDzruMrr6hMDsIfaotURepu7QCT0sADm9If
X89Et55EkSE9oE9qBD8=
</cnl:TokenValue>
</cnl:CNLAuthzToken>
CNLAuthzToken is constructed of the CNLAuthzTicket TicketID and SignatureValue CNLAuthzToken use suggests caching CNLAuthzTicket’s
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_30
CNLSAMLAuthzTicket example – 2254 bytes
<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" AssertionID="c236b047d62db5cecec6b240996bcb90" IssueInstant="2005-02-15T14:53:23.542Z" Issuer="cnl:subject:CNLAAAauthority" Version="1.1">
<Conditions NotBefore="2005-02-16T14:32:12.506Z" NotOnOrAfter="2005-02-17T14:32:12.506Z"><Condition xsi:type="typens:cnl:session-id">JobXPS1-2005-001</Condition><Condition xsi:type="typens:cnl:policy-uri">CNLpolicy01</Condition>
</Conditions> <AuthorizationDecisionStatement Decision="Permit" Resource="http://resources.collaboratory.nl/Philips_XPS1"> <Action Namespace="urn:oasis:names:tc:SAML:1.0:action:cnl:action">cnl:actions:CtrlInstr</Action> <Action Namespace="urn:oasis:names:tc:SAML:1.0:action:cnl:action">cnl:actions:CtrlExper</Action> <Evidence> <Assertion AssertionID="f3a7ea74e515ffe776b10a7eef0119d7" IssueInstant="2005-02-15T14:53:23.542Z" Issuer="cnl:subject:CNLAAAauthority"
MajorVersion="1" MinorVersion="1"> <Conditions NotBefore="2005-02-15T14:53:11.745Z" NotOnOrAfter="2005-02-16T14:53:11.745Z"/> <AttributeStatement> <Subject> <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
NameQualifier="cnl:subject">WHO740@users.collaboratory.nl</NameIdentifier> <SubjectConfirmation>
<ConfirmationMethod>signed-subject-id</ConfirmationMethod> === moved to attr in SAML 2.0<ConfirmationData>
PBLIR0aZRtdZmq979lj8eDpJ5VT6BxxWBtSApC5BPnIsfHRUcOOpWQowXBw2TmOZdJGNzFWhMinzXU3/wSdLjv+siO2JGfyZ7U9eqkM0GqY8VizMl5uRuUAsrr7AIHv9/DP1ksJMNDZ5DnGosMc+ZyqnKogfMqhK+DKqPwfHF6U=</ConfirmationData>
</SubjectConfirmation> </Subject> <Attribute xmlns:typens="urn:cnl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
AttributeName="AttributeSubject" AttributeNamespace="urn:cnl">
<AttributeValue xsi:type="typens:cnl:job-id">CNL2-XPS1-2005-02-02</AttributeValue> === level 5 of element <AttributeValue xsi:type="typens:cnl:role">analyst@JobID;expert@JobID</AttributeValue> </Attribute> </AttributeStatement> </Assertion> </Evidence> </AuthorizationDecisionStatement></Assertion>
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_31
CNLAuthnTicket example – 1752 bytes
<cnl:CNLAuthnTicket xmlns:AAA="http://www.AAAarch.org/ns/AAA_BoD" xmlns:cnl="http://www.aaauthreach.org/ns/#CNL" Issuer="http://www.AAAarch.org/servers/AAA" TicketID="f35585dfb51edec48de0c7eadb11c17e">
<!-- Mandatory elements -->
<cnl:Validity NotBefore="2005-02-15T14:33:10.548Z" NotOnOrAfter="2005-02-16T14:33:10.548Z"/>
<cnl:Subject Id="subject">
<cnl:SubjectID>WHO740@users.collaboratory.nl</cnl:SubjectID>
<cnl:SubjectConfirmationData>
0+qQNAVuZW4txMi8DH6DFy7eLMGxSfKDJY6ZnY4UW5Dt0JFtatlEprUtgnjCkzrJUMvWk9qtUzna
sDdUG+P4ZY7dgab+PHiU91ClusZbztu/ZIjNqCnw5su1BQLTumC8ZTtYKKJi4WWs+bMMbP8mFNQm
+M7F4bJIPBfLcxf0bk4=
</cnl:SubjectConfirmationData>
<!--Optional elements -->
<cnl:SubjectAttribute attrname="urn:cnl:subject:attribute:job-id">
CNL2-XPS1-2005-02-02
</cnl:SubjectAttribute>
<cnl:SubjectAttribute attrname="urn:cnl:subject:attribute:role">
analyst@JobID;expert@JobID
</cnl:SubjectAttribute>
</cnl:Subject>
</cnl:CNLAuthnTicket>
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_32
CNLAuthnToken signed/encrypted – 401/269 bytes
<cnl:CNLAuthnToken xmlns:cnl="http://www.aaauthreach.org/ns/#CNL" TokenID="f35585dfb51edec48de0c7eadb11c17e">
<cnl:SubjectID>WHO740@users.collaboratory.nl</cnl:SubjectID>
<cnl:TokenValue>
0+qQNAVuZW4txMi8DH6DFy7eLMGxSfKDJY6ZnY4UW5Dt0JFtatlEprUtgnjCkzrJUMvWk9qtUzna
sDdUG+P4ZY7dgab+PHiU91ClusZbztu/ZIjNqCnw5su1BQLTumC8ZTtYKKJi4WWs+bMMbP8mFNQm
+M7F4bJIPBfLcxf0bk4=</cnl:TokenValue>
</cnl:CNLAuthnToken>
CNLAuthnToken is constructed of the CNLAuthnTicket TicketID and SubjectConfirmationData which is encrypted SubjectID value
CNLAuthzToken must be self-sufficient and doesn’t require caching CNLAuthnTicket’s
<cnl:CNLAuthnToken xmlns:cnl="http://www.aaauthreach.org/ns/#CNL" TokenID="a392a20157698d201d77b2c6e8e444ef">
<cnl:SubjectID>WHO740@users.collaboratory.nl</cnl:SubjectID>
<cnl:TokenValue>qij9zJgKZp9RiJxYN1QJAN0vhjLJSMGVLD/doQtmCsk=</cnl:TokenValue>
</cnl:CNLAuthnToken>
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_33
Session management in CNL2 AuthZ system
Maintaining session is a part of generic RBAC functionality Session can be started only by authorised Subject/Role
Session can be joined by other less privileged users
SessionID is included into AuthzTicket together with other decision attributes Signed AuthzTicket is cached by PEP or PDP
If session is terminated, cached AuthzTicket is deleted Note: AuthzTicket revocation should be done globally for the AuthZ trust domain
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_34
Tickets/Tokens handling in AuthZ system
AuthzTicket is issued by PDP and may be issued by PEP AuthzTicket must be signed AuthzTicket contains all necessary information to make local PEP-Triage Request verification When using AuthzTokens, AuthzTickets must be cached; Resolution mechanism from token to
ticket must be provided
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_35
AAA Policy and XACML Policy formats
PolicySet
Policy{Rules}
Target{S, R, A, (E)}
RBAC/XACML Policy
Policy{Rules}
…
Subject
Rules
Resource/Environment
CNL AAA Policy
Policy Target{S, R, A, (E)}
XACML Policy
Rule CombinationAlgorithm
Rule ID#1
Rule Target{S, R, A}
Condition
Match List
AttrDesignat
Rule ID#n
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_36
CNL2 AuthZ policy: RBAC using AAA format
Policy generation conventions Subject validation Resource and Environment checking Access rules evaluation
Rules are expressed as permissions to perform an action against Subject role
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_37
CNL2 AuthZ policy: RBAC using XACML format
Policy generation conventions Policy Target is defined for the Resource and may include Environment
checking Policy combination algorithm is “ordered-deny-override” or “deny-override” Rule Target is defined for the Action
Rule’s Condition provides matching of roles which are allowed to perform the Action
Access rules evaluation Rules are expressed as permissions to perform an action against Subject role Rules effect is “Permit”
Subject validation – is not supported by current XACML functionality TODO: add Function or do validation at/by PEP or Context Handler
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_38
GT4 AuthZ framework: Implementation details
Source code treeorg.globus.wsrf.impl.security.authorization
Still using grid-map file as a major option Special interface for PDP and PIP to interact with Interceptor Very simple example provisioning for XACML
Simple policy format
June 16, 2005 RELARN2005 Access Control in Web Services and Grid Slide_39
GT4 AuthZ framework: Multiple configured PDPs
GT4 implementation uses Interceptor concept
• Originated from POSIX AuthZ f/w
• Supported by Axis Handlers• PEP function is (virtually)
eliminated• “Deny-override” vs “Permit-
override” combination• Configured by Interceptor
PDP/PIP call-out list• PDP are called directly or
via PIP