Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- cs:archive:cesnet_aa [2015/01/13 12:27] – [Atributová autorita] upřesnění jop@cesnet.cz
+++ cs:archive:cesnet_aa [2015/01/14 19:22] (aktuální) – odstraněno po přesunutí jop@cesnet.cz
@@ Řádek 1: / Řádek 1: @@
-====== Atributová autorita CESNETu ======
-FIXME Po doladění přesunout do menu //O federaci//.
-===== Úvod =====
-CESNET provozuje řadu podpůrných aplikací pro zaměstnance, řešitele projektů a další externě spolupracující osoby. Tyto aplikace často vyžadují autentizaci a také určitý soubor uživatelských atributů, jejichž zdrojem je uživatelská databáze CESNETu (LDAP). Znamená to, že kromě zaměstnanců sdružení CESNET se do této databáze ukládají i účty externích spolupracovníků z jiných organizací, včetně jejich autentizačních údajů (hesla).
-S příchodem české národní akademické federace identit eduID.cz přibyla možnost federovaného přístupu k aplikacím. Uživatel přistupující k aplikaci je přesměrován na přihlašovací stránku své domovské organizace, která provádí autentizaci a poskytuje základní uživatelská data pro cílovou aplikaci. Vzhledem ke skutečnosti, že řada aplikací v síti CESNET vyžaduje specifické uživatelské atributy nad rámec atributů z domovské organizace, které jsou k dispozici pouze v uživatelské databázi atributové autority CESNETu, je potřeba zkombinovat federovanou autentizaci s možností získat tato dodatečná uživatelská data z databáze atributové autority.
-===== Atributová autorita =====
-Ve federacích identit založených na standardu SAML (Security Assertion Markup Language) poskytuje Identity Provider (IdP) dvě služby:
-  * autentizaci uživatelů,
-  * vydávání uživatelských atributů.
-Tyto dvě služby jsou nejčastěji poskytovány zároveň v okamžiku přihlášení uživatele. Na druhou stranu může Identity Provider fungovat jako samostatná tzv. atributová autorita -- v režimu, kdy na dotaz poskytuje pouze uživatelské atributy; avšak neřeší předchozí autentizaci uživatele, kterou zajišťuje Identity Provider z domovské organizace uživatele.
-Znamená to, že daná aplikace může využít určitého Identity Providera pro autentizaci a pak získat dodatečné uživatelské atributy z jiného Identity Providera, který působí jako atributová autorita. Konkrétně v případě aplikací v síti CESNET -- uživatel se k aplikaci přihlásí pomocí svého domovského Identity Providera a aplikace pak získá další potřebné uživatelské atributy dotazem do atributové autority CESNETu.
-Atributová autorita jinými slovy umožňuje, aby se k uživatelskému účtu z libovolné organizace (např. ČVUT v Praze) přiřadily další uživatelské atributy (např. členství v nějakých skupinách). Je tedy možné vytvořit uživatelské skupiny tvořené uživateli z různých organizací a tedy různých Identity Providerů. Tyto skupiny je možné následně používat pro řízení přístupu ve službách využívajících federované přihlašování. Například můžete vytvořit skupinu lidí z různých univerzit a přiřadit je do skupiny administrátorů webové stránky.
-===== Virtuální organizace =====
-Všechny aplikace vyžadující data z atributové autority CESNETu budou sdruženy do tzv. virtuální organizace, která bude mít vlastní záznam v metadatech. Cílem je, aby Identity Provideři domovských organizací pracovali s touto entitou jako celkem. Za běžných okolností vydává Identity Provider pro každou aplikaci různý uživatelský identifikátor (name identifier). V případě virtuální organizace vydává Identity Provider uživatelský identifikátor společný pro celou virtuální organizaci, tj. pro všechny aplikace z této virtuální organizace. Na základě tohoto uživatelského identifikátoru atributová autorita CESNETu vyhledá data příslušného uživatele a vydá jeho uživatelské atributy aplikaci (z virtuální organizace), která o ně požádala.
-===== Podpora u domovských organizací =====
-==== Hlavní požadavky ====
-Pro využití atributové autority v rámci domovské organizace z české akademické federace identit eduID.cz je potřeba splnit následující požadavky:
-  * implementovat podporu pro atribut storedId
-  * používat Shibboleth Identity Provider verze 2.2 nebo vyšší (s přihlédnutím k [[https://wiki.shibboleth.net/confluence/display/SHIB2/SecurityAdvisories|bezpečnostním oznámením]])
-=== Implementace storedId ===
-Identity provider musí implementovat tzv. stored ID data connector, který generuje a ukládá netransparentní uživatelské identifikátory pro každou žadatelskou aplikaci zvlášť. Stored ID data connector standardně využívá SQL databázi pro ukládání vygenerovaných hodnot, ale v podstatě je možné použít libovolný způsob generování a ukládání dat, pokud budou splněny následující podmínky:
-  * je netransparentní -- nelze z jeho hodnoty odvodit identitu uživatele
-  * je //targeted// -- pro každého žadatele má jinou hodnotu
-  * je persistentní -- hodnota pro daného uživatele se v čase nemění
-=== Shibboleth IdP 2.2+ ===
-Shibboleth Identity Provider od verze 2.2 umí pracovat s virtuální organizací (tj. skupinou aplikací, Service Providerů neboli SP) jako celkem. V tomto případě aplikace (SP), která se dotazuje na uživatelské atributy, zároveň v dotazu uvede, že je členem dané virtuální organizace. Identity Provider pak vybere uživatelský identifikátor, který přísluší dané virtuální organizaci, nikoli konkrétní aplikaci. Pro kontrolu, zda aplikace opravdu patří do virtuální organizace, nahlíží Identity Provider do metadat, kde je tato virtuální organizace definována a kde jsou uvedeni všichni členové (aplikace neboli SP).
-Tato funkcionalita je automatická a pokud Identity Provider správně implementuje stored ID data connector, není potřeba do konfigurace nijak zasahovat.