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

Зарегистрируйтесь, чтобы просмотреть полный документ!

Обеспечение гибкой системы контроля доступа в Веб-сервисах и Грид-системах RELARN 2005 16 июня, 2005 Yuri Demchenko <demch@science. uva. nl> AIRG, University of Amsterdam June 16, 2005 RELARN 2005 Access Control in Web Services and Grid Slide 2_

Содержание · Услуги Аутентификации (Auth. N) и Авторизации (Auth. Z) в научных и образовательных сетях · Модель безопасности и контроль доступа в системах ориентированных на услуги (СОУ) · Система контроля доступа на основе политики (СКДП) и модель Role Based Access Control (RBAC) u Оптимизированные модели push-pull-agent и использование квитанций/билетов и маркеров авторизации (Auth. Z tickets and tokens) · Отношения доверия в распределенной инфраструкутре контроля доступа · Политика доступа и существующие форматы · Примеры систем распределенной аутентификации и авторизации June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 2

Auth. N/Auth. Z в научных и образовательных сетях · Доступ к многосайтовым Веб/Интернет ресурсам u Система единого доступа (SSO – Single Sign On) и системы управления идентификацией (Id. M - Identity management) · Межуниверситетские ресурсы и доступ к внешним ресурсам или предоставление доступа для внешних пользователей · Распределенные университетские кампусы и дистанционное обучение · Грид-центры и Грид-приложения Различные административные домены и домены безопасности u Продолжительные (транзитивные) задачи u Динамические ресурсы и виртуальные ассоциации ресурсов и пользователей u June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 3

Современная архитектура сервисов Auth. N и Auth. Z Проблемы · Множество логинов/паролей – на каждый ресурс/сайт · Ограничение одним доменом безопасности или множество сертификатов открытых ключей · Сложность частичной динамической делегации полномочий Требования к современной архитектуре Auth. N/Z · Разделение сервисов аутентификации (Auth. N) и авторизации (Auth. Z) Аутентификация в «домашней» организации u Авторизация ресурсом u · Конфиденциальность, приватность и анонимность u Контроль доступа к атрибутам на основе политики · Управление доступом на основе ролей и политики безопасности (RBAC) и инфраструктуры управления привелегиями (PMI) June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 4

Новая парадигма безопасности приложений Традиционные модели безопасности (ISO 7498 -2) и POSIX: · · Host-to-host или point-to-point security Ориентированная на архитектуру Client/Server Основанные на соединение (connection-oriented) и нет (connectionless) В общем случае единый доверительный домен (на основе PKI) Безопасность приложений основе XML · Безопасность между конечными точками приложений (End-to-end) · Ориентированная на документ (или семантический обьект) u Квитанции, мандаты и маркеры безопасности могут быть ассоциированы с документом или сообщением или их частью · Потенциально работает между различными доменами административными и безопасности · Позволяет создавать динамические и виртуальные ассоциации June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 5

Модель контроля доступа в СОУ June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 6

Архитектура безопасности Грид и Веб-сервисов June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 7

Требования к Системе Контроля Доступа на основе Политики (СКДП) · Выражение политики для множества доменов и организаций (Multidomain and inter-institutional) · Множество форматов описания политики (multiple policy format) · Комбинирование и агрегирование множества политик (policy combination and aggregation) · Множество центров удостоверения политики (multiple policy authority) · Управление политикой независимо от управления основными функциями (independent policy administration) · Динамическое приложение/ассоциирование политики с основными функциями (dynamic policy association) June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 8

СКДП и управление доступом на основе ролей RBAC – Role Based Access Control · Роль описывает функцию · Права/привилегии определяют доступ к ресурсу в определенном режиме · Правила доступа описаны в форме политики доступа u Возможно комбирирование множественных политик Преимущества RBAC · · · Легко управлять и контролировать Раздельное назначение ролей-пользователей и ролей-привилегий Поддерживает принцип минимально необходимых привилегий Масштабируемость, наследование и агрегирование привилегий/прав Возможность делегирования ISO STD on PMI (Privilege Management Infrastructure) как основа для RBAC · Строится на основе X. 509 Сертификатов Атрибутов (AC – Attribute Certificate) u АС позволяет связать идентификатор пользователя с ролями и роли с привилегиями June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 9

(1) Generic AAA Architecture by AIRG (Uv. A) Решение о доступе на основе политики Request/Response Generic AAA RBE Policy • Политика доступа определяется ресурсом June 16, 2005 RELARN 2005 ASM ASM · Req {Auth. Ntoken, Attr/Roles, Policy. Type. Id, Condition. Ext} · RBE (Req + Policy) => => Decision {Response. AAA, Action. Ext} · Action. Ext = {Req. AAAExt, ASMcontrol} · Response. AAA = {Ack. AAA/Reject. AAA, Req. Attr, Req. Auth. N, Bind. AAA (Resource, Id/Attr)} • Преобразование log. Decision => Action • Преобразование State => Log. Condition Access Control in Web Services and Grid 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 RELARN 2005 Access Control in Web Services and Grid 11

Служба авторизации сайта на основе RBAC и комбинированная модель pull-push Важные вопросы: • Комбинирование множества политик • Последовательность PEP (chaining) и рекурентность PDP (nesting) • Множество доменов доверия и административных (Multiple domains) June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 12

Служба авторизации сайта на основе комбинированной модели agent-push для сложных ресурсов Важные вопросы: • Ресурсы, состоящие из множества компонентов и принадлежащих множеству доменов (Multi-component and multidomain resources) • Включение политики в запрос и/или использование квитанций (Policy push and/or token based access control) June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 13

СКДП: Вопросы внедрения · · · PDP и PAP должны иметь общее пространство имен (namespace) Запрос (request message) должен содержать ссылку на Политику и соответствующий PAP или эта информация должна быть известна PEP и PDP заранее Каждый PEP в цепочке приложения политики (policy enforcement) должен обрабатывать запрос полностью, обращаясь к соответствующему главному PDP (master PDP). u · Только один PDP должен формировать окончательное решение по исходному запросу u · · PEP не должен производить комбинацию множества решений нескольких PDP Однако, PEP при этом может запрашивать различные типы PDP в зависимости от семантики или пространства имен запроса и используемой политики В случае использования квитанций или билетов (ticket/token) для оптимизации производительности контроля доступа, PEP должен понимать и иметь возможность проверять (validate) Auth. Z-билеты, выданные доверительным PDP (trusted PDP) u При этом Auth. Z-билеты должны иметь ограниченный срок годности и назначение (validity and usage restriction) и содержать информацию о принятом авторизационном решении и о ресурсе Для ускорения процесса последующей проверки и повышения безопасности, PEP может кэшировать Auth. Z-билеты June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 14

Что нужно сделать до установки СКДП Исходные технические правила и соглашения · Распределение ключей и установление доверительный отношений (Key distribution and trust establishing) u В настоящее время в процессе поиска простой и эффективной модели · Формат для описания политики, включая семантику и пространства имен для субьекта, атрибутов и ролей, акций Совместимость с существующими форматами, например SAML, XACML u Практически, формат политики может определяться используемым/наличным PDP u · Формат для мандатов/сертификатов безопасности u Standard vs proprietary · Протоколы и форматы сообщений SOAP + XACML Request/Response u SOAP + SAMLP + XACML u June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 15

Отношения доверия в Auth. N/Z системах Последовательность доверия/мандатов делегирования для основных модулей User. Cred => => (HO. user[TA] | User. D) => User. roles(AA) => Role. permissions(PA) => Resource. permissions Trust/credentials chain and delegation between major modules: Получение необходимых прав доступа для выполнения запрашиваемой акции: User => Auth. N(Home. Org. Ident. P, (User. DB | TA)) => => Auth. Z(Attr. A. roles, Policy. permissions) => => Resource. permissions June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 16

Пример использования: Система контроля доступа в демосистеме Collaboratory. nl (CNL 2) JNLP – Java Network Launch Protocol CHEF – Collaborative tool Surabaya – Collaborative Workspace environment Locations/trust domains June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 17

CNL 2 Auth. Z policy: Resource, Actions, Subject, Roles Actions (8) · · · · Roles (4) · · · Start. Session Stop. Session Join. Session Control. Experiment Control. Instrument View. Experiment View. Archive Admin. Task Analyst Customer Guest Administrator (Certified. Analyst) Naming convention · Resource - “http: //resources. collaboratory. nl/Phillips_XPS 1” · Subject – “WHO 740@users. collaboratory. nl” · Roles - “role“ or “role@Job. ID” June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 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)} Policy. Set Rule ID#1 Rules Policy {Rules} … Policy {Rules} Rule Target {S, R, A} Condition Attr. Designat Match List Rule ID#n June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 19

Oткрытые системы для Auth. N/Auth. Z Разработаны в рамках проектов Internet 2, FP 5/FP 6 и национальных научных сетей · Internet 2 проекты u Shibboleth - http: //shibboleth. internet 2. edu/ · TERENA AAI (Authentication, Authorisation Initiative) и ассоциированные проекты - http: //www. terena. nl/tf-emc 2/ A-Select - http: //a-select. surfnet. nl/ u PAPI - http: //www. rediris. es/app/papi/index. en. html u PERMIS - http: //www. permis. org/ u GEANT JRA 5 AAI Framework - http: //www. geant 2. net/ u · Globus Toolkit 4. 0 Auth. Z Framework · GAAA_tk and GAAAPI (Generic Auth. N, Auth. Z API) GAAA_tk - http: //www. science. uva. nl/research/air/projects/aaa/ u GAAAPI - http: //staff. science. uva. nl/~demch/projects/aaauthreach/ u June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 20

Обсуждение и вопросы? Обговорення і питання? Discussion and Questions? Bespreking and Vragen? June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 21

Дополнительная информация · · Примеры Auth. Z tickets and tokens Управление сессией авторизации Примеры политики в формате AAA и XACML GT 4 Authorisation Framework June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 22

Модель контроля доступа в СОУ - Обмен Authz. Ticket и Authz. Token June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 23

Mapping between CNLAuthz. Ticket, XACML Request/Response and SAML 2. 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 Auth. Z • Attributes can be placed only as deep as 5 level down: Assert/Az. Stm/Evid/Attr. Asrt/Attr. Value • Ambiguous location for Policy. URIs and Session. ID • SAML 1. 1 Confirmation. Data element is extensible type – compatibility problems June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 24

Using SAML 1. 1/2. 0 for Authz. Ticket 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 XACMLAuthz. Statement General problems for Authorisation assertion · Attributes can be placed only as deep as 5 level down: Assertion/Authz. Statement/Evidence/Attribute. Assertion/Attribute. Value · Ambiguous location for Policy. URIs and Session. ID · Ambiguous mapping for XACML/Obligation to SAML/(Condition or Advice) · SAML 1. 1 Confirmation. Data element is an extensible type – compatibility problems · XACML Obligation element u Can be mapped to SAML Condition element or SAML Advice element June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 25

CNLAuthz. Ticket example – 1011 bytes <cnl: CNLAuthz. Ticket xmlns: AAA="http: //www. AAAarch. org/ns/AAA_Bo. D" xmlns: cnl="http: //www. aaauthreach. org/ns/#CNL" Issuer="http: //www. AAAarch. org/servers/AAA" Policy. URIs="CNLpolicy 01" Session. Index="Job. XPS 1 -2005 -001" Ticket. ID="c 24 d 2 c 7 dba 476041 b 7853 e 63689193 ad">  <cnl: Decision Resource. ID="http: //resources. collaboratory. nl/Philips_XPS 1">Permit</cnl: Decision> <cnl: Validity Not. Before="2005 -02 -13 T 01: 26: 42. 699 Z" Not. On. Or. After="2005 -02 -14 T 01: 26: 42. 699 Z"/>  <cnl: Subject Id="subject"> <cnl: Subject. ID>WHO 740@users. collaboratory. nl</cnl: Subject. ID> <cnl: Subject. Confirmation. Data>Se. DFGVHYTY 83 ZXx. Edswe. OP 8 Iok</cnl: Subject. Confirmation. Data> <cnl: Job. ID>CNL 2 -XPS 1 -2005 -02 -02</cnl: Job. ID> <cnl: Role>analyst@Job. ID; expert@Job. ID</cnl: Role> </cnl: Subject> <cnl: Resource>http: //resources. collaboratory. nl/Philips_XPS 1</cnl: Resource> <cnl: Actions> <cnl: Action>cnl: actions: Ctrl. Instr</cnl: Action> <cnl: Action>cnl: actions: Ctrl. Exper</cnl: Action> </cnl: Actions> <ds: Signature xmlns: ds="http: //www. w 3. org/2000/09/xmldsig#">. . . </ds: Signature> </cnl: CNLAuthz. Ticket> June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 26

CNLAuthz. Ticket XML Signature element – 957 bytes (total signed ticket 1968 bytes) <ds: Signature xmlns: ds="http: //www. w 3. org/2000/09/ xmldsig#"> <ds: Signed. Info> <ds: Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> <ds: Signature. Method Algorithm="http: //www. w 3. org/2000/09/ xmldsig#rsa-sha 1"/> <ds: Reference URI=""> <ds: Transforms> <ds: Transform Algorithm="http: //www. w 3. org/2000/09/ xmldsig#enveloped-signature"/> <ds: Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315# With. Comments"/> </ds: Transforms> <ds: Digest. Method Algorithm="http: //www. w 3. org/2000/09/ xmldsig#sha 1"/> <ds: Digest. Value>nr. Nr. ZZDiw/2 a. Dn. KXFEHSeoixnsc=</ds: Digest. Value> </ds: Reference> </ds: Signed. Info> <ds: Signature. Value> 0 IZt 9 Ws. JT 6 an+t. Ixhh. TPtizt. Dp. Z+iynx 7 K 7 X 2 Cxd 2 i. Bw. CUTQ 0 n 61 Szv 81 DKll. Wsq 75 Is. Hfusnm 56 z. T 3 fh. KU 1 z. EUsob 7 p 6 o. MLM 7 hb 42+vjfv. Ne. Ju 2 roknh. IDzru. Mrr 6 h. MDs. Ifaot. URepu 7 QCT 0 s. ADm 9 If X 89 Et 55 Ek. SE 9 o. E 9 q. BD 8= </ds: Signature. Value> <ds: Key. Info> <<. . . snip. . . >> </ds: Key. Info> </ds: Signature> June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 27

RSA <ds: Key. Info> element – 1010 bytes (total signed ticket with Key. Info - 3078 bytes) <ds: Key. Info> <ds: X 509 Data> <ds: X 509 Certificate> MIICADCCAWk. CBEGX/FYw. DQYJKo. ZIhvc. NAQEEBQAw. Rz. ELMAk. GA 1 UEBh. MCTkwx. GTAXBg. NVBAo. TEENv b. Gxh. Ym 9 y. YXRvcnkubmwx. HTAb. Bg. NVBAMTFEFBQXV 0 a. HJl. YWNo. IFNl. Y 3 Vya. XR 5 MB 4 XDTA 0 MTEx. NTAw NDYx. NFo. XDTA 1 MDIx. Mz. Aw. NDYx. NFow. Rz. ELMAk. GA 1 UEBh. MCTkwx. GTAXBg. NVBAo. TEENvb. Gxh. Ym 9 y. YXRv cnkubmwx. HTAb. Bg. NVBAMTFEFBQXV 0 a. HJl. YWNo. IFNl. Y 3 Vya. XR 5 MIGf. MA 0 GCSq. GSIb 3 DQEBAQUAA 4 GN ADCBi. QKBg. QDd. Dr. Bh. Vmr 1 n. D 9 eqi 7 U 7 m 4 yj. IRxfvj. AKv 33 Epuajv. TKHp. KUg. Ljbc. BC 3 j. NJ 4 F 7 a 0 Gi. XQ c. Vbu. F/a. Dx/yd. IUJXQktv. Fx. K 0 Sm 77 WVe. Sel 0 c. Lc 1 h. Yf. USAg 4 mudtfs. B 7 r. Aj+Cz. Nn. Vdr 6 RLFp. S 9 YFE lv 5 pt. Ga. NGSbw. Hj. U 02 Hn. Ar. EGL 2 K+0 Aw. IDAQABMA 0 GCSq. GSIb 3 DQEBBAUAA 4 GBADHKqk. OW 4 m. P 9 Dv. Oi b. Mvf 4 oq. XTth 7 yv 8 o 3 Zol 7+nql. B 9 Tqf/b. VNLMk 8 v. No 5 f. WRHbpn. HIFFg. Tk 31 nr. Jf 8 k. EZEofvw. Ae. W 9 s 1 g. Qt. Yfs 1 oxvs. MPKHx. Fj. JDi. Zl. Lk. HRVi. Jl/slz 5 a 7 pk. Lq. IXLRs. PFRzi. Tksem. RXB/f. T 8 KDz. M 14 pz. QZg Hic. O </ds: X 509 Certificate> </ds: X 509 Data> <ds: Key. Value> <ds: RSAKey. Value> <ds: Modulus> 3 Q 6 w. YVZq 9 Zw/Xqou 1 O 5 u. Moy. Ec. X 74 w. Cr 99 x. Kbmo 70 yh 6 Sl. IC 423 AQt 4 z. Se. Be 2 t. Bol 0 HFW 7 hf 2 g 8 f 8 n. SFCV 0 JLbxc. St. Epu+1 l. Xknpd. HC 3 NYWH 1 Eg. IOJrnb. X 7 Ae 6 w. I/gsz. Z 1 Xa+ k. Sxa. Uv. WBRJb+ab. Rmj. Rkm 8 B 41 NNh 5 w. Kx. Bi 9 ivt. AM= </ds: Modulus> <ds: Exponent>AQAB</ds: Exponent> </ds: RSAKey. Value> </ds: Key. Info> June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 28

CNLAuthz. Token example – 293 bytes <cnl: CNLAuthz. Token. ID="ed 9 d 969 e 1262 ba 1 d 3 a 7 f 33 dbd 670 dd 94"> <cnl: Token. Value> 0 IZt 9 Ws. JT 6 an+t. Ixhh. TPtizt. Dp. Z+iynx 7 K 7 X 2 Cxd 2 i. Bw. CUTQ 0 n 61 Szv 81 DKll. Wsq 75 Is. Hfusnm 56 z. T 3 fh. KU 1 z. EUsob 7 p 6 o. MLM 7 hb 42+vjfv. Ne. Ju 2 roknh. IDzru. Mrr 6 h. MDs. Ifaot. URepu 7 QCT 0 s. ADm 9 If X 89 Et 55 Ek. SE 9 o. E 9 q. BD 8= </cnl: Token. Value> </cnl: CNLAuthz. Token> · CNLAuthz. Token is constructed of the CNLAuthz. Ticket. ID and Signature. Value · CNLAuthz. Token use suggests caching CNLAuthz. Ticket’s June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 29

CNLSAMLAuthz. Ticket example – 2254 bytes <Assertion xmlns="urn: oasis: names: tc: SAML: 1. 0: assertion" xmlns: samlp="urn: oasis: names: tc: SAML: 1. 0: protocol" Assertion. ID="c 236 b 047 d 62 db 5 cecec 6 b 240996 bcb 90" Issue. Instant="2005 -02 -15 T 14: 53: 23. 542 Z" Issuer="cnl: subject: CNLAAAauthority" Version="1. 1"> <Conditions Not. Before="2005 -02 -16 T 14: 32: 12. 506 Z" Not. On. Or. After="2005 -02 -17 T 14: 32: 12. 506 Z"> <Condition xsi: type="typens: cnl: session-id">Job. XPS 1 -2005 -001</Condition> <Condition xsi: type="typens: cnl: policy-uri">CNLpolicy 01</Condition> </Conditions> <Authorization. Decision. Statement Decision="Permit" Resource="http: //resources. collaboratory. nl/Philips_XPS 1"> <Action Namespace="urn: oasis: names: tc: SAML: 1. 0: action: cnl: action">cnl: actions: Ctrl. Instr</Action> <Action Namespace="urn: oasis: names: tc: SAML: 1. 0: action: cnl: action">cnl: actions: Ctrl. Exper</Action> <Evidence> <Assertion. ID="f 3 a 7 ea 74 e 515 ffe 776 b 10 a 7 eef 0119 d 7" Issue. Instant="2005 -02 -15 T 14: 53: 23. 542 Z" Issuer=" cnl: subject: CNLAAAauthority" Major. Version="1" Minor. Version="1"> <Conditions Not. Before="2005 -02 -15 T 14: 53: 11. 745 Z" Not. On. Or. After="2005 -02 -16 T 14: 53: 11. 745 Z"/> <Attribute. Statement> <Subject> <Name. Identifier Format="urn: oasis: names: tc: SAML: 1. 1: nameid-format: email. Address" Name. Qualifier="cnl: subject">WHO 740@users. collaboratory. nl</Name. Identifier> <Subject. Confirmation> <Confirmation. Method>signed-subject-id</Confirmation. Method> === moved to attr in SAML 2. 0 <Confirmation. Data> PBLIR 0 a. ZRtd. Zmq 979 lj 8 e. Dp. J 5 VT 6 Bxx. WBt. SAp. C 5 BPn. Isf. HRUc. OOp. WQow. XBw 2 Tm. OZd. JGNz. FWh. Minz XU 3/w. Sd. Ljv+si. O 2 JGfy. Z 7 U 9 eqk. M 0 Gq. Y 8 Viz. Ml 5 u. Ru. UAsrr 7 AIHv 9/DP 1 ks. JMNDZ 5 Dn. Gos. Mc+ Zyqn Kogf. Mqh. K+DKq. Pwf. HF 6 U=</Confirmation. Data> </Subject. Confirmation> </Subject> <Attribute xmlns: typens="urn: cnl" xmlns: xsd="http: //www. w 3. org/2001/XMLSchema" xmlns: xsi="http: //www. w 3. org/2001/XMLSchema-instance" Attribute. Name="Attribute. Subject" Attribute. Namespace="urn: cnl"> <Attribute. Value xsi: type="typens: cnl: job-id">CNL 2 -XPS 1 -2005 -02 -02</Attribute. Value> === level 5 of element <Attribute. Value xsi: type="typens: cnl: role">analyst@Job. ID; expert@Job. ID</Attribute. Value> </Attribute. Statement> </Assertion> </Evidence> </Authorization. Decision. Statement> </Assertion> June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 30

CNLAuthn. Ticket example – 1752 bytes <cnl: CNLAuthn. Ticket xmlns: AAA="http: //www. AAAarch. org/ns/AAA_Bo. D" xmlns: cnl="http: //www. aaauthreach. org/ns/#CNL" Issuer="http: //www. AAAarch. org/servers/AAA" Ticket. ID="f 35585 dfb 51 edec 48 de 0 c 7 eadb 11 c 17 e">  <cnl: Validity Not. Before="2005 -02 -15 T 14: 33: 10. 548 Z" Not. On. Or. After="2005 -02 -16 T 14: 33: 10. 548 Z"/> <cnl: Subject Id="subject"> <cnl: Subject. ID>WHO 740@users. collaboratory. nl</cnl: Subject. ID> <cnl: Subject. Confirmation. Data> 0+q. QNAVu. ZW 4 tx. Mi 8 DH 6 DFy 7 e. LMGx. Sf. KDJY 6 Zn. Y 4 UW 5 Dt 0 JFtatl. Epr. Utgnj. Ckzr. JUMv. Wk 9 qt. Uzna s. Dd. UG+P 4 ZY 7 dgab+PHi. U 91 Clus. Zbztu/ZIj. Nq. Cnw 5 su 1 BQLTum. C 8 ZTt. YKKJi 4 WWs+b. MMb. P 8 m. FNQm +M 7 F 4 b. JIPBf. Lcxf 0 bk 4= </cnl: Subject. Confirmation. Data>  <cnl: Subject. Attribute attrname="urn: cnl: subject: attribute: job-id"> CNL 2 -XPS 1 -2005 -02 -02 </cnl: Subject. Attribute> <cnl: Subject. Attribute attrname="urn: cnl: subject: attribute: role"> analyst@Job. ID; expert@Job. ID </cnl: Subject. Attribute> </cnl: Subject> </cnl: CNLAuthn. Ticket> June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 31

CNLAuthn. Token signed/encrypted – 401/269 bytes <cnl: CNLAuthn. Token xmlns: cnl="http: //www. aaauthreach. org/ns/#CNL" Token. ID="f 35585 dfb 51 edec 48 de 0 c 7 eadb 11 c 17 e"> <cnl: Subject. ID>WHO 740@users. collaboratory. nl</cnl: Subject. ID> <cnl: Token. Value> 0+q. QNAVu. ZW 4 tx. Mi 8 DH 6 DFy 7 e. LMGx. Sf. KDJY 6 Zn. Y 4 UW 5 Dt 0 JFtatl. Epr. Utgnj. Ckzr. JUMv. Wk 9 qt. Uzna s. Dd. UG+P 4 ZY 7 dgab+PHi. U 91 Clus. Zbztu/ZIj. Nq. Cnw 5 su 1 BQLTum. C 8 ZTt. YKKJi 4 WWs+b. MMb. P 8 m. FNQm +M 7 F 4 b. JIPBf. Lcxf 0 bk 4=</cnl: Token. Value> </cnl: CNLAuthn. Token> · CNLAuthn. Token is constructed of the CNLAuthn. Ticket. ID and Subject. Confirmation. Data which is encrypted Subject. ID value · CNLAuthz. Token must be self-sufficient and doesn’t require caching CNLAuthn. Ticket’s <cnl: CNLAuthn. Token xmlns: cnl="http: //www. aaauthreach. org/ns/#CNL" Token. ID="a 392 a 20157698 d 201 d 77 b 2 c 6 e 8 e 444 ef"> <cnl: Subject. ID>WHO 740@users. collaboratory. nl</cnl: Subject. ID> <cnl: Token. Value>qij 9 z. Jg. KZp 9 Ri. Jx. YN 1 QJAN 0 vhj. LJSMGVLD/do. Qtm. Csk=</cnl: Token. Value> </cnl: CNLAuthn. Token> June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 32

Session management in CNL 2 Auth. Z system · Maintaining session is a part of generic RBAC functionality · Session can be started only by authorised Subject/Role u Session can be joined by other less privileged users · Session. ID is included into Authz. Ticket together with other decision attributes u Signed Authz. Ticket is cached by PEP or PDP · If session is terminated, cached Authz. Ticket is deleted u Note: Authz. Ticket revocation should be done globally for the Auth. Z trust domain June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 33

Tickets/Tokens handling in Auth. Z system · · Authz. Ticket is issued by PDP and may be issued by PEP Authz. Ticket must be signed Authz. Ticket contains all necessary information to make local PEP-Triage Request verification When using Authz. Tokens, Authz. Tickets must be cached; Resolution mechanism from token to ticket must be provided June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 34

CNL 2 Auth. Z policy: RBAC using AAA format Policy generation conventions · Subject validation · Resource and Environment checking · Access rules evaluation u Rules are expressed as permissions to perform an action against Subject role June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 36

CNL 2 Auth. Z 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 u 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 u Rules effect is “Permit” u · Subject validation – is not supported by current XACML functionality u TODO: add Function or do validation at/by PEP or Context Handler June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 37

GT 4 Auth. Z 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 u Simple policy format June 16, 2005 RELARN 2005 Access Control in Web Services and Grid 38

GT 4 Auth. Z framework: Multiple configured PDPs GT 4 implementation uses Interceptor concept • Originated from POSIX Auth. Z 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 RELARN 2005 Access Control in Web Services and Grid 39

Скачать презентацию Обеспечение гибкой системы контроля доступа в Веб-сервисах и

41b7d231b3dd38e7d2f90d545b4d3b24.ppt

Количество слайдов: 39