Webov

1
Webové služby a bezpecnost 2

• Doc. Ing. Ladislav Hudec, CSc.

1
2
Manažment identity

• Manažment identity pre SOA. Obsahuje celú škálu
  udalostí súvisiacich s identitou entity
• Informácie a dokumenty, pomocou ktorých je
  verifikovaná identita entity.
• Vydávanie dokumentov identity entity a osobných
  dokumentov.
• Autentizácia identity entít v miestach vstupu do
  SOA.
• Identita entity formuje v SOA základ pre
  autorizáciu a dôveru.
• Systém manažmentu identity (IDMS - Identity
  Management System) ako taký je zodpovedný za
  verifikáciu identity entity, registráciu entít a
  vydávanie digitálnych identifikátorov entitám
  (vid nasledujúci obrázok).
• Musí byt splnených viacero podmienok, aby bol
  obcan (ludská entita) registrovaný v registri
  obcanov SR (register fyzických osôb).
• Podobne to je aj s právnickými osobami a môžu byt
  iné požiadavky napríklad pre neziskové inštitúcie
  a súkromné podnikatelské subjekty.
• Pre hrácov stávkových hier stací na preukázanie
  identity platná emailová adresa a císlo bankového
  úctu, pre elektronický obchod stací platná
  emailová adresa a císlo kreditnej karty.
• Akonáhle bol entite vydaný digitálny
  identifikátor, môže byt tento identifikátor
  použitý v rámci inštitúcie spolu s dalším
  informáciami o entite ako napríklad jej rola a
  autorizacné atribúty. Identifikátor sa môže stat
  castou digitálnych dokladov, ktoré autorizujú
  entitu na prístup k rôznym zdrojom SOA.
• Pri registrácii musí entita poskytnút cast
  svojich dokladov, ktoré postacujú na autentizáciu
  identity. Samozrejme rôzne inštitúcie môžu mat
  rôzne politiky pre to, co predstavuje postacujúce
  autentizacné doklady. Vela sídiel e-obchodu
  vyžadujú od entít zadat meno a heslo, iné
  inštitúcie môžu od entity požadovat zaslanie
  certifikátu verejného klúca podla X.509.

2
3
Manažment identity
3
4
Manažment identity

• Po autentizácii identity entity bod rozhodnutia
  politiky (PDP Policy Decision Point) systému
  alebo zdroja, ku ktorému entita žiada prístup,
  musí stanovit ci novo-autentizovaná entita je
  tiež autorizovaná na prístup k zdroju.
• Na vykonanie autorizácie sa PDP spolieha na
  manažment privilégií a manažment atribútov.
• Rozhodnutie politiky umožnit alebo odmietnut
  prístup môže vychádzat z jednoduchého atribútu
  entity (napríklad atribútu roly) alebo môže
  vyžadovat kombináciu atribútov jemnej granularity
  (napríklad fyzické umiestnenie entity, aktuálnej
  aktívnej roly entity v systéme a úrovni oprávnení
  entity).
• Systém manažmentu atribútov využíva digitálny
  identifikátor (vydaný IDMS) na uloženie a výber
  týchto atribútov entity, ktoré sú vyžadované
  politikou manažmentu privilégií.
• Existujú tri významné architektúry manažmentu
  identity, ktoré sú dostupné na používanie pri
  webových službách
• Izolovaný manažment identity je to architektúra
  používaná väcšinou webových aplikácií na
  Internete.
• Poskytovatelia webových služieb fungujú aj ako
  poskytovatelia dokladov a aj poskytovatelia
  identity.
• Zjednodušuje to manažment pre jedinú službu a
  vylucuje potrebu TTP (Trusted Third Party), aby
  vykonávala funkciu poskytovatelov alebo
  dokumentov.
• Nevýhodou tejto architektúry je to, že každá
  služba musí poznat doklady a identifikátory
  všetkých autorizovaných žiadatelov. V prípade
  rozsiahlej SAO sa môže stat administrácia každého
  poskytovatela nezvládnutelná.

4
5
Manažment identity

• Existujú tri významné architektúry manažmentu
  identity
• Federatívny manažment identity skupina
  poskytovatelov súhlasí s tým, že si bude navzájom
  uznávat identifikátory používatelov.
• Každý poskytovatel služby funguje ako
  poskytovatel dokumentov a identít pre podmnožinu
  žiadatelov.
• Vydaním tvrdenia (napríklad autentizacné a
  atribútové tvrdenia SAML) môže poskytovatel
  služby vybavit ostatných poskytovatelov
  nevyhnutnými informáciami o žiadatelovi bez
  požadovania, aby sa žiadatel autentifikoval druhý
  krát. Toto zjednodušuje manažment identít a
  dokumentov pre SOA ako celku, ale vyžaduje
  individuálne služby dôvery tvrdení medzi
  poskytovatelmi.
• V jednej SOA v rámci inštitúcii nemusí byt
  obtiažne pre jednotlivých poskytovatelov
  dôverovat jeden druhému, ale asi bude menšia vôla
  dôverovat tvrdeniam v prípade, ked SOA zahrnuje
  poskytovatelov z rôznych inštitúcií. Žiadatel v
  SOA môže dat požiadavku poskytovatelovi a zadat
  lubovolné tvrdenie na získanie prístupu. Je
  dôležité mat politiku inštitúcie pre takýto typ
  údajov, ktoré prekracujú hranice SOA v
  inštitúcii.
• Centralizovaný manažment identity
  poskytovatelia sa spoliehajú na jednu TTP, ktorá
  vybaví žiadatelov dokumentami a identifikátormi.
• Je podobný na federatívny manažment identity v
  tom, že poskytovatelia dokladov a identity
  vystavia tvrdenia priamo poskytovatelom služieb
  umožnujúc tak žiadatelom prístup bez druhej
  autentizácia.
• Individuálni poskytovatelia služieb potrebujú
  poznat iba poskytovatela identity.
• V SOA medzi inštitúciami by mali byt inštitúcie
  ochotné dôverovat v prvom rade poskytovatelom
  identity partnerskej inštitúcii (viac než ich
  jednotlivým ponúkaným službám).
• Hlavným nedostatkom tejto architektúry je to, že
  poskytovatelia identity môžu fungovat ako jediné
  miesto poruchy (single point of failure).
  Napríklad v prípade útoku DoS na poskytovatela
  identity nebude možné, aby poskytovatel
  akceptoval akúkolvek požiadavku.
• Pri vývoji nových alebo aktualizácii existujúcich
  SOA je potrebné brat do úvahy velkost SOA a
  priority inštitúcií. Niektoré z uvedených
  architektúr nemusia byt vhodné pre SOA urcitej
  velkosti a môžu byt v rozpore s politikou
  inštitúcie.

5
6
Manažment identity a webové služby

• Webové služby poskytujú štandardizovaný
  mechanizmus na komunikáciu a zdielanie informácií
  napriec hraníc inštitúcií. Bezpecnostne
  akceptovatelné webové služby napriec inštitúcií
  vyžadujú spôsob na to, aby poskytovatelia
  bezpecne identifikovali a poskytovali služby
  oprávneným žiadatelom a spôsob pre žiadatelov,
  aby pomocou nevyhnutných dokladov bezpecne
  vyvolali webovú službu.
• Bez rámca manažmentu identity je pre webové
  služby obtažné bezpecne identifikovat jedna druhú
  alebo predložit uznatelné dokumenty.
• Napríklad, inštitúcia A môže používat na
  identifikáciu webových služieb a jednotlivých
  používatelov certifikáty X.509, zatial co
  inštitúcia B môže používat na identifikáciu
  tikety Kerbera. Ak žiadatel z inštitúcii B pošle
  poskytovatelovi z inštitúcii A správu SAOP s
  tiketom Kerbera, poskytovatel nebude schopný
  autorizovat žiadatela a prístup odmietne.
• Rámec manažmentu identity webových služieb
  abstrahuje túto informáciu a umožní webovým
  serverom bezpecne identifikovat jeden druhého bez
  ohladu na použitú identifikacnú technológiu. Na
  realizáciu tejto úlohy stací, aby inštitúcie mali
  jednoduchú množinu webových služieb
  zabezpecujúcich manažment identity napriec hraníc
  inštitúcií.
• Množina webových služieb na manažment identity
  napriec hraníc inštitúcií obsahuje
• Služby dôvery tieto služby vydávajú a validujú
  autentizacné tokeny na používanie napriec
  inštitúcií. Služby dôvery si tiež môžu vymienat
  tieto tokeny s lokálnym poskytovatelom identity.
• Autentizacné a validacné služby tieto služby sú
  poskytované lokálnymi poskytovatelmi identity,
  udelujú tokeny autentizovaným používatelom a
  validujú tokeny predložené službou dôvery.

6
7
Manažment identity a webové služby

• Množina webových služieb na manažment identity
  napriec hraníc inštitúcií obsahuje
• Služby mapovania identity a atribútov casto sú
  obsiahnuté v službách dôvery. Tieto služby mapujú
  zadané identifikacné informácie alebo atribúty do
  lokálnych ekvivalentov.
• Služby manažmentu životného cyklu používatela
  umožnujú zriadit alebo mapovat identifikacné
  informácie a atribúty pre používatela z inej
  inštitúcie.
• Autorizacné služby casto implementované lokálne
  pre individuálne služby. Autorizacné služby môžu
  spracovat doklady poskytnuté odosielatelom,
  dopýtat sa odpovedajúcej bezpecnostnej politiky a
  urcit ci odosielatelovi je dovolené vykonat
  požadovanú akciu.
• Systémy manažmentu identity môžu poskytnút tieto
  abstraktné služby v rôznych konfiguráciach,
  niektoré môžu byt explicitné webové služby a iné
  môžu byt poskytnuté implicitne.

7
8
Zriadenie dôvery medzi službami

• Aby SAML alebo WS-Security boli užitocné vo
  velkom rozsahu je potrebné, aby vztah dôvery bol
  zriadený medzi vzdialenými webovými službami.
  Podpísané tvrdenia SAML alebo správy WS-Security
  sú nepoužitelné, ak príjemca tvrdenia nie je
  schopný garantovat, že informácia v tvrdení je
  dôveryhodná.
• V pôvodnej špecifikácii SAML sú diskutované iba
  vztahy priamej dôvery sú referencované ako
  párové kruhy dôvery (pairwise circles of trust).
• Na druhej strane SAML v2.0 ponúka dalšie modely
  dôvery SAML sprostredkovanú (brokered) dôveru a
  komunitárnu (community) dôveru
• Kruhy párovej dôvery sú najtesnejšia a
  najpriamejšia forma vztahu dôvery. Každá entita,
  ktorá je autorizovaná komunikovat s dalšou
  entitou musí zdielat jej informácie o klúci. Ak
  tvrdenie SAML môže byt v kruhu párovej dôvery
  verifikované, potom je verifikované autorizovanou
  entitou. Jednou z hlavných nevýhod párovej dôvery
  je fakt, že každá entita musí mat kópiu verejného
  klúca od každej dalšej entity, s ktorou
  komunikuje. Tento fakt vytvára systém inherentne
  neškálovatelný.
• Model sprostredkovanej dôvery je rozšírením
  modelu párovej dôvery. Ked dve služby môžu
  komunikovat a nepoznajú navzájom svoje klúce, na
  výmenu klúcov sa použije TTP. Tento koncept
  umožnuje lepšie škálovanie než pri kruhu párovej
  dôvery, pretože pridanie poskytovatela novej
  služby spôsobí iba výmenu klúca novej služby s
  TTP. Poskytovatelia webových služieb musia verit,
  že TTP nebola kompromitovaná. Toto odlišuje od
  párového modelu, v ktorom každý poskytovatel
  služby je nezávisle zodpovedný za dôveru.
• Dalšou tažkostou v modeli sprostredkovanej dôvery
  je situácia, v ktorej dve služby môžu komunikovat
  s TTP ale nemôžu komunikovat navzájom medzi
  sebou. V modeli párovej dôvery tieto dve služby
  by nemali potrebné klúce na vzájomnú komunikáciu.
  V modeli sprostredkovanej dôvery môžu obe služby
  komunikovat s TTP a teda tiež s ostatnými
  entitami. To znamená, že alebo TTP alebo
  jednotlivé entity musia vediet, kto môže a kto
  nemôže s kým komunikovat.

8
9
Zriadenie dôvery medzi službami

• Model komunitárnej dôvery sa pri zriadení dôvery
  spolieha na externú PKI. Tento model dôvery
  predpokladá, že PKI interfejsy sú implementované
  korektne a že žiadna certifikacná autorita nebola
  kompromitovaná. Tento model ponúka dôveru podobnú
  aká je v párovom modeli a škálovatelnost aká je v
  sprostredkovanom modeli. Klúc vzdialenej intity
  je podpísaný dôveryhodnou autoritou a teda je
  bezpecné s jeho použitím komunikovat. Musí však
  ale existovat mechanizmus zabranujúci dvom
  entitám komunikovat v prípade, že je to proti
  politike (aj ked si navzájom poznajú klúce).
  Tento mechanizmus je implementovaný v PKI alebo v
  jednotlivých entitách. Pridanie novej služby je
  jednoduché pridaním klúca do PKI.
• Podpísané tvrdenia SAML majú tie isté
  bezpecnostné nedostatky ako každá technológia
  využívajúca kryptografiu verejného klúca
  privátny klúc nesmie byt kompromitovaný.
• Rámec federácie dôvery poskytuje podporu pre
  všetky skorej vymenované modely dôvery bez ohladu
  na to ci webové služby potrebujú dôverovat jedna
  druhej v rámci jednej inštitúcie alebo napriec
  hraníc viacerých inštitúcií.
• Federácia dôvery
• Dôvera v distribuovanom výpoctovom prostredí je
  zvycajne verifikovaná pomocou PKI certifikátov
  (podpísaných dôveryhodnou certifikacnou
  autoritou) alebo predložením zákazníckeho tokenu,
  ktorý je generovaný TTP (napríklad Kerberos
  token). Tradicne tieto mechanizmy dôvery fungujú
  dobre v rámci jednej inštitúcii. Pokial zdielanie
  informácií prekracuje hranice inštitúcii, entity
  navzájom komunikujúce nemusia nevyhnutne mat ten
  istý zdroj dôvery. Pred príchodom webových
  služieb bolo zdielanie informácií napriec
  inštitúciami riešené pomocou proxy, ktoré
  preklenovalo hranice, alebo pomocou krížových
  certifikátov.

9
10
Zriadenie dôvery medzi službami

• Federácia dôvery
• V SOA by mali webové služby z viacerých
  inštitúcií dôverovat jedna druhej bez vyžadovania
  rozsiahlejšej reštrukturalizácii prostredia
  dôvery. Vychádzajúc z tejto požiadavky, rámec
  federatívnej dôvery by mal byt konfigurovaný s
  využitím už existujúcich autentizacných
  mechanizmov v inštitúciách. Liberty Alliance
  poskytuje pre webové aplikácie a aj pre federáciu
  webových služieb využívanie SAML na realizáciu
  sprostredkovania dôvery. WS-Federation dovoluje
  federalizovat rôzne bezpecnostné oblasti (realms)
  definovaním sprostredkovatelov dôvery, ktorí
  validujú použitím WS-Trust bezpecnostné tokeny
  používané medzi webovými službami.
• WS-Federation a WS-Trust
• Boli vyvinuté viacerými firmami (IBM, Microsoft,
  RSA, BEA), aby vytvorili systém federácie
  identity založený na rozšírení WS-Security, ktorá
  používa protokoly hlavných webových služieb SOAP
  a WSDL. WS-SecurityPolicy je rozšírením rámca
  WS-Policy, ktorý dovoluje webovej službe
  definovat množinu detailných požiadaviek ako
  musia byt správy zabezpecené a aké tokeny sú
  webovou službou vyžadované. To využíva WS-Trust
  na urcenie, ktoré tokeny sú potrebné na
  interakciu s urcitou webovou službou.
• WS-Trust je využitá na výmenu tokenov dôvery
  medzi webovými službami
• WS-Trust je rozšírením WS-Security.
• WS-Trust poskytuje metódy na vydanie, obnovu a
  validáciu bezpecnostných tokenov a metód na
  zriadenie a sprostredkovanie vztahov dôvery medzi
  webovými službami.
• Ak žiadatel nezadá vhodnú žiadost, môže použit
  bezpecnostnú politiku deklarovanú vo
  WS-SecurityPolicy stanovujúcu URI poskytovatela
  so službou bezpecnostných tokenov (STS- Security
  Token Service), kde je daná informácia a kde
  zistí aká žiadost je vhodná.
• Navyše, WS-Trust podporuje výmeny s viacerými
  správami, ktoré dovolujú poskytovatelom použit na
  autorizáciu mechanizmus výzvy a odpovede.
• Pretože WS-Trust je vystavaná nad WS-Security,
  žiadostou môže byt cokolvek od digitálneho
  podpisu po certifikát X.509 alebo token na báze
  XML ako je SAML tvrdenie.

10
11
Zriadenie dôvery medzi službami

• WS-Federation a WS-Trust
• WS-Federation rozširuje WS-Trust.
• WS-Federation je rozšírená rôznymi protokolmi,
  pomocou ktorých STS (zamenitelne nazývaná
  poskytovatel identity vo WS-Federation),
  žiadatelia a poskytovatelia môžu medzi sebou
  navzájom interagovat a pomocou ktorých umožnujú
  webovým službám dôverovat jedna druhej napriec
  hraníc inštitúcií.
• Každá inštitúcia je separátna oblast dôvery
  (trust realm). WS-Federation umožnuje webovým
  službám komunikovat medzi viacerými oblastami
  dôvery.
• WS-Federation ponúka dva profily na to, ako
  žiadatelia interagujú s poskytovatelmi a STS
  aktívny a pasívny profil žiadatela. Pasívny
  profil žiadatela udáva detail ako musia byt
  posielané správy medzi webovým browserom
  žiadatela (klient om webovej služby),
  poskytovatelom, poskytovatelmi identity (IP
  Identity Provider) a STS obidvoch inštitúcií tak,
  aby WS-Federation mohla byt použitá v rámci
  kontextu webových aplikácií, poskytujúcich
  používatelom prax SSO (Single Sign On). Aktívny
  profil žiadatela udáva detaily ako musia
  žiadatelia interagovat s poskytovatelom a IP/STS
  na prístup k poskytovatelovi v dalšej oblasti
  dôvery.

11
12
Opis politík webových služieb (WS-Policy)

• WSDL opisuje ako komunikovat s webovou službou.
• WSDL udáva detaily protokolu väzby a formáty
  správy, ktoré webová služba ocakáva. V mnohých
  prípadoch protokol väzby a formáty správy nie sú
  postacujúce pre žiadatelov na dynamickú väzbu s
  poskytovatelom.
• WSDL je obmedzený na opis, co by malo byt uložené
  v samotnej správe. Nešpecifikuje aký typ metadát
  by mal byt zadaný, ako bude správa autentizovaná
  alebo ktorá cast správy by mala byt podpísaná. K
  tomuto úcelu bol vytvorený rámec politiky webovej
  služby (WS-Policy), ktorý dovoluje poskytovatelom
  vyjadrit možnosti, požiadavky a charakteristiky
  webovej služby.
• WS-Policy požiadavky môžu byt v rozsahu od
  špecifických on-the-wire požiadaviek takých ako
  požiadavka WS-Security šifrovanie alebo
  podpisovanie až po abstraktnejšie požiadavky ako
  sú QoS alebo požiadavky na privátnost.
• Vyjadrenie politiky WS-Policy vybavuje
  odosielatela základnými metadátami pre plnú
  automatizáciu dynamickej väzby. Vyjadrenie
  politiky obsahuje množinu alternatív politiky
  spolu s množinami tvrdení.
• Tvrdenia (assertions) politiky sú definované pre
  množstvo WS- špecifikácií vrátane
  WS-SecurityPolicy, WS-ReliableMessaging Policy
  Assertions (WS-RM) a WS-Addressing WSDL Binding.
  WS-Policy Primer (dostupné na http//www.w3.org/)
  definuje ako môžu byt tieto špecifikácie použité
  v rámci výrazov politiky. Existujú tri primárne
  (2007) špecifikácie definujúce WS-Policy
  tvrdenia
• WS-SecurityPolicy definuje tvrdenia na
  špecifikáciu integrity, dôvernosti a informácií o
  bezpecnostných tokenoch.
• WS-RM Policy definuje tvrdenia, ktoré môžu byt
  použité na špecifikáciu ako webové služby
  používajú WS-ReliableMessaging.
• WS-Addressing WSDL Binding definuje elementy,
  ktoré môžu byt použité v rámci WSDL deskriptora
  na špecifikáciu použitia WS-Addressing.

12
13
Opis politík webových služieb (WS-Policy)

• Na obrázku je príklad vyjadrenia WS-Policy
• Korenové vyjadrenie v príklade je All príznak
  (tag), ktorý je použitý na špecifikáciu, že
  všetky obsahujúce vyjadrenia musí žiadatel
  splnit, aby bol v súlade s politikou
  poskytovatela. All príznak obsahuje tieto
  vyjadrenia
• wsapUsingAddressing špecifikuje, že žiadatelia
  by mali zahrnút do hlavicky SOAP informáciu
  WS-Addressing.
• spTransportBinding špecifikuje, že žiadatelia
  by mali použit TLS na zabezpecenie správy SOAP a
  definuje požadované parametre.
• Element spTransportBinding obsahuje All príznak
  obsahujúci dve vyjadrenia
• spTransportToken špecifikuje, aký typ tokenu
  musí zadat odosielatel. V tomto príklade
  spHttpsToken indikuje, že odosielatel musí zadat
  prostredníctvom TLS klientsky certifikát .
• spAlgorithmSuite špecifikuje, aký algoritmus
  knižnice TLS odosielatela musí byt podporovaný. V
  tomto príklade spBasic256Sha256Rsa15, definovaný
  WS-SecurityPolicy, indikuje, že by mal byt
  použitý AES algoritmus s dlžkou klúca 256 bitov
  pre symetrické šifrovanie, 256 bitový algoritmus
  SHA na hašovanie a RSA v1.5 algoritmus pre
  asymetrické šifrovanie.

13
14
Opis politík webových služieb (WS-Policy)

• WS-Policy môže byt tiež použitá na opis
  nevyhnutných parametrov pri používaní
  WS-ReliableMessaging s cielom zaistit dodanie
  správy. Na obrázku je politika definujúca casovú
  závoru 2 sekundy pri neaktívnosti, základný
  interval 5 sekúnd retransmisie pri použití
  exponenciálneho algoritmu backoff a interval 5
  sekúnd na potvrdenie.

14
15
Opis politík webových služieb (WS-Policy)

• Príjemcovia majú volbu špecifikácie, ci
  odosielatelia by mali použit TLS alebo
  WS-Security na zabezpecenie správ SOAP. Niektorí
  príjemcovia si môžu priat rozhodnút sa, ktorú
  volbu budú podporovat. V takomto prípade by bolo
  použité vyjadrenie ExactlyOne na indikáciu volby
  spôsobom podobným na obrázku.

15
16
Opis politík webových služieb (WS-Policy)

• Vyjadrenie ExactlyOne na predchádzajúcom obrázku
  obsahuje dve vyjadrenia majúce vztah na
  zabezpecenie správ webovej služby medzi
  žiadatelom a poskytovatelom.
• Odosielatel si musí pri posielaní správy SOAP do
  tejto služby vybrat práve jednu z uvedených
  volieb
• spTransportBinding indikuje žiadatelovi, že
  môže použit SSL/TLS na zabezpecenie správy
• All obsahuje dve vyjadrenia WS-SecurityPolicy,
  ktoré musia byt dodržané pri používaní
  WS-Security namiesto SSL/TLS spsignedParts
  indikuje, že aj telo a aj hlavicka SOAP správy
  musí byt podpísaná, spEncryptionParts
  indikuje, že telo správy SOAP musí byt šifrované.
• Každé vyjadrenie politiky môže obsahovat
• Vyjadrenie All, ExactlyOne alebo element
  vyjadrenia z gramatiky WS-Policy ako sú
  WS-Security, WS-RM alebo WS-Addressing.
• Každé z týchto vyjadrení môže obsahovat dalšie
  vyjadrenia Policy.
• Táto úroven flexibility dovoluje poskytovatelovi
  kompletne špecifikovat požiadavky, ktoré musia
  byt žiadatelom splnené nad rámec požiadaviek
  daných v opise WSDL poskytovatela.
• Vyjadrenia politiky sú externé k metadátam
  uložených v UDDI a WSDL. To znamená, že
  poskytovatelia sa musia spoliehat na separátny
  mechanizmus distribúcie informácií WS-Policy
  WS-MetadataExchange alebo WS-PolicyAttachment.
• WS-MetadataExchnge špecifikácia definuje
  zapúzdrenie formátu pre metadáta webovej služby,
  mechanizmus na výmenu správ riadenú metadátami a
  opiera sa na špecifikáciu WS-Transfer pri
  zabezpecení koncového bodu webovej služby, z
  ktorého si žiadatelia môžu vybrat metadáta.
• WS-PolicyAttachment špecifikácia definuje ako
  referencovat politiku z definícií WSDL, ako
  združit politiky z rozmiestnených koncových bodov
  a ako združit politiky s položkami UDDI.

16
17
Distribuovaný manažment autorizácie a prístupu

• Vzhladom na distribuovanú podstatu architektúry
  webových služieb je správa autorizácie a dokladov
  riadenia prístupu používatelov v prostredí SOA
  netriviálny problém. V tejto casti budú uvedené
  opisy tradicných a pokrocilých modelov a praktík
  použitelných na uchopenie, spravovanie a
  presadzovanie rozhodnutí o riadení prístupu
  autorizovaných používatelov.
• Najdôležitejšie modely v správe prístupu v SOA
  sú
• RBAC (Role Based Access Control)
• ABAC (Attribute Based Access Control)
• PBAC (Policy Based Access Control)
• RAdAC (Risk Adaptive Access Control)
• Autorizacný model RBAC
• Je autorizacný mechanizmus, ktorý zväzuje množinu
  prístupových privilégií s urcitou rolou, casto
  korešpondujúcou s pracovnou pozíciou. Všetky
  prístupy používatela sú sprostredkované
  prostredníctvom roly.
• Zjednodušuje spravovanie bezpecnosti pomocou
  štruktúry hierarchie rolí.
• Má rozsiahle možnosti na obmedzenie prístupu
  používatela na základe administrátorom
  definovaných vztahov. Táto vlastnost umožnuje
  implementovat komplexné opatrenia ako napríklad
  separácia povinností.
• Väcšina komercne dostupných systémov RBAC je
  konformná s niektorým štandardom RBAC (NIST RBAC
  webová stránka).
• Skupina OASIS poskytuje XACML pre hlavný a
  hierarchický RBAC profil umožnujúci podporovat
  RBAC v inštitúciach pomocou flexibilnej a
  platformovo nezávislej špecifikácie XACML.

17
18
Distribuovaný manažment autorizácie a prístupu

• Autorizacný model RBAC
• RBAC na platforme webových služieb by mal byt
  implementovaný minimálne pre administrátorov,
  vývojárov a ostatné privilegované kontá, ktoré sú
  potrebné na prevádzku webovej služby. Platforma
  webovej služby musí byt konfigurovaná na
  presadzovanie separácie rolí (nedovolit
  používatelovi pridelenému do jednej roly, aby
  vykonával funkcie výlucne pridelené inej role).
• Privilégiá priradené každej roli by mali byt
  pridelené tak, aby zabezpecovali najmenšie
  potrebné privilégiá (least privilege) každej
  role by mali byt pridelené iba minimálne
  privilégiá potrebné na vykonanie funkcií
  požadovaných rolou.
• Väcšina dodávatelov implementuje vo svojich
  produktoch hlavných webových služieb niektorú
  formu RBAC. Inou alternatívou je implementovat
  alebo rozširovat RBAC na úrovni webových služieb,
  ktoré sú podporované mnohými bránami XML a
  dodávatelmi webových služieb.
• Autorizacný model ABAC
• Poskytuje mechanizmus na reprezentáciu
  prístupového profilu subjektu (používatela alebo
  aplikácie) prostredníctvom kombinácie týchto
  atribútov
• Atribúty subjektu (S) sú zviazané so subjektom
  a definujú identitu a charakteristiky subjektu
• Atribúty zdroja (R) - sú zviazané so zdrojom ako
  je webová služba, systémová funkcia alebo údaje
• Atribúty prostredia (E) opisujú prevádzkové,
  technické alebo situacné prostredie alebo
  kontext, v ktorom sa vykonáva prístup k
  informácii.
• Pravidlá politiky ABAC sú vytvárané ako Boolovské
  funkcie atribútov S, R a E a stanovujú ci subjekt
  S môže pristúpit k zdroju R v urcitom prostredí
  E. Túto skutocnost možno formálne zapísat
  vztahom
• Rule X can_access(s,r,e) ? f(ATTR(s), ATTR(r),
  ATTR(e))

18
19
Distribuovaný manažment autorizácie a prístupu

• Autorizacný model ABAC
• Prostredie SOA môže byt vo svojej podstate
  extrémne dynamické. Z tohto pohladu má model ABAC
  zjavnú výhodu oproti modelu RBAC. Pravidlá
  politiky ABAC môžu byt zákaznicky orientované s
  ohladom na sémantický obsah a sú významne
  flexibilnejšie ako RBAC pre jemnozrnné úpravy
  alebo nastavenia vo vztahu k prístupovému profilu
  subjektu. ABAC sa bezproblémovo integruje s
  XACML, ktoré sa pri vykonaní rozhodnutia o
  riadení prístupu spolieha na atribúty definované
  politikou.
• Dalším prínosom ABAC pri jeho implementácii do
  webových služieb spocíva v jeho volnej definícii
  subjektu. Pretože ABAC poskytuje flexibilitu pri
  pridelení pravidiel prístupu lubovolnému aktorovi
  (subjektu), môže byt ABAC rozšírený aj na
  softvérových agentov webových služieb. Na
  nasledujúcom obrázku je ilustrácia ako môže byt
  atribútová autorita (AA) ABAC integrovaná do
  rámca SAML. Na tomto obrázku AA generuje
  atribútové tvrdenia, ktoré obsahujú všetky
  atribúty potrebné rozhodnutie o riadení prístupu
  vychádzajúce z politiky ABAC napísanej v XACML.
  Bod rozhodnutia politiky (PDP Policy Decision
  Point) použije atribútové tvrdenia, autentizacné
  tvrdenia a politiku XACML na generovanie tvrdenia
  o autorizacnom rozhodnutí. Na obrázku je
  autentizacné tvrdenie žiadatela vydané
  poskytovatelom identity ešte pred prístupom k
  zdroju. Tieto kroky opisujú ako SAML a XACML
  použijú atribúty žiadatela na urcenie ci bude
  udelený prístup
• Žiadatel sa pokúša pristúpit k zdroju a predloží
  autentizacné tvrdenie.
• Bod presadzovania politiky (PEP Policy
  Enforcement Point) posiela bodu PDP SAML žiadost
  na rozhodnutie o autorizácii.
• PDP žiada urcité atribútové tvrdenia, ktoré sú
  zviazané so žiadatelom.
• AA vracia prííslušné atribútové tvrdenia.
• PDP žiada politiku XACML z úložiska politík.
• PDP prijíma politiku XACML.
• Po dopýtaní politiky XACML, PDP posiela PEP
  tvrdenie o autorizacnom rozhodnutí.
• Na základe tvrdenia o autorizacnom rozhodnutí,
  PDP udeluje žiadatelovi prístup k zdroju.

19
20
Distribuovaný manažment autorizácie a prístupu

• Použitie SAML a XACML pri implementácii ABAC

20
21
Distribuovaný manažment autorizácie a prístupu

• Autorizacný model PBAC
• Tento model je logickým a v niecom ohraniceným
  rozšírením modelu ABAC. Je užitocný pri
  presadzovaní striktných politík riadenia prístupu
  na úrovni prostredia.
• PBAC zavádza pojem autority politiky, ktorá slúži
  ako bod rozhodovania o prístupe v predmetnom
  prostredí.
• PBAC znižuje granulárne funkcie pravidiel
  politiky, ktoré sú charakteristické pre ABAC.
  PBAC sa sústreduje viac na automatizované
  presadzovanie povinného riadenia prístupu MAC
  (Mandatory Access Control), ktoré je tradicne
  omnoho viac ohranicené ako volitelné riadenie
  prístupu DAC (Discretionary Access Control).
• Autorizacný model RAdAC
• Tento model je dalším variantom tradicných metód
  riadenia prístupu. Na rozdiel od RBAC, ABAC a
  PBAC sa v modeli RAdAC vykonáva rozhodnutie o
  riadení prístupu na základe profilu relatívneho
  rizika pristupujúceho subjektu a nie nevyhnutne
  prísne na základe preddefinovaných pravidiel
  politiky. Na obrázku je logika procesu urcujúca
  RAdAC, ktorá využíva kombináciu meratelnej úrovne
  rizika, ktorému je pristupujúci subjekt
  vystavený, a ohodnotenie prevádzkových potrieb
  ako primárnych atribútov, pomocou ktorých sú
  urcené prístupové práva subjektu.
• RAdAC ako politikou riadený mechanizmus je
  zdanlivo abstrakciou PBAC. Na rozdiel od PBAC
  rámec RAdAC vyžaduje väzbu na zdroje, ktoré sú
  schopné pri každej žiadosti o autentizáciu (a
  prístup) poskytnút v reálnom case informácie
  týkajúce sa situácie, na základe ktorých je možné
  ohodnotit riziko.

21
22
Distribuovaný manažment autorizácie a prístupu

• Rozhodovací strom RAdAC

22
23
DAKUJEM ZA POZORNOST
23