Zabezpečenie webových služieb: Rozdiel medzi revíziami
() |
(→SAML) |
||
| Riadok 141: | Riadok 141: | ||
Štandard SAML umožňujúci zdieľanie autentifikačných a autorizačných informácii v rámci určitého systému. Medzi autotentifikačné a autorizačné informácie patria role a certifikáty. Dokument SAML môže byť digitálne podpísaní pomocou XML Signature. <nowiki>[</nowiki>15<nowiki>]</nowiki> | Štandard SAML umožňujúci zdieľanie autentifikačných a autorizačných informácii v rámci určitého systému. Medzi autotentifikačné a autorizačné informácie patria role a certifikáty. Dokument SAML môže byť digitálne podpísaní pomocou XML Signature. <nowiki>[</nowiki>15<nowiki>]</nowiki> | ||
| − | [[Súbor: | + | [[Súbor:tempDp_17.png|framed|center|Obr. 8.2 SSO ]] |
Obr. Chyba! V dokumente nie je žiaden text v zadanom štýle..14 SAML | Obr. Chyba! V dokumente nie je žiaden text v zadanom štýle..14 SAML | ||
Verzia zo dňa a času 16:49, 7. apríl 2010
Zabezpečenie webových služieb
V tejto kapitole sa budeme venovať spôsobom a technikám zabezpečenia webových služieb ASP.NET založených na autentifikácii, autorizácii, dôvernosti a integrity komunikácie.
Webová služba môže byť zabezpečená na týchto troch úrovniach [16]:
- na úrovni transportu, respektíve platformy,
- a na úrovni správ,
- na úrovni aplikácie.
Prvé dve vymenované možnosti zabezpečujú komunikáciu medzi dvoma koncovými bodmi, pri poslednej variante sa jedná o vlastný model zabezpečenia.
Zabezpečenie na úrovni transportu alebo platformy
Tento model sa slúži na vytvorenie bezpečnej komunikácie medzi dvoma koncovými bodmi, webovou službou a klientskou aplikáciou. Pri tomto spôsobe sa využíva zabezpečený transportný kanál na prenos SOAP správ.
- Bezpečnosť je zaistená platformou a transportným protokolom. Autentifikácia je realizovaná webovým serverom, buď s využitím základnej, digestívnej, integrovanej Windows autentifikácie alebo overovaním pomocou certifikátov. Integrita a dôvernosť komunikácie je zabezpečená napríklad pomocou protokolov SSL a IPSec.
K hlavnou výhodou tohto zabezpečenia je, že sa jedná jednoduchý, a výhodný model pre veľa scenárov v intranete, kde máme kontrolu nad konfiguráciou koncových komunikačných bodov a tak isto aj nad transportným mechanizmom.
Medzi hlavné nevýhody patrí [13]:
- Nie sú zabezpečené rôzne presmerovania v aplikačných uzloch, zabezpečené sú len koncové body komunikácie.
- Pri tomto spôsobe vzniká tesná väzba na transportný mechanizmus, nadradenú platformu a tak isto na poskytovateľa zabezpečenia (NTLM, Kerberos a iný).
Architektúra zabezpečenia na úrovni platformy
Volanie webovej služby klientom spúšťa nasledovnú sekvenciu udalostí [14], [16] :
1. Klient volá webovú službu. Predáva SOAP požiadavku.
2. Služba IIS môže vykonať autentifikáciu klienta na základe autentifikačných metód, ako sú základná, digestívna, integrovaná Windows autentifikácie alebo autentifikácia založená na certifikácii. Následne sa môže vykonať autorizácia klienta, obmedzenie niektorých IP adries, NTFS oprávnenie.
3. Pokiaľ overovanie a autorizácia klienta prebehne úspešne, služba IIS predá prístupový token overeného užívateľa do prostredia ASP.NET.
4. ASP.NET vykoná autentifikáciu klienta a následne prebehne autorizácia klienta k webovej službe ( k súboru .asmx). Autorizačný mechanizmus môže autorizácia na základe URL alebo autorizácia prístupu k súborom.
5. Následne webová služba môže použiť nejaký vzdialený prostriedok.
Webové služby nepoužívajú zosobnenie, implicitne používajú konfiguračný účet ASP.NET, v prípade potreby môžeme využiť impersonáciu (zosobnenie) kódu, a použiť identitu užívateľa, ktorý volá webovú službu.
Celý mechanizmus overovanie a autorizácie je znázornený na Obr. 7.2.
Zabezpečenie na úrovni správ
Zabezpečenie na úrovni správ predstavuje najflexibilnejší a najvýkonnejší spôsob zabezpečenia. Integrita XML správ je realizovaná pomocou digitálnych podpisov a utajenie komunikácie je zabezpečené kryptovaním.
Tento spôsob je napríklad implementovaní GXA pomocou špecifikácie WS – Security.
Výhody tohto modelu zabezpečenia sú [16]:
- bezpečnosť komunikácie je zaistená aj pri presmerovaní v aplikačných uzloch,
- nezávislosť na transportnom mechanizme,
- možnosť použiť viac typov kryptovacích technológii,
- podporuje nepopierateľnosť.
Zabezpečenie na úrovni aplikácie
Pri tomto type zabezpečenia je autentifikácia, autorizácia, poprípade zaistenie integrity a dôvernosti komunikácie ponechané na samotnej aplikácií. Tento spôsob je vhodné použiť, ak máme k dispozícii databázu existujúcich užívateľov a rolí. Ďalšou výhodou je selektívne kryptovanie prenášaných informácii, nie celej komunikácie. Nakoľko proces kryptovania je sám o sebe z časového hľadiska náročný.
XML Security
Ako sme už spomenuli komunikácia webových služieb a klientskych aplikácii prebieha prostredníctvom SOAP správ. Na komunikáciu je použitý typ SOAP správ nazývaný document-style (štýl dokument). Tento typ SOAP zobrazuje dáta, ktoré sú vymenované ako dokumenty, čiže každá SOAP správa obsahuje v tele XML dokument. Z toho dôvodu, môžeme využiť pri zabezpečovaní SOAP správ technológie zamerané na bezpečnosť XML.
XML Security predstavuje rozšírenie samotného XML o bezpečnostné mechanizmy. XML Security tvorí päť častí [14] , [15]:
- XML Signature (XS),
- XML Encryption (XE),
- Security Assertion Markup Language (SAML),
- XML Access Control Markup Language (XACML),
- XML Key Managment Specification (XKMS).
XML Signature
XML Signature je štandard definujúci XML schému pre uloženie výsledku operácie digitálneho podpisu aplikovaného na ľubovoľné (XML) dáta. XML podpisy sú najčastejšie využívané pri XML transakciách. Digitálne podpisovanie XML poskytuje mechanizmus na [15]:
- Autentifikáciu,
- kontrolu integrity a dôvernosti dát,
- na podporu neopakovateľnosti ( non repundation).
XML Signature umožňuje podpísať [17]:
- celý XML dokument,
- vybrané časti XML dokumentu.
Možnosť podpísať len vybranú časť XML stromu umožňuje veľkú flexibilitu. Napríklad v situácii, kde rozličné časti XML dokumentu boli vytvorené viacerými autoritami, každá autorita môže podpísať len svoju časť XML dokumentu.
Schéma XML digitálneho podpisu je v Tab. 8.1.
Tab. Chyba! V dokumente nie je žiaden text v zadanom štýle..24 XML Signature [17]
| - <<Signature xmlns="http://www.w3.org/2000/09/xmldsig "> - <<SignedInfo> <<CanonicalizationMethod Algorithm/> <<SignatureMethod Algorithm/> - <<Reference URI=""> - <<Transforms> <<Transform Algorithm/> </Transforms> <<DigestMethod Algorithm/> <<DigestValue> DigestValue> </Reference> </SignedInfo> |
Popis dôležitých elementov XML Signature [17]:
- Reference každý zdroj, ktorý má byť digitálne podpísaný má svoj vlastný Reference element, reprezentovaný URI adresou.
- Transform, je zoznam procesov ktoré sa aplikujú na obsah XML dokumentu, pred jeho digitálnym podpísaným.
- Digest, tento element obsahuje hodnotu digest odkazovaného zdroja.
- SignatureValue, obsahuje hodnotu zašifrovaného digest elementu SignedInfo.
XML Signature môže obsahovať ešte nepovinný element KeyInfo, ktorý určuje typ kľúča potrebného k overeniu digitálneho podpisu XML dokumentu.
Technológiu XML Signature použijeme pri zabezpečovaní komunikácie vo vlastnej bezpečnostnej platforme.
XML Encryption
XML Encryption je štandard definujúci XML schému pre uloženie výsledku operácie digitálneho šifrovania aplikovaného na ľubovoľné (XML) dáta. Takisto ako XML Signature aj XML Encryption umožňuje šifrovať [18]:
- celý XML dokument,
- vybrané časti XML dokumentu.
XML Encryption predstavuje point-to-point zabezpečenie, odstraňuje určité nedostatky technológie SSL alebo TLS.
Tento štandard nebude použitý pri vytváraní vlastnej bezpečnostnej platforme, nakoľko sme sa rozhodli ponúknuť vlastný alternatívny spôsob ako selektívne šifrovať časti XML s použitím veľmi bezpečného Advanced Encryption Standard. Dôvod vlastného spôsobu šifrovania XML je ten, že pri XML Encryption dochádza k zašifrovaniu tagov XML, tým sa stráca určitá funkčnosť XML dokumentu, v našom prípade SOAP správy.
Schéma XML Encrypt je v Tab. 8.2.
Tab. Chyba! V dokumente nie je žiaden text v zadanom štýle..25 XML Encrypt [18]
| <E <EncryptedData Type> < </EncryptionMethod Algorithm/> - < </CipherData> < </CipherValue></CipherValue> </CipherData> </EncryptedData> |
Pre viac informácii odporúčame [18].
SAML
Štandard SAML umožňujúci zdieľanie autentifikačných a autorizačných informácii v rámci určitého systému. Medzi autotentifikačné a autorizačné informácie patria role a certifikáty. Dokument SAML môže byť digitálne podpísaní pomocou XML Signature. [15]
Obr. Chyba! V dokumente nie je žiaden text v zadanom štýle..14 SAML
1. Webový portál overí indentitu užívateľa na základe klientskeho certifikátu. Užívateľovi pridelí určitú identitu, rolu.
2. Rola užívateľa je pripojená do SOAP správy, ktorá je digitálne podpísane webovým portálom.
3. Webová služba overí identitu webového portálu, skontroluje digitálny podpis, a následne zakáže alebo povolí klientovi prístup.
Štandard SAML sa skladá z troch častí [19]:
1. Definuje syntax a sémantiku správ obsahujúcich assertion (tvrdenia) vo forme XML.
2. Definuje protokoly pre výmenu bezpečnostných informácii.
3. Definuje pravidlá pre použitie assertion, štandardy pre transport. Napríklad SOAP tvrdenie môže byť poslané v SOAP správe cez HTTP kanál.
Security Assertion Markup Language sa dá využiť v tých 3 nasledujúcich scenárov [19]:
• Single sing-on (Jediné prihlásenie),
1. Klient je autentifikovaný prostredníctvom certifikátu na webovom portáli 1.
2. Pri prístupe na webový portál 2, by musel znova predložiť certifikát.
3. Pokiaľ je použitý SAML, webový portál 2 overí identitu na webovom portály 1, a na základe toho sa rozhodné či dovolí alebo odmietne prístup klientovi.
- Distribuované transakcie,
- Autorizačná služba.
XACML
Tento štandard úzko súvisí so SAML, ktorý slúži ako mechanizmus na šírenie autentifikačných a autorizačných informácii. XACML je autentifikačná a autorizačná informácia. Predstavuje XML metajazyk, ktorého úlohou je štandardizovať popis autentifikačných a autorizačných politík. Definuje slovník pre popis práv a podmienok subjektu.
Nakoľko štandard XACML nebude v bezpečnostnej platforme použitý, nebudeme sa ním podrobnejšie zaoberať. Pre viac informácii odporúčame [30].
XMKS
XMKS špecifikuje protokol pre hospodárenie s verejnými kryptografickými kľúčom [21]:
- Registrácia,
- Rušenie platnosti,
- Obnova kľúčov,
- Vydanie nového kľúča.
XMKS sa skladá z troch časti [21]:
1. XML Key Information Service Specification (X - KISS). Podporuje služby pre používanie kryptografických kľúčov.
2. XML Key Registration Service Specification (X – KRSS). Podporuje služby spojené s držiteľom kryptografických kľúčov (obnova, registrácia).
3. Bulk Key Regisration ( X- Bulk) predstavuje rozšírenie X – KRSS pre hromadnú registráciu kryptografických kľúčov. Tieto protokoly môžu byť použité spolu so SOAP.
