cnl:TokenValue - UAZone.org Development Server

Обеспечение гибкой системы
контроля доступа
в Веб-сервисах и Грид-системах
RELARN2005
16 июня, 2005
Yuri Demchenko <demch@science.uva.nl>
AIRG, University of Amsterdam
Содержание
 Услуги Аутентификации (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_2
AuthN/AuthZ в научных и образовательных сетях
 Доступ к многосайтовым Веб/Интернет ресурсам

Система единого доступа (SSO – Single Sign On) и системы управления
идентификацией (IdM - Identity management)
 Межуниверситетские ресурсы и доступ к внешним ресурсам или
предоставление доступа для внешних пользователей
 Распределенные университетские кампусы и дистанционное обучение
 Грид-центры и Грид-приложения
Различные административные домены и домены безопасности
 Продолжительные (транзитивные) задачи
 Динамические ресурсы и виртуальные ассоциации ресурсов и пользователей

June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_3
Современная архитектура сервисов AuthN и AuthZ
Проблемы
 Множество логинов/паролей – на каждый ресурс/сайт
 Ограничение одним доменом безопасности или множество сертификатов
открытых ключей
 Сложность частичной динамической делегации полномочий
Требования к современной архитектуре AuthN/Z
 Разделение сервисов аутентификации (AuthN) и авторизации (AuthZ)
Аутентификация в «домашней» организации
 Авторизация ресурсом

 Конфиденциальность, приватность и анонимность

Контроль доступа к атрибутам на основе политики
 Управление доступом на основе ролей и политики безопасности (RBAC) и
инфраструктуры управления привелегиями (PMI)
June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_4
Новая парадигма безопасности приложений
Традиционные модели безопасности (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_5
Модель контроля доступа в СОУ
User HomeOrg
Zone RN
Zone RA
IdentP
TA/BA
Req/User
Client
Zone RAA
Zone R1
IdentP
TA/BA
FW
Appl
Srvr/
Contnr
Resource/Service Site
AuthN
(SSO)
AuthZ
(Policy
Enforcemnt)
Resource
IF/Agent
(IntFW)
Creds
PEP
ACL
(ResAuthZ)
Attrib
PDP
AttrA
PolicyA
June 16, 2005 RELARN2005
Site AuthN
Identity/Attributes
(TA/BA/VO Contx)
Resource/
Service
PolicyA
Data
Local
FileSyst
UserDB
Internet/Network
Access
Zone R0
Site AuthZ
(Policy Enforcement)
Access Control in Web Services and Grid
Resource IF/Agent
Resource Manager
Resource
(Local File System)
Slide_6
Архитектура безопасности Грид и Веб-сервисов
Site Security
Services
Intrusion
Detection and
Incident
Response
Services/Operational Security
Authentication
and Identity
Management
Authorisation
(Access Control)
Secure
Logging
Policy
Management
(AuthZ,
Privacy,
Trust,
Federation)
Secure Context
Management
Auditing and
Notarisation
Policy Expression and Exchange
Identity/
Federation Policy
Authorisation
Policy
Trust
Management
Policy
Confidentiality
and
Privacy Policy
Messaging Security: SOAP/WS- Security
User
Management
Key
Management
June 16, 2005 RELARN2005
Communication/Transport Security: SSL/TLS, VPN, IPSec, Firewall, etc.
Access Control in Web Services and Grid
Slide_7
Требования к Системе Контроля Доступа на
основе Политики (СКДП)
 Выражение политики для множества доменов и организаций (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_8
СКДП и управление доступом на основе ролей
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_9
(1) Generic AAA Architecture by AIRG (UvA)
Решение о доступе на основе
политики
Request/Response
Request/Response
Request/Response
Generic AAA
RBE
Policy
Policy
Policy
•Политика доступа
определяется ресурсом
June 16, 2005 RELARN2005
ASM
ASM
ASM
 Req {AuthNtoken, Attr/Roles,
PolicyTypeId, ConditionExt}
 RBE (Req + Policy) =>
=> Decision {ResponseAAA,
ActionExt}
 ActionExt = {ReqAAAExt,
ASMcontrol}
 ResponseAAA =
{AckAAA/RejectAAA, ReqAttr,
ReqAuthN, BindAAA (Resource,
Id/Attr)}
•Преобразование logDecision => Action
•Преобразование State => LogCondition
Access Control in Web Services and Grid
Slide_10
(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_11
Служба авторизации сайта на основе RBAC и
комбинированная модель pull-push
Site Services/Resources
AzTicket
Srv Req
Requestor
Srv Deliv
AzTicket
User
login
IF
PEP1
PEP2
Resource/
Service
AzTicket
AuthN Req
PDP
types
call
An
Req/
Resp
AuthN
and
IdentMngt
AzReq
Decision
AuthN Req/Valid
Ext
AuthZ
IF
Az
Tickt
PDP
(local)
PDP
PDP
PDP
(Master)
PDP
(Secondary)
chain
PDP
(Secondary)
chain
Важные вопросы:
• Комбинирование
множества политик
• Последовательность
PEP (chaining) и
рекурентность PDP
(nesting)
• Множество доменов
доверия и
административных
Extern
(Multiple domains)
PDP
chain
AzTicket
Attribute
Authority
PAP
(local)
Attr Req/Valid
PAP
June 16, 2005 RELARN2005
PAP
Access Control in Web Services and Grid
Slide_12
Служба авторизации сайта на основе комбинированной
модели agent-push для сложных ресурсов
Site Services/Resources
SrvDeliv
SrvDeliv
Resource/
Service
AzTicket
PEP1
(ASM)
Srv Req
Srv Req
Resource/
Service
PEP2
(ASM)
Srv Req
AzTicket
AuthN Req/Valid
AuthNReq
AuthN
and
IdentMngt
AuthN Req
Srv Req
Srv Req
AzTicket
AzTicket
Srv Req
Requestor
AzTicket
Attribute
Authority
User
login/
AuthZ
IF
PDP
(Driving)
Recursive
PDP
flow/chain
Recurs
PDP
call
Attr Req/Valid
PAP
June 16, 2005 RELARN2005
PDP2
(Driving)
Важные вопросы:
• Ресурсы, состоящие из
множества
компонентов и
принадлежащих
множеству доменов
(Multi-component and
multidomain resources)
• Включение политики в
запрос и/или
использование
квитанций (Policy push
and/or token based
access control)
PAP
Access Control in Web Services and Grid
Slide_13
СКДП: Вопросы внедрения



PDP и PAP должны иметь общее пространство имен (namespace)
Запрос (request message) должен содержать ссылку на Политику и соответствующий
PAP или эта информация должна быть известна PEP и PDP заранее
Каждый PEP в цепочке приложения политики (policy enforcement) должен
обрабатывать запрос полностью, обращаясь к соответствующему главному PDP
(master PDP).


Только один PDP должен формировать окончательное решение по исходному запросу



PEP не должен производить комбинацию множества решений нескольких 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_14
Что нужно сделать до установки СКДП
Исходные технические правила и соглашения
 Распределение ключей и установление доверительный отношений
(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_15
Отношения доверия в AuthN/Z системах
User HomeOrg
Zone RN
Zone RA
IdentP
TA/BA
Req/User
Client
Zone RAA
Zone R1
IdentP
TA/BA
FW
Appl
Srvr/
Contnr
Resource/Service Site
AuthN
(SSO)
AuthZ
(Policy
Enforcemnt)
Resource
IF/Agent
(IntFW)
Creds
PEP
ACL
(ResAuthZ)
Attrib
PDP
AttrA
PolicyA
Site AuthN
Identity/Attributes
(TA/BA/VO Contx)
Resource/
Service
PolicyA
Data
Local
FileSyst
UserDB
Internet/Network
Access
Zone R0
Site AuthZ
(Policy Enforcement)
Resource IF/Agent
Resource Manager
Resource
(Local File System)
Последовательность
доверия/мандатов
делегирования для
основных модулей
User.Cred =>
=> (HO.user[TA] | UserD)
=> User.roles(AA)
=> Role.permissions(PA)
=> Resource. permissions
Trust/credentials chain and
delegation between major
modules:
Получение необходимых прав доступа для выполнения запрашиваемой акции:
User => AuthN(HomeOrg.IdentP, (UserDB | TA)) =>
=> AuthZ(AttrA.roles, Policy.permissions) =>
=> Resource.permissions
June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_16
Пример использования: Система контроля доступа в демосистеме Collaboratory.nl (CNL2)
3. JNLP
Remote CNL
Instrument
Surabaya
5,10 startSession()
11,14 goLeft()
Web
Client
2. JNLP
1. Login
CHEF
Job Mgt.
Instrument
Controller
4. getJobInfo()
6,9 startSession()
12,13 checkAuthZStatus()
gAAA Server
7,8 requestDecision()
PDP
Note: we assume SSL TCP connections all over.
June 16, 2005 RELARN2005
PEP
JNLP – Java Network
Launch Protocol
CHEF – Collaborative
tool
Surabaya – Collaborative
Workspace
environment
Locations/trust
domains
Access Control in Web Services and Grid
Slide_17
CNL2 AuthZ policy: Resource, Actions, Subject,
Roles
Actions (8)








Roles (4)





StartSession
StopSession
JoinSession
ControlExperiment
ControlInstrument
ViewExperiment
ViewArchive
AdminTask
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_18
AAA Policy and XACML Policy formats
CNL AAA Policy
Subject
Resource/
Environment
RBAC/XACML
Policy
Target
{S, R, A, (E)}
XACML Policy
Rule Combination
Algorithm
Policy Target
{S, R, A, (E)}
PolicySet
Rule ID#1
Rules
Policy
{Rules}
…
Rule Target
{S, R, A}
Condition
AttrDesignat
Policy
{Rules}
Match List
Rule ID#n
June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_19
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_20
Обсуждение и вопросы?
Обговорення і питання?
Discussion and Questions?
Bespreking and Vragen?
June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_21
Дополнительная информация




Примеры AuthZ tickets and tokens
Управление сессией авторизации
Примеры политики в формате AAA и XACML
GT4 Authorisation Framework
June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_22
Модель контроля доступа в СОУ - Обмен
AuthzTicket и AuthzToken
Zone RN
AzTickt
Zone RA
FW
Appl
Srvr/
Contnr
AuthZ
User
DB
PEP
AttrA
Zone R0
Resource/Service Site
AuthN
Attrib
SrvResp
Zone R1
IdentP
TA/BA
SrvReq
Requestor
(User)
System
Zone RAA
PDP
PAP
Resource
IF/Agent
(SRM)
Resource/
Service
(DSE)
(Access
Control
List)
PAP
Data
AzTickt
Local
FileSyst
UserDB
Internet/Network
Access
June 16, 2005 RELARN2005
Site AuthN
(Identity/Attributes)
Site AuthZ
(Policy Enforcement)
Access Control in Web Services and Grid
Resource IF/Agent
Resource Manager
Resource
(Local File System)
Slide_23
Mapping between CNLAuthzTicket, XACML Request/Response and
SAML2.0 Authorization Assertion
CNLAuthzTicket
XACMLRequest
PolicyRef
{Subject}
SubjectID
AuthnToken
JobID
SessionID
Issuer
Issuer
PolicyURIs
Subject
Decision
SubjNameID
ResourceID
{Roles}
{Resource}
ResContent
{ResAttribs}
Action
{ActionAttrs
}
Environment
{EnvirAttrs}
Result
ResourceID
ValidityTime
ValidityTime
ValidityTime
ValidityTime
AuthnToken
CommunRestr
SubjectID
AuthnToken
JobID
Status
Status/Msg
StatusDetail
Obligations
{Condition}
Advice
SAML11AuthzStat
{Assertions}
m
Decision
OtherInfo
Resource
SAMLAuthzStatm
Subject
Resource
ResourceID
Action
Obligations
{Obligation}
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
AudienceRstr
Proxy/1Time
Subject
{Actions}
Decision
SubjConfirm
Conditions
Validity
{Roles}
XACMLResponse
SAML20AuthzAssertion
Decision
SubjNameID
ResourceID
SubjConfirm
Action
Action
{ActionID}
{ActionID}
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
Evidence
Evidence
AttrAssertion
AttrAssertion
}
AuthnToken
{Assertion}
}
{Assertions}
AuthnToken
{Obligation}
June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_24
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_25
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-0214T01: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_26
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+iynx7K7X2Cxd2iBwCUTQ0n61Szv81DKllWsq75IsHfusnm56
zT3fhKU1zEUsob7p6oMLM7hb42+vjfvNeJu2roknhIDzruMrr6hMDsIfaotURepu7QCT0sADm9If
X89Et55EkSE9oE9qBD8=
</ds:SignatureValue>
<ds:KeyInfo> << ... snip ... >> </ds:KeyInfo>
</ds:Signature>
June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_27
RSA <ds:KeyInfo> element – 1010 bytes
(total signed ticket with KeyInfo - 3078 bytes)
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICADCCAWkCBEGX/FYwDQYJKoZIhvcNAQEEBQAwRzELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEENv
bGxhYm9yYXRvcnkubmwxHTAbBgNVBAMTFEFBQXV0aHJlYWNoIFNlY3VyaXR5MB4XDTA0MTExNTAw
NDYxNFoXDTA1MDIxMzAwNDYxNFowRzELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEENvbGxhYm9yYXRv
cnkubmwxHTAbBgNVBAMTFEFBQXV0aHJlYWNoIFNlY3VyaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDdDrBhVmr1nD9eqi7U7m4yjIRxfvjAKv33EpuajvTKHpKUgLjbcBC3jNJ4F7a0GiXQ
cVbuF/aDx/ydIUJXQktvFxK0Sm77WVeSel0cLc1hYfUSAg4mudtfsB7rAj+CzNnVdr6RLFpS9YFE
lv5ptGaNGSbwHjU02HnArEGL2K+0AwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBADHKqkOW4mP9DvOi
bMvf4oqXTth7yv8o3Zol7+nqlB9Tqf/bVNLMk8vNo5fWRHbpnHIFFgTk31nrJf8kEZEofvwAeW9s
1gQtYfs1oxvsMPKHxFjJDiZlLkHRViJl/slz5a7pkLqIXLRsPFRziTksemRXB/fT8KDzM14pzQZg
HicO
</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>
3Q6wYVZq9Zw/Xqou1O5uMoyEcX74wCr99xKbmo70yh6SlIC423AQt4zSeBe2tBol0HFW7hf2g8f8
nSFCV0JLbxcStEpu+1lXknpdHC3NYWH1EgIOJrnbX7Ae6wI/gszZ1Xa+kSxaUvWBRJb+abRmjRkm
8B41NNh5wKxBi9ivtAM=
</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_28
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_29
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>
PBLIR0aZRtdZmq979lj8eDpJ5VT6BxxWBtSApC5BPnIsfHRUcOOpWQowXBw2TmOZdJGNzFWhMinz
XU3/wSdLjv+siO2JGfyZ7U9eqkM0GqY8VizMl5uRuUAsrr7AIHv9/DP1ksJMNDZ5DnGosMc+Zyqn
KogfMqhK+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_30
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_31
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_32
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_33
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_34
AAA Policy and XACML Policy formats
CNL AAA Policy
Subject
Resource/
Environment
RBAC/XACML
Policy
Target
{S, R, A, (E)}
XACML Policy
Rule Combination
Algorithm
Policy Target
{S, R, A, (E)}
PolicySet
Rule ID#1
Rules
Policy
{Rules}
…
Rule Target
{S, R, A}
Condition
AttrDesignat
Policy
{Rules}
Match List
Rule ID#n
June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_35
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_36
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_37
GT4 AuthZ framework: Implementation details
 Source code tree
org.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_38
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 “Permitoverride” combination
• Configured by Interceptor
PDP/PIP call-out list
• PDP are called directly or
via PIP
June 16, 2005 RELARN2005
Access Control in Web Services and Grid
Slide_39