Sdílet prostřednictvím

Federace identit ve světě webových služeb

  • Článek

Autorská práva

 

© 2001-2003 International Business Machines Corporation, Microsoft Corporation. Všechna práva vyhrazena.

Abstraktní

Tento dokument popisuje problémy související se správou federovaných identit a popisuje komplexní řešení na základě specifikací webových služeb popsaných v plánu WS-Security a dalších specifikacích souvisejících webových služeb.

Přístup popsaný v tomto dokumentu white paper, který bude dále definován ve specifikaci WS-Federation, představuje zprostředkovatele identity jako třídu služby tokenů zabezpečení. Proto používá mechanismy WS-Trust a WS-Federation k vytvoření a zprostředkování důvěryhodnosti v rámci federací a napříč federacemi. Kromě toho jsou mechanismy definované pro jednotné přihlašování a odhlášení, sdílení atributů na základě autorizačních zásad a zásad ochrany osobních údajů a integrované zpracování pseudonymů (aliasů používaných na různých webech a federaci).

Společně poskytují specifikace uvedené v tomto dokumentu komplexní a integrovanou sadu protokolů pro zabezpečené spolehlivé transactované zprávy v rámci federace a napříč federacemi tím, že obsahují další specifikace zabezpečení a webové služby.

Shrnutí

V posledních několika letech se webové aplikace vyvinuly z jednoduchých aplikací pro doručování obsahu do sofistikovaných podnikových kancelářských nástrojů a mechanismu pro integraci aplikací v podnicích a napříč podniky. Růst webových a webových služeb ukázal potřebu otevřených a interoperabilních řešení mnoha technických problémů.

V tomto dokumentu se zaměříme na konkrétní sadu problémů souvisejících se zabezpečením. Patří mezi ně:

Jak určíme správné webové služby zabezpečené identity a umístění: Organizace potřebují standardní způsob, jak pro žadatele služeb (zákazníky a partnery) bezpečně najít správné webové služby daného podniku a pro poskytovatele obchodních služeb, aby bezpečně identifikovaly a zpřístupnily správnou webovou službu pouze autorizovaným žadatelem.

Jak určíme sadu přihlašovacích údajů, která umožňuje zabezpečené vyvolání webových služeb: Standardizované prostředky pro žadatele obchodních služeb k bezpečnému vyvolání webových služeb se správnou sadou ověřování, autorizace a oprávnění.

Jak bezpečně federujeme webové služby: Standardní způsob, jak podnikům umožnit přímé poskytování služeb zákazníkům registrovaným v jiných (partnerských) firmách nebo institucích. V rámci federace služeb může firma získat důvěryhodné informace o uživateli z domovské organizace uživatele (nebo služby poskytující informace). Firma nemusí registrovat a udržovat identitu daného uživatele a uživatel nemusí získat nové přihlášení a pamatovat si ho, aby mohl komunikovat s firmou.

Jak povolíme mezi podniky a mezidoménovými vztahy důvěryhodnosti: Standardní způsob, jak vytvořit a odrážet vztah důvěryhodnosti mezi organizacemi. Toto je klíčový problém pro federované služby.

Jak povolíme mapování federovaných identit a atributů: Dobře pochopitelné mechanismy a postupy pro mapování důvěryhodných informací o cizím uživateli (např. uživatelům z obchodních partnerů) na ověřovací a autorizační informace použitelné stávajícími službami podniku.

Jak povolíme zabezpečené a spolehlivé transakce: Standardní způsob výměny zpráv v zabezpečeném, spolehlivém a transakčním kontextu. Předchozí specifikace (např. WS-ReliableMessaging a WS-Transaction) poskytují podporu spolehlivé výměny zpráv a obchodních transakcí. V tomto dokumentu probereme podporu federovaného zabezpečení.

IBM, Microsoft a naši partneři mají v úmyslu spolupracovat se zákazníky, partnery a standardy a vyvíjet zde popsané specifikace a zajistit, aby se tato specifikace dobře shodovala s dalšími prvky architektury webových služeb. Abychom zajistili interoperabilitu a konzistentní implementaci různých navrhovaných specifikací popsaných v tomto dokumentu, IBM, Microsoftu a našich partnerů, úzce spolupracovali se standardy organizací, komunitou vývojářů a s průmyslovými organizacemi, jako jsou WS-I.org, s cílem vyvíjet profily a testy interoperability, které poskytnou pokyny pro dodavatele nástrojů.

Vzhledem k tomu, že terminologie se liší mezi technologiemi, tento dokument definuje několik termínů, které lze konzistentně použít v různých formátech a mechanismech zabezpečení. Proto se zde použitá terminologie může lišit od jiných specifikací a je definována tak, aby čtenář mohl namapovat termíny na preferovaný slovník. Projděte si Terminologie části souhrnu těchto termínů a jejich definice a použití.

1 Úvod a motivace

Správa federovaných identit představuje významnou výzvu pro jednotlivce i firmy. Tato kapitola se zabývá problémem, identifikuje strany, které se jí týkají, a dokončí klíčové cíle pro realizovatelná řešení.

Co je problém se správou federovaných identit?

Síť hodnot společnosti zahrnuje mnoho organizací, systémů, aplikací a obchodních procesů. Několik různých složek tvoří tuto hodnotovou síť, včetně zákazníků, zaměstnanců, partnerů, dodavatelů a distributorů. Neexistuje žádná jedna entita nebo společnost, která by vymýšlila centrální správu nebo řízení informací o identitě o jejích složkách v této komplexní hodnotové síti. Dokonce i v rámci jedné společnosti může existovat několik autoritativních zdrojů dat identity, které je potřeba spravovat nezávisle a nezávisle v rámci organizačních jednotek.

Tento přístup k centralizaci jako základního návrhu na spolupráci napříč společnostmi přináší značné třecí plochy v oblasti elektronické spolupráce, integrace a automatizace, což vede k vysokým nákladům na správu identit a snížení efektivity. Při centralizaci jsou náklady na správu životního cyklu identit uživatelů velmi vysoké. Většina firem musí spravovat identity zaměstnanců, obchodních partnerů a zákazníků. Kromě toho se vztahy mezi firmou a těmito osobami mění poměrně často a každá změna vyžaduje administrativní akci.

V některých případech by firmy chtěly odvést některé funkce zabezpečení stranám, které spravují identitu (jak to dnes dělají pro společnosti s platebními kartami v transakčních kontextech), ale nemohou to provést ze dvou důvodů: zaprvé neexistují žádní poskytovatelé identity třetích stran, kteří obsluhují trhy jiné než spotřebitelské finanční transakce, a za druhé, neexistují žádné modely obchodních a odpovědnosti, které by mohly bezpečně spoléhat na služby jiného poskytovatele identity než jiné služby než poskytovatele identity třetí strany. spotřebitelských finančních transakcí.

Ostatní firmy chtějí využívat identity, které udržují, aby umožnily další obchodní interakce. Vytvoření mechanismů důvěryhodnosti, které umožní federování entit napříč obchodními hranicemi, je však obtížné. Firmy, které spravují identitu stále častěji, jsou ohroženy poškozením pověsti nebo regulační odpovědností, pokud jejich akce správy identit uvolní nebo používají informace způsobem, který je v konfliktu s individuálními právy na ochranu osobních údajů. To výrazně zvyšuje riziko správy identity.

Z pohledu jednotlivce existuje více identit, osobních i profesionálních. Jednotlivec má také problém se správou identit způsobený nemožností znovu používat identity.

Správa federovaných identit zajišťuje flexibilitu mezi firmami a umožňuje společnostem snížit zatížení a zjednodušit náklady na správu identit. To umožňuje společnostem sledovat cíle obchodní integrace, které nejlépe odpovídají jejich obchodnímu modelu, zásadám IT a cílům a požadavkům na zásady správného řízení a zabezpečení.

Kdo má problém se správou federovaných identit?

Hlavní integrační bariérou je integrace mezi společnostmi kvůli nedostatku zabezpečených komunikačních modelů. Problém se týká široké škály společností, mezi které patří:

  • Střední a velké organizace, které používají informace o identitě k poskytování služeb spotřebitelům (například poskytovatelům webových cestovních služeb).
  • Střední a velké organizace, které spolu obchodují, a potřebují vyměňovat si informace o identitách jednotlivců (například letecké společnosti a půjčovny aut, nemocnice a poskytovatel zdravotní pojištění).
  • Organizace, které potřebují integrovat obchodní aplikace v rámci podniku a hodnotový řetězec zákazníků a dodavatelů (např. dodavatelský řetězec) a potřebují autorizovat své zaměstnance k provádění transakcí jménem organizace.
  • Organizace, které odsoudí služby, jako je personální oddělení a výhody, na třetí strany, ale na tyto služby uplatňují své vlastní značky (například organizace, která svým zaměstnancům poskytuje více možností plánu vyřazení nebo zdravotnického plánu prostřednictvím vlastního interního portálu personálního oddělení) a které proto musí sdílet informace o identitě zaměstnanců s poskytovateli služeb.
  • Organizace (zprostředkovatelé, zprostředkovatelé, agregátory), jejichž obchodní model je řízen "vlastnictvím zkušeností zákazníků" z důvodů neintermediace.
  • Organizace, které poskytují integrované obchodní portály řízené identitou na základě identity (finanční služby, pojišťovací služby, předplatné atd.) agregací služeb napříč několika poskytovateli třetích stran.

Jak jsme si poznamenali dříve, jednotlivci zapojení do webových aktivit také trpí tímto problémem, že obvykle mají velký počet nezávislých identit, které musí vytvořit a spravovat.

Cíle

Primární cíle federovaných služeb identit jsou následující:

  • Snížení nákladů na správu identit snížením duplicit úsilí; identita každého jednotlivce je téměř vždy spravovaná důvěryhodnou organizací (například bankou, zaměstnavatelem nebo lékařem jednotlivce).
  • Využijte práci, kterou už tito stávající správci identit provedli, tím, že ostatním stranám poskytnete přístup (podle potřeby a s odpovídající ochranou osobních údajů) k příslušným informacím o identitě.
  • Zachovejte autonomii všech stran – volbu ověřovací technologie manažera identity by neměla uplatňovat na strany, které se spoléhají na informace o identitě. Volba operačního systému nebo síťového protokolu nebo databáze správce identit by neměla svým partnerům ukládat stejnou volbu.
  • Respektujte stávající struktury důvěryhodnosti a kontrakty firmy. Registrace k získání informací o identitě od zprostředkovatele identity nesmí vyžadovat, aby organizace vytvořila vztah důvěryhodnosti s žádnou jinou stranou než s poskytovatelem identity a nesmí vyžadovat přijetí žádné konkrétní technologie ověřování uživatelů.
  • Chraňte soukromí jednotlivců tím, že respektujete a důrazně vynucujete předvolby uživatelů, které řídí používání individuálně identifikovatelných informací, sledováním pravidel státní a regionální ochrany osobních údajů, hledáním souhlasu uživatele pro nové použití a implementací silných mechanismů pro uchovávání záznamů a odpovědnost, aby se zajistilo, že budou dodrženy postupy ochrany osobních údajů.
  • Stavět na otevřených standardech, aby bylo možné zabezpečit spolehlivé transakce pro firmy a jednotlivce.

2. Federované jednotné přihlašování a správa identit

Odvolání federací spočívá v tom, že mají uživateli umožnit bezproblémovou procházení různých lokalit v rámci dané federace. Tento dokument se zaměřuje konkrétně na problém správy federovaných identit a ne na větší problém obecné federace (nad rámec zabezpečení). Vzhledem k vztahům důvěryhodnosti vytvořeným mezi účastníky federace je jeden účastník schopen ověřit uživatele a pak jednat jako vydávající strany tohoto uživatele. Ostatní účastníci federace se stanou předávající strany. To znamená, že spoléhají na informace, které poskytuje o uživateli vydávající strana bez přímého zapojení uživatele. V některých případech může být uživatel anonymní předávající straně, například z důvodu různých mechanismů ověřování a použití ověřovacích mechanismů třetích stran.

Flexibilita a odvolání modelu webových služeb je základem stavebního bloku, kde společnosti mohou snadno vytvářet nové služby pro poskytování inovativních obchodních modelů nebo propojit síť hodnotového řetězce efektivněji prostřednictvím užších vztahů s partnery, dodavateli, zákazníky a zaměstnanci. Takový model může být úspěšný pouze v případě, že umožňuje zákazníkům, partnerům a koncovým uživatelům snadno přecházet mezi weby podporujícími tyto služby, aniž by se museli neustále ověřovat nebo identifikovat na různých webech nebo redundantně udržovat osobní údaje u každého člena v rámci podnikové federace.

Aktuální schémata pro ověřování uživatelů a získávání informací o atributech uživatelů (např. informace o platební kartě) obvykle vynucují, aby se uživatel registroval v každém zájmu, a neustále vyžaduje, aby se uživatel identifikoval a ověřil (obvykle s uživatelským jménem a heslem) a vynutil firmě správu velkého a rychle se měnícího základu identit, které nejsou pod kontrolou společnosti. Takový model je obrovskou překážkou pro přijetí webových služeb - a je bolest hlavy pro uživatele i firmy.

Další nevýhodou převládaného modelu je, že daná firma může být nechtěná dát část informací o zákazníce obchodnímu partnerovi, který chce místo toho zachovat a řídit vztah zákazníka.

Federace poskytují jednoduchý flexibilní mechanismus pro identifikaci a ověřování uživatelů z partnerských organizací a zajištění bezproblémového přístupu k webům v rámci důvěryhodné federace bez nutnosti opětovného ověřování pomocí hesla. Kromě toho se standardy federace zabývají také tím, že poskytují důvěryhodné atributy (např. certifikáty X509, certifikáty atributů X509v3, tokeny Kerberos, kontrolní výrazy SAML) o uživatelích (např. role a informace o skupinách), které umožňují ochranu osobních údajů a pravidla specifická pro firmy.

Koncept a pojmy federovaného jednotného přihlašování a identit je možné znázornět pomocí jednoduchého příkladu:

Uživatel John Doe pracuje pro farmaceutickou společnost s názvem Pharma456.com; Jan má účet s Pharma456.com a vyžaduje se k ověření pro Pharma456.com pro přístup k prostředkům. Jako zaměstnanec má Jan určité výhody se společností, jako jsou účty a služby v partnerských společnostech. V tomto příkladu jsou úsporové služby společnosti spravovány firmou finančních služeb, která se nazývá RetireAccounts.com (poskytovatel služeb) a investiční služby spravuje firma s názvem InvestAccounts.com (poskytovatel služeb). Pokud chcete získat přístup k prostředkům u partnera, například portál úspor hostovaný RetireAccounts.com, musí se uživatel ověřit v RetireAccounts.com. Ověření na RetireAccounts.com vyžaduje, aby uživatel uvedl číslo sociálního pojištění (SSN), identifikátor zaměstnance (jedinečný identifikátor vydaný zaměstnavatelem – v tomto případě Pharma456.com) a osobní PIN číslo (specifické pro RetireAccounts.com).

Bez federace se John Doe musí explicitně ověřit na RetireAccounts.com webu, aby získal přístup ke svému účtu úspory, i když se již ověřil na Pharma456.com a přistupoval k webovým službám RetireAcounts.com prostřednictvím portálu pro zaměstnance Pharma456.com.

S federovaným jednotným přihlašováním se ale John Doe může přihlásit k portálu svého zaměstnance, kliknutím na odkaz na portál získat přístup k informacím o účtu úspory z partnerského webu (RetireAccounts.com) a nemusí se znovu ověřit nebo poskytnout další informace na partnerském webu.

Federace také zajišťuje, aby jedinečné identity pro stejného uživatele napříč společnostmi mohly být bezpečně propojené mezi dvěma společnostmi pomocí federovaných technik správy. Účastníci federace můžou vyměňovat informace o identitě tak, aby předávající společnost nezávisle ověřila identitu uživatele v rámci své domény.

Federované jednotné přihlašování mezi vydávající doménou (Pharma456.com) a předávající doménou (poskytovatel federovaných služeb RetireAccounts.com) usnadňuje zabezpečený a důvěryhodný přenos identifikátorů uživatelů a dalších informací souvisejících s atributy (například autorizační role a členství ve skupinách a uživatelská oprávnění, jako jsou EmployeeID, SSN a PIN #). Správa federovaných identit definuje proces, pomocí kterého může předávající strana (RetireAccounts.com) určit místně platný identifikátor uživatele na základě (důvěryhodných) informací přijatých od vydávající strany. Podrobnosti o přenosu můžou zahrnovat více zpráv mezi firmou a podnikem původu uživatele (a zprávami do pomocných služeb), ale tyto zprávy jsou pro uživatele zpracovávány transparentně.

Abychom umožnili federaci, zavádíme zprostředkovatele identity, služby atributů a pseudonymní služby, které jsou znázorněny na výše uvedeném obrázku.

Zprostředkovatelé identity, jako jsou poskytovatelé identit v Pharma456.com, InvestAccounts.com a RetireAccounts.com, poskytují identity, které se používají pro místní mapování a indexování (např. informace o účtu). Díky mechanismům důvěryhodnosti a federace společně se zásadami důvěryhodnosti umožňují tyto identity automaticky sdílet a mapovat identity federace.

Služby atributů poskytují způsob, jak federovat přístup k autorizovaným atributům pro federované identity. V předchozím příkladu, protože John Doe navštíví portál každého partnera, může služba portálu přistupovat k atributům Johna (těch, kterým je autorizována), aby získala požadované informace a přizpůsobila prostředí. Pro zajištění ochrany osobních údajů má John Doe úplnou kontrolu nad tím, které atributy mají oprávnění ke kterým službám. Tyto přístupy k atributům je možné monitorovat a protokolovat, aby se zajistilo dodržování uvedených zásad ochrany osobních údajů vytvořených u zaměstnanců Pharma456.com. Nepovolujeme konkrétní typ služby atributů, ale místo toho povolíme použití různých služeb, jako je UDDI.

Mechanismy důvěryhodnosti poskytují způsob, jak předávající strany přidružit úroveň důvěryhodnosti k autoritě nebo identitě a použít ji pro místní mapování. Existují však situace, kdy obavy ohledně ochrany osobních údajů chtějí, aby toto mapování bylo neprůžné pro cílovou službu. Cíl tedy konzistentně ví, že je "John Doe" založený na místní osobě Johna, ale nerozumí ani nezná globální identitu. Pseudonymní služby poskytují mechanismus mapování, který lze použít k usnadnění tohoto mapování důvěryhodných identit napříč federacemi za účelem ochrany osobních údajů a identity.

Správa federovaných identit (včetně federovaného jednotného přihlašování) je mnohem širší koncept než řešení jednotného přihlašování k webu. I když tento příklad zvýrazňuje případ použití pro scénář B2C, kdy je jednotné přihlašování k webu důležitou funkcí, federované jednotné přihlašování je širší koncept, který firmám umožňuje vytvořit kompletní architekturu pro zabezpečení B2B a B2C e-business.

3. Model federované identity

Model federované identity vychází a integruje infrastrukturu webových služeb a specifikace zabezpečení, které tvoří konzistentní a rozšiřitelný model zabezpečení. Model federace rozšiřuje model WS-Trust a popisuje, jak zprostředkovatelé identity fungují jako služby tokenů zabezpečení a jak lze atributy a pseudonymy integrovat do mechanismu vystavování tokenů, aby poskytovaly mechanismy mapování federovaných identit.

In summary, principals sign-in and sign-out of Identity Providers (or security token services). Můžete to provést prostřednictvím explicitních zpráv nebo implicitně jako tokeny žádostí o objekty zabezpečení. Instanční tokeny požadavků na prostředky nebo služby a vystavené tokeny mohou buď představovat primární identitu objektu, nebo nějaký pseudonym odpovídající rozsahu. Zprostředkovatel identity (nebo stS) vydává zprávy zúčastněným (a autorizovaným) příjemcům. Instanční objekty jsou registrovány s atributem/pseudonymy a atributy a pseudonymy jsou přidány a používány. Služby mohou zadávat dotazy na atributy a pseudonymní služby pomocí poskytnutých identit (potenciálně anonymní, což znamená, že strana žádající o informace má neprůhlásný token a nezná skutečnou identitu) k získání autorizovaných informací o identitě.

Specifikace zabezpečení webových služeb

Model a přístup popsaný v tomto dokumentu využívají specifikace popsané v dokumentu white paper, Zabezpečení ve světě webových služeb: Navrhovaná architektura a plán. Každý z klíčových specifikací je shrnutý níže:

  • WS-Security popisuje, jak připojit hlavičky podpisu a šifrování ke zprávám SOAP. Kromě toho popisuje, jak připojit tokeny zabezpečení, včetně binárních tokenů zabezpečení, jako jsou certifikáty X.509 a lístky Protokolu Kerberos, ke zprávám.
  • WS-Policy představuje sadu specifikací, které popisují možnosti a omezení zásad zabezpečení (a dalších obchodních) zprostředkovatelů a koncových bodů (např. požadované tokeny zabezpečení, podporované šifrovací algoritmy, pravidla ochrany osobních údajů) a způsob přidružení zásad ke službám a koncovým bodům.
  • WS-Trust popisuje architekturu pro modely důvěryhodnosti, která umožňuje webovým službám bezpečně spolupracovat vyžádáním, vystavováním a výměnou tokenů zabezpečení.
  • WS-Privacy popisuje model, jak webové služby a žadatelé uvádějí předvolby ochrany osobních údajů a prohlášení o zásadách ochrany osobních údajů organizace.
  • WS-SecureConversation popisuje, jak spravovat a ověřovat výměny zpráv mezi stranami, včetně výměn kontextu zabezpečení a vytváření a odvozování klíčů relací.
  • WS-Federation popisuje, jak spravovat a zprostředkovávat vztahy důvěryhodnosti v heterogenním federovaném prostředí, včetně podpory federovaných identit, sdílení atributů a správy pseudonymů.
  • WS-Authorization popisuje, jak spravovat autorizační data a zásady autorizace.

Kromě toho několik dalších klíčových specifikací webových služeb dokončí základní vrstvu specifikací:

  • WS-Addressing popisuje, jak určit informace o identifikaci a adresování zpráv.
  • WS-MetadataExchange popisuje, jak vyměňovat metadata, jako jsou informace o WS-Policy a WSDL mezi službami a koncovými body.
  • WS-ReliableMessaging popisuje, jak zajistit spolehlivé doručování zpráv v přítomnosti nespolehlivých sítí.
  • WS-Transactions a WS-Coordination popisují, jak v rámci výměn zpráv webové služby povolit transakce.

Kombinace výše uvedených specifikací a profilů interoperability umožní zákazníkům snadno vytvářet interoperabilní zabezpečené spolehlivé webové služby, které se integrují v rámci federací a napříč federacemi tím, že vytvoří specifikace federace a zabezpečení s jinými specifikacemi webových služeb.

Profily

Tento dokument popisuje obecný model, který lze použít v různých prostředích. Konkrétně lze tento model použít v prostředích sestávajících z pasivních žadatele, jako jsou webové prohlížeče nebo aktivní žadatele, jako jsou žadatelé SOAP.

Specifikace federace poskytují obecný model a architekturu; profily popisují způsob použití modelu v těchto různých prostředích. Pro integraci modelu do jiných prostředí je možné zadat další profily.

Každá specifikace profilu definuje způsob použití mechanismů v WS-Federation, pokud vůbec, pro dané prostředí, jako jsou pasivní nebo aktivní žadatele.

Mechanismy popsané v tomto dokumentu (zprostředkovatelé identit, přihlášení/odhlášení, tokeny zabezpečení, atributy, pseudonymy, . . . ). ) se vztahují jak na pasivní žadatele (například webové prohlížeče), tak na aktivní žadatele (jako jsou webové služby fungující jak jako klienti, tak služby), a také na další profily, které mohou být v budoucnu definovány.

Zprostředkovatelé identit

Federace začíná pojmem identity. To znamená, že žadatel nebo delegát žadatele (zprostředkovatel identity, který je autoritativním vlastníkem těchto dat identity), ověří identitu a zprostředkovatel identity ověří tento kontrolní výraz. Federace se pak stane funkcí důvěryhodnosti (přímý, zprostředkovaný a delegovaný) mezi zprostředkovateli identit a těmi, kteří spoléhají na určení identity zprostředkovatele. Někdy přijímající strana potřebuje schopnost korelovat identity od více zprostředkovatelů – například korelaci identity při kontrole, na platební kartě a na licenci řidiče.

Služba tokenů zabezpečení (STS) je obecná služba, která vydává/vyměňuje tokeny zabezpečení pomocí běžného modelu a sady zpráv. Každá webová služba může být sama o sobě službou STS jednoduše podporou specifikace WS-Trust. V důsledku toho existují různé typy služeb tokenů zabezpečení, které poskytují různé doplňkové služby. zprostředkovatele identity identity je speciální typ služby tokenů zabezpečení, která minimálně provádí ověřování partnerských entit a může v vydaných tokenech zabezpečení vytvářet deklarace identity nebo přidružení. Všimněte si, že v mnoha případech jsou IP adresy a tokeny zabezpečení zaměnitelné a mnoho odkazů v tomto dokumentu identifikuje obojí.

Model federace vychází z architektury definované v WS-Trust pomocí mechanismu vystavování a výměny tokenů, aby zahrnoval vydávání a federování identit.

Následující příklad ukazuje možnou kombinaci IP adresy a tokenů zabezpečení pro přístup ke službě. V tomto příkladu (1) žadatel získá token zabezpečení identity ze své IP adresy (Business456.com) a pak předá kontrolní výraz (token zabezpečení) službě STS pro Fabrikam123. Pokud Fabrikam123.com důvěřuje Business456.com a autorizaci, služba STS vrátí žadateli přístupový token. Žadatel (3) pak použije přístupový token pro žádosti k Fabrikam123.com.

V tomto příkladu je odpověď v kroku 1 podepsána Business456.com (důvěryhodná IP adresa) a token zabezpečení vrácený v odpovědi je relativní k Fabrikam123.com (např. vydali ho).

Alternativní model, který je popsán níže, umožňuje službě Fabrikam123.com zaregistrovat token zabezpečení u pseudonymní služby a v případě potřeby načíst tento pseudonym. To umožňuje službě spravovat mapování a stále poskytovat úroveň ochrany osobních údajů žadateli.

Jednotné přihlašování a Sign-Out

Model popsaný v tomto dokumentu a ve specifikacích WS-Federation umožňuje různé pojmy uživatelských relací, jako jsou služby spravované a spravované žadatelem. Jedním z příkladů relace spravované službou by bylo vytvoření a správa souborů cookie v rámci relace webového prohlížeče. Příkladem relace spravované žadatelem je žadatel webové služby, který získá token a použije ho po určitou dobu a potom token před vypršením jeho platnosti zahodí. Zavádějí se pojmy odhlášení, které umožňují různým profilům určit, jak se tyto přechody vztahují na jednotlivé profily.

Účelem jednotného přihlašování je vytvořit tokeny zabezpečení potřebné pro přístup k prostředku na webu federované domény nebo sféry. Podobně federovaného odhlašování slouží k vyčištění všech stavů uložených v mezipaměti a tokenů zabezpečení, které mohou existovat v rámci federace. Aby to bylo možné, musí mechanismy poskytovat federovaným přihlašovacím zprávám vydaným zprostředkovatelem identity a odhlašování autorizovaným stranám akcí přihlášení a odhlášení (což jim umožní provádět potřebné akce nastavení a čištění).

Atributy a pseudonymy

Jak jsme už probírali, je potřeba mít možnost získat informace o identitě (nebo jakémkoliv federovaného prostředku), například poskytnutí pozdravu "hello" nebo získání PSČ žadatele pro přizpůsobení prostředí – a to může poskytnout služba atributů. Tato specifikace umožňuje použití různých typů služeb atributů, jako je UDDI.

Tyto informace se řídí autorizačními pravidly a sémantikou ochrany osobních údajů. Podobně se očekává, že různé atributy budou sdíleny odlišně a mají různé stupně ochrany osobních údajů a ochrany (např. jméno vs. příjmení). V důsledku toho by měl být každý výraz atributu schopný vyjádřit vlastní zásady řízení přístupu a zásady by měly brát v úvahu přidružené obory a objekty zabezpečení, které můžou mluvit pro rozsahy. Koncový uživatel (osoba) může například chtít nastavit následující: "Moje služby v intranetu můžou mít přístup k mému příjmení, zatímco ostatní služby nemůžou bez výslovného oprávnění od mě".

Služba atributů může využívat existující úložiště a může poskytovat určitou úroveň organizace nebo kontextu. V rámci oboru názvů organizace se zaregistrují jednotlivé objekty zabezpečení a sada vlastností atributů (v podstatě dvojice name/value, kde název je název řetězcové vlastnosti a hodnota je element XML) reprezentované v xml objektu zabezpečení jsou přidruženy k objektu zabezpečení.

Je důležité si uvědomit, že každý atribut může mít vlastní pravidla autorizace zabezpečení a zásady ochrany osobních údajů, což objektům zabezpečení umožňuje řídit, komu a jak jsou informace zpřístupněny.

Různé služby atributů mají různé možnosti, které jsou vyjádřeny v dokumentu zásad.

Kromě služeb atributů mohou existovat i pseudonymní služby. Pseudonymní služba umožňuje instančnímu objektu mít různé aliasy v různých prostředcích/ službách nebo v různých doménách nebo sférách. Někteří zprostředkovatelé identity používají v tokenech zabezpečení pevné identity. V některých scénářích je žádoucí zajistit anonymizu tokenů; pseudonymy poskytují mechanismus pro umožnění této anonymizie. Často existuje kompromis mezi spravovatelností, kterou musí určit hlavní objekt (tj. čím více identit, tím větší potenciál pro problémy správy).

Je třeba poznamenat, že v některých případech bude atribut a pseudonymní služby sloučeny a v některých případech budou samostatné služby.

Žadatel se například ověří v Business456.com s primární identitou Fred.Jones. Nicméně, v Fabrikam123.com, on je známý jako "Freddo". Aby se zachovala anonymizace, může Business456.com vydat jinou identitu pokaždé, když se Fred.Jones přihlásí, takže se zobrazí "anonymní", jak je znázorněno v kroku 3 na obrázku níže. Fabrikam123.com může nastavit "Freddo" jako místní název tohoto žadatele na Fabrikam123.com (krok 4) a mít pseudonymní službu, která rozumí anonymnímu jménu, zadejte mapování na "Freddo".

Při příštím přihlášení žadatele k Business456.com IP adrese (krok 1 níže) může mít nový identifikátor, například "XYZ321@Business456.com" (krok 2 níže). Vzhledem k tomu, že Business456.com IP adresa obsahuje mapování uvedené výše, webová služba v Fabrikam123.com teď může požádat o pseudonym pro XYZ321@Business456.com v Fabrikam123.com (krok 4 níže) a získat zpět, co dříve nastavili – v tomto případě je to "Freddo@Fabrikam123.com" (krok 5 níže).

Pseudonymní služba to dokáže, protože má schopnost back-mapovat "XYZ321@Business456.com" do známé identity v Business456.com, která k ní přidružuje pseudonymy pro různé domény a sféry. K tomuto zpětnému mapování dochází na základě vztahu důvěryhodnosti mezi IP adresou a pseudonymní službou. Podobně existuje vztah důvěryhodnosti mezi prostředkem a pseudonymní službou (pravděpodobně zaváděcí ip adresou), která umožňuje, aby byl zdroj autorizovaný k získání a nastavení pseudonymů.

Případně může zprostředkovatel identity (nebo STS) pracovat ručně s pseudonymní službou. To znamená, že žadatel požádá svého zprostředkovatele identity (neboli TOKENY) o token na zadanou doménu důvěryhodnosti, doménu, sféru nebo prostředek nebo službu. Služba tokenů zabezpečení hledá pseudonymy a vydává token, který lze použít v zadaném prostředku nebo službě, jak je znázorněno níže:

Jak je znázorněno, v tomto modelu federované identity je podporováno několik různých přístupů, ve kterých se pseudonymy dají použít k zajištění ochrany osobních údajů. Každá má různé charakteristiky spravovatelnosti a ochrany osobních údajů, což každému poskytovateli a instančnímu objektu umožňuje zvolit vhodné řešení, které splňuje jeho konkrétní požadavky.

4 Souhrn

V tomto dokumentu navrhujeme integrovaný model federace webových služeb, který umožňuje stranám vydávat informace od ostatních členů federace a spoléhat se na ně a na zprostředkování důvěryhodnosti a atributů napříč federacemi zabezpečeným způsobem, který udržuje individuální a obchodní soukromí.

Tento model se integruje se zabezpečením webových služeb a souvisejícími specifikacemi, které umožňují zabezpečené spolehlivé transakce mezi žadateli a službami v rámci federací a napříč federacemi.

IBM a Microsoft věří, že je to důležitý krok při definování komplexní strategie zabezpečení webových služeb.  Odráží výzvy a řešení, které jsme zatím identifikovali. Vzhledem k tomu, že nadále spolupracujeme se zákazníky, partnery a organizacemi standardů na zabezpečení webových služeb, očekáváme, že budou k dokončení strategie potřeba další nápady a specifikace. 

Terminologie

Vzhledem k tomu, že terminologie se liší mezi technologiemi, tento dokument definuje několik termínů, které lze konzistentně použít v různých formátech a mechanismech zabezpečení. Proto se zde použitá terminologie může lišit od jiných specifikací a je definována tak, aby čtenář mohl namapovat termíny na preferovaný slovník.

pasivní prohlížeč – pasivní prohlížeč je prohlížeč HTTP, který podporuje široce podporovaný protokol HTTP (např. HTTP/1.1).

aktivního žadatele – aktivní žadatel je aplikace (pravděpodobně webový prohlížeč), která může vydávat zprávy webových služeb, jako jsou zprávy popsané v WS-Security a WS-Trust.

profil – profilu je dokument, který popisuje způsob použití tohoto modelu na konkrétní třídu žadatele (např. pasivní nebo aktivní).

deklarace identity – deklarace identity je deklarace vytvořená entitou (např. název, identita, klíč, skupina, oprávnění, schopnost, atribut atd.).

token zabezpečení – token zabezpečení představuje kolekci deklarací identity.

podepsaný token zabezpečení – podepsaný token zabezpečení je token zabezpečení, který se uplatňuje a kryptograficky podepisuje konkrétní autoritou (např. certifikát X.509 nebo lístek Kerberos).

důkaz o vlastnictví - důkazem o vlastnictví je ověřovací data, která jsou k dispozici se zprávou, která potvrzuje, že byla zpráva odeslána nebo vytvořena deklarovanou identitou.

tokenu pro ověření vlastnictví – důkazem o vlastnictví je token zabezpečení, který obsahuje data, která může odesílající strana použít k předvedení důkazu o vlastnictví. I když ne výhradně, informace o vlastnictví jsou šifrovány klíčem známým pouze odesílateli a přijímajícím stranám.

digest – digest je kryptografický kontrolní součet oktetového datového proudu.

podpis – podpis je hodnota vypočítaná kryptografickým algoritmem a vázána na data tak, aby zamýšlení příjemci dat mohli podpis použít k ověření, že data nebyla od podpisu podepsána podpisem.

služba tokenů zabezpečení (STS) – služba tokenů zabezpečení je webová služba, která vydává tokeny zabezpečení (viz WS-Security a WS-Trust). To znamená, že provádí kontrolní výrazy založené na důkazech, že důvěřuje, komu důvěřuje. Ke komunikaci důvěryhodnosti vyžaduje služba důkaz, například token zabezpečení nebo sadu tokenů zabezpečení, a vydává token zabezpečení s vlastním prohlášením o důvěryhodnosti (všimněte si, že u některých formátů tokenů zabezpečení to může být jenom opětovné vystavení nebo spolu podpis). To tvoří základ zprostředkování důvěryhodnosti.

Atribut Service – služba atributu je webová služba, která udržuje informace (atributy) o instancích v rámci sféry důvěryhodnosti nebo federace. Instanční objekt výrazu v tomto kontextu se dá použít na libovolnou systémovou entitu, nejen na osobu.

pseudonymní služba – pseudonymní služba je webová služba, která udržuje alternativní informace o identitě objektů zabezpečení v rámci sféry důvěryhodnosti nebo federace. Instanční objekt výrazu v tomto kontextu se dá použít na libovolnou systémovou entitu, nejen na osobu.

vztah důvěryhodnosti - důvěryhodnosti je charakteristické, že jedna entita je ochotná spoléhat na druhou entitu k provedení sady akcí a/nebo k provedení sady kontrolních výrazů o sadě subjektů a/nebo oborů.

důvěřovat doméně – doména důvěryhodnosti je spravovaný prostor zabezpečení, ve kterém zdroj a cíl požadavku může určit a odsouhlasit, jestli konkrétní sady přihlašovacích údajů ze zdroje vyhovují příslušným zásadám zabezpečení cíle. Cíl může odložit rozhodnutí o důvěryhodnosti třetí straně, a to včetně důvěryhodné třetí strany v doméně důvěryhodnosti.

ověřovací služba – ověřovací služba je webová služba, která používá mechanismy WS-Trust k ověření poskytnutých tokenů a posouzení jejich úrovně důvěryhodnosti (např. deklarací důvěryhodných).

přímý vztah důvěryhodnosti - přímý vztah důvěryhodnosti je, když předávající strana přijme jako true všechny (nebo podmnožinu) deklarací identity v tokenu odeslaném žadatelem.

direct brokered trust - Direct Brokered Trust je, když jedna strana důvěřuje druhé straně, která zase důvěřuje nebo vouchá, deklarace identity třetí strany.

nepřímý zprostředkovaný vztah důvěryhodnosti - nepřímý zprostředkovaný vztah důvěryhodnosti je varianta přímého zprostředkovaného vztahu důvěryhodnosti, kde druhá strana nemůže okamžitě ověřit deklarace identity třetí strany a vyjednává s třetí stranou nebo dalšími stranami, aby ověřila deklarace identity a posoudila důvěryhodnost třetí strany.

ověřování zpráv - ověřování zpráv je proces ověření, že přijatá zpráva je stejná jako zpráva odeslaná.

ověřování odesílatele - ověřování odesílatele je možné ověřit ověřovací důkazy, které znají odesílatele zprávy webové služby (a jeho přidružená data). Upozorňujeme, že pokud existují ověření zprostředkovatelé, může zpráva obsahovat více odesílatelů. Všimněte si také, že je závislá na aplikaci (a mimo rozsah), pokud jde o to, kdo nejprve vytvořil zprávy jako původce zprávy, může být nezávislý na ověřeném odesílateli nebo skrytý za ověřeným odesílatelem.

sféra nebo domény – sféra nebo doména představuje jednu jednotku správy zabezpečení nebo důvěryhodnosti.

federace – federace je kolekce sfér/domén, které navazovaly vztah důvěryhodnosti. Úroveň důvěryhodnosti se může lišit, ale obvykle zahrnuje ověřování a může zahrnovat autorizaci.

zprostředkovatel identity - zprostředkovatel identity je entita, která funguje jako služba ověřování partnerských entit koncovým uživatelům a ověřovací službě zdroje dat na poskytovatele služeb (obvykle se jedná o rozšíření služby tokenů zabezpečení).

jednotné přihlašování - jednotného přihlašování je optimalizace pořadí ověřování, aby se odstranila zátěž opakujících se akcí umístěných na koncovém uživateli. Aby se usnadnilo jednotné přihlašování, může element označovaný jako zprostředkovatel identity fungovat jako proxy jménem uživatele, aby poskytl důkazy o událostech ověřování třetí strany požadující informace o uživateli. Tito zprostředkovatelé identity jsou důvěryhodní třetí strany a musí být důvěryhodní jak uživatel (aby se zachovaly informace o identitě uživatele, protože ztráta těchto informací může vést k ohrožení identity uživatelů) a webovým službám, které můžou udělit přístup k cenným prostředkům a informacím na základě integrity informací o identitě poskytovaných IP adresou.

mapování identit - mapování identit je metoda vytváření relací mezi vlastnostmi identity. Někteří zprostředkovatelé identity můžou využít mapování ID.

odhlášení – odhlášení je proces, kterým jsou tokeny zabezpečení zničeny pro sféru nebo doménu nebo federaci.

přidružení - přidružení je proces, kterým se objekty zabezpečení přidružují nebo přidružují k sférě důvěryhodnosti nebo federaci.

Přispěvatelů

Tento dokument společně vytvořil IBM a Microsoft.

Mezi klíčové přispívání patří (abecedně): Giovanni Della-Libera, Microsoft; Brendan Dixon, Microsoft; Mike Dusche, Microsoft; Don Ferguson, IBM; Praerit Garg, Microsoft; Tim Hahn, IBM; Heather Hinton, IBM; Maryann Hondo, IBM; Chris Kaler, Microsoft; Frank Leymann, IBM; Brad Lovering, Microsoft; Hiroshi Maruyama, IBM; Anthony Nadalin, IBM; Nataraj Nagaratnam, IBM; Venkat Raghavan, IBM; John Shewchuk, Microsoft

Odkazy

© 2001-2003 International Business Machines Corporation, . Všechna práva vyhrazena.

Jedná se o předběžný dokument, který může být v průběhu času podstatně změněn. Informace obsažené v tomto dokumentu představují aktuální pohled společnosti International Business Machine a Microsoft Corporation na otázky popsané k datu zveřejnění. Vzhledem k tomu, že SPOLEČNOST IBM a Microsoft musí reagovat na měnící se tržní podmínky, neměla by být interpretována jako závazek na straně IBM a Microsoftu a společnost IBM a Microsoft nemohou zaručit přesnost jakýchkoli informací uvedených po datu zveřejnění.

Prezentace, distribuce nebo jiné šíření informací obsažených v tomto dokumentu není licence, ať už výslovně nebo implicitně, jakékoli duševní vlastnictví vlastněné společností IBM nebo Microsoft a\nebo jakoukoli jinou třetí stranou.  IBM, Microsoft a/nebo jakákoli jiná třetí strana mohou mít patenty, patentové aplikace, ochranné známky, autorská práva nebo jiná práva duševního vlastnictví, která se týkají předmětu tohoto dokumentu.  Vybavení tohoto dokumentu vám neudělí žádnou licenci na patenty, ochranné známky, autorská práva ani jiné duševní vlastnictví společnosti IBM ani Microsoft ani jiné třetí strany. Ukázkové společnosti, organizace, produkty, názvy domén, e-mailové adresy, loga, lidé, místa a události, které jsou zde znázorněny, jsou fiktivní.  Žádná asociace se skutečnou společností, organizací, produktem, názvem domény, e-mailovou adresou, logem, osobou, místy nebo událostmi je zamýšlená nebo by měla být odvozena.

Tento dokument a informace uvedené v tomto článku jsou poskytovány na základě "AS IS" a v maximálním rozsahu povoleném platnými zákony, IBM a Microsoft poskytují dokument AS IS A WITH ALL FAULTS, a tímto zřeknou všechny ostatní záruky a podmínky, ať už výslovné, implicitní nebo zákonné, včetně, ale nikoli omezené na žádné (pokud nějaké) předpokládané záruky, povinnosti nebo podmínky prodejnosti, vhodnosti pro určitý účel, přesnosti nebo úplnosti odpovědí, výsledků, pracovního úsilí, nedostatku virů a nedostatku nedbalosti, veškerého s ohledem na dokument. ROVNĚŽ NEEXISTUJE ŽÁDNÁ ZÁRUKA ANI PODMÍNKA NÁZVU, TICHÉHO UŽÍVÁNÍ, TICHÉHO VLASTNICTVÍ, KORESPONDENCE K POPISU NEBO NON-INFRINGEMENT JAKÝCHKOLI PRÁV DUŠEVNÍHO VLASTNICTVÍ V SOUVISLOSTI S DOKUMENTEM.

V ŽÁDNÉM PŘÍPADĚ SPOLEČNOST IBM NEBO MICROSOFT NEBUDE ZODPOVĚDNÁ ZA ŽÁDNÉ JINÉ STRANY ZA NÁKLADY NA POSKYTOVÁNÍ NÁHRADNÍHO ZBOŽÍ NEBO SLUŽEB, ZTRÁTY ZISKU, ZTRÁTY VYUŽITÍ, ZTRÁTY DAT NEBO JAKÉKOLI NÁHODNÉ, NÁSLEDNÉ, PŘÍMÉ, NEPŘÍMÉ NEBO ZVLÁŠTNÍ ŠKODY, AŤ UŽ NA ZÁKLADĚ SMLOUVY,RTY, ZÁRUKY NEBO JINAK, VZNIKLÉ JAKÝMKOLI ZPŮSOBEM MIMO TUTO NEBO JAKOUKOLI JINOU SMLOUVU TÝKAJÍCÍ SE TOHOTO DOKUMENTU, ZDA TATO STRANA PŘEDEM ZAZNAMENALA MOŽNOST TĚCHTO ŠKOD.