Обеспечение гибкой системы контроля доступа в...

Обеспечение гибкой системы контроля доступа

в Веб-сервисах и Грид-системах

RELARN2005 16 июня, 2005

Yuri Demchenko <[email protected]>

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)

Отношения доверия в распределенной инфраструкутре контроля доступа Политика доступа и существующие форматы

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


AuthN/AuthZ в научных и образовательных сетях

Доступ к многосайтовым Веб/Интернет ресурсам Система единого доступа (SSO – Single Sign On) и системы управления

идентификацией (IdM - Identity management)

Межуниверситетские ресурсы и доступ к внешним ресурсам или предоставление доступа для внешних пользователей

Распределенные университетские кампусы и дистанционное обучение Грид-центры и Грид-приложения

Различные административные домены и домены безопасности Продолжительные (транзитивные) задачи Динамические ресурсы и виртуальные ассоциации ресурсов и пользователей


Современная архитектура сервисов AuthN и AuthZ

Проблемы Множество логинов/паролей – на каждый ресурс/сайт Ограничение одним доменом безопасности или множество сертификатов

открытых ключей Сложность частичной динамической делегации полномочий

Требования к современной архитектуре AuthN/Z Разделение сервисов аутентификации (AuthN) и авторизации (AuthZ)

Аутентификация в «домашней» организации Авторизация ресурсом

Конфиденциальность, приватность и анонимность Контроль доступа к атрибутам на основе политики

Управление доступом на основе ролей и политики безопасности (RBAC) и инфраструктуры управления привелегиями (PMI)


Новая парадигма безопасности приложений

Традиционные модели безопасности (ISO7498-2) и POSIX: Host-to-host или point-to-point security Ориентированная на архитектуру Client/Server Основанные на соединение (connection-oriented) и нет (connectionless) В общем случае единый доверительный домен (на основе PKI)

Безопасность приложений основе XML Безопасность между конечными точками приложений (End-to-end) Ориентированная на документ (или семантический обьект)

Квитанции, мандаты и маркеры безопасности могут быть ассоциированы с документом или сообщением или их частью

Потенциально работает между различными доменами административными и безопасности

Позволяет создавать динамические и виртуальные ассоциации


Модель контроля доступа в СОУ

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


Архитектура безопасности Грид и Веб-сервисов

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


Требования к Системе Контроля Доступа на основе Политики (СКДП)

Выражение политики для множества доменов и организаций (Multidomain and inter-institutional)

Множество форматов описания политики (multiple policy format) Комбинирование и агрегирование множества политик (policy combination

and aggregation) Множество центров удостоверения политики (multiple policy authority) Управление политикой независимо от управления основными функциями

(independent policy administration) Динамическое приложение/ассоциирование политики с основными

функциями (dynamic policy association)


СКДП и управление доступом на основе ролей

RBAC – Role Based Access Control Роль описывает функцию Права/привилегии определяют доступ к ресурсу в определенном режиме Правила доступа описаны в форме политики доступа

Возможно комбирирование множественных политик

Преимущества RBAC Легко управлять и контролировать Раздельное назначение ролей-пользователей и ролей-привилегий Поддерживает принцип минимально необходимых привилегий Масштабируемость, наследование и агрегирование привилегий/прав Возможность делегирования

ISO STD on PMI (Privilege Management Infrastructure) как основа для RBAC Строится на основе X.509 Сертификатов Атрибутов (AC – Attribute Certificate)

АС позволяет связать идентификатор пользователя с ролями и роли с привилегиями


(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

•Политика доступа определяется ресурсом


(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


Служба авторизации сайта на основе 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


Служба авторизации сайта на основе комбинированной модели 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


СКДП: Вопросы внедрения

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-билеты


Что нужно сделать до установки СКДП

Исходные технические правила и соглашения Распределение ключей и установление доверительный отношений

(Key distribution and trust establishing) В настоящее время в процессе поиска простой и эффективной модели

Формат для описания политики, включая семантику и пространства имен для субьекта, атрибутов и ролей, акций

Совместимость с существующими форматами, например SAML, XACML Практически, формат политики может определяться используемым/наличным

PDP

Формат для мандатов/сертификатов безопасности Standard vs proprietary

Протоколы и форматы сообщений SOAP + XACML Request/Response SOAP + SAMLP + XACML


Отношения доверия в AuthN/Z системах

Получение необходимых прав доступа для выполнения запрашиваемой акции:

User => AuthN(HomeOrg.IdentP, (UserDB | TA)) => => AuthZ(AttrA.roles, Policy.permissions) =>

=> Resource.permissions

AuthN (SSO)

AttrA





Site AuthN Identity/Attributes

(TA/BA/VO Contx)



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:


Пример использования: Система контроля доступа в демо-системе 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


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 – “[email protected]” Roles - “role“ or “role@JobID”


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


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/


Обсуждение и вопросы?

Обговорення і питання?

Discussion and Questions?

Bespreking and Vragen?


Дополнительная информация

Примеры AuthZ tickets and tokens Управление сессией авторизации Примеры политики в формате AAA и XACML GT4 Authorisation Framework


Модель контроля доступа в СОУ - Обмен AuthzTicket и AuthzToken

AuthN





Site AuthN (Identity/Attributes)



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


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


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

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"><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"/><cnl:Subject Id="subject">

<cnl:SubjectID>[email protected]</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>


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>


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>


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


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">[email protected]</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>

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">



<cnl:Validity NotBefore="2005-02-15T14:33:10.548Z" NotOnOrAfter="2005-02-16T14:33:10.548Z"/>

<cnl:Subject Id="subject">

<cnl:SubjectID>[email protected]</cnl:SubjectID>

<cnl:SubjectConfirmationData>

0+qQNAVuZW4txMi8DH6DFy7eLMGxSfKDJY6ZnY4UW5Dt0JFtatlEprUtgnjCkzrJUMvWk9qtUzna

sDdUG+P4ZY7dgab+PHiU91ClusZbztu/ZIjNqCnw5su1BQLTumC8ZTtYKKJi4WWs+bMMbP8mFNQm

+M7F4bJIPBfLcxf0bk4=

</cnl:SubjectConfirmationData>



<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>


CNLAuthnToken signed/encrypted – 401/269 bytes

<cnl:CNLAuthnToken xmlns:cnl="http://www.aaauthreach.org/ns/#CNL" TokenID="f35585dfb51edec48de0c7eadb11c17e">


<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:TokenValue>qij9zJgKZp9RiJxYN1QJAN0vhjLJSMGVLD/doQtmCsk=</cnl:TokenValue>

</cnl:CNLAuthnToken>


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


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


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


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


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


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


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

Обеспечение гибкой системы контроля доступа в...

Documents

Transcript of Обеспечение гибкой системы контроля доступа в...