Uživatelem spravovaný přístup - User-Managed Access

Uživatelem spravovaný přístup (UMA) je OAuth - standardní protokol pro správu přístupu. Verze 1.0 normy byla schválena Iniciativa Kantara 23. března 2015.[1]

Jak je popsáno v listině skupiny, která vyvinula UMA,[2] účelem specifikací protokolu je „umožnit vlastníkovi zdroje kontrolovat autorizaci sdílení dat a další přístup k chráněným zdrojům mezi službami online jménem vlastníka nebo se souhlasem vlastníka autonomní žádající stranou “. Tento účel má důsledky pro soukromí a souhlas pro webové aplikace a Internet věcí (IoT), jak prozkoumala sbírka případových studií od účastníků ve skupině pro standardy.[3]

Historie a pozadí

The Iniciativa Kantara Pracovní skupina UMA[4] uspořádalo své první zasedání[5] 6. srpna 2009. Principy a technický design UMA byly informovány o předchozích pracích zaměstnanců Sun Microsystems, zahájených v březnu 2008, na protokolu nazvaném ProtectServe. ProtectServe byl zase ovlivněn cíli Řízení vztahů s dodavateli pohyb a odnožová snaha zvaná feed-based VRM.

Nejstarší verze ProtectServe a UMA využily OAuth Protokol 1.0. Jelikož OAuth prošel významnou změnou vydáním specifikace Web Resource Authorization Protocol (WRAP) a následně návrhů OAuth 2.0, specifikace UMA držela krok a nyní používá rodinu specifikací OAuth 2.0 pro několik klíčových toků protokolu.

UMA nepoužívá OpenID 2.0 jako prostředek identifikace uživatele nebo na něm nezávisí. Volitelně však používá protokol OpenID Connect založený na OAuth jako prostředek ke shromažďování deklarací identity od žádající strany, aby se pokusil splnit zásady přístupu autorizujícího uživatele.

UMA také nepoužívá eXtensible Access Control Markup Language (není na něm závislý) (XACML ) jako prostředek kódování zásad uživatele nebo vyžadování rozhodnutí o zásadách. UMA nediktuje formát zásad, protože vyhodnocení zásad se provádí interně na autorizačním serveru (AS) z pohledu UMA. K implementaci zásad uvnitř AS se obvykle používá XACML. Jeho implementace je mimo rozsah UMA. Toky protokolu UMA pro vyžádání oprávnění k přístupu mají některé funkce společné s protokolem XACML.

Stav standardizace

Skupina UMA provádí svou práci v rámci iniciativy Kantara[6] a také přispěl řadou specifikací internetového návrhu do Pracovní skupina pro internetové inženýrství (IETF) jako případný domov pro normalizační práci UMA. Za tímto účelem přispěla pracovní skupina k posouzení několika individuálním internetovým návrhům IETF. Jedna z nich, specifikace pro dynamickou registraci klienta OAuth,[7] sloužil jako vstup pro obecnější mechanismus, který byl nakonec vyvinut pro OAuth.[8]

Stav provádění a přijetí

Základní protokol UMA má několik implementací,[9] včetně několika implementací open source. Mezi zdroje aktivních a dostupných implementací open-source patří ForgeRock,[10] Gluu,[11], IDENTOS Inc.,[12] MITREid Connect,[13] Atricore, Node-UMA[14], Roland Hedberg[15], Keycloak.[16] a WSO2 Identity Server.[17] Skupina Kantara Initiative pracuje na vývoji „bezplatného a otevřeného softwaru (FOSS) v několika populárních programovacích jazycích, který umožňuje vývojářům začlenit do aplikací, služeb a zařízení povolení UMA pro ochranu a autorizaci API.“[18]

Produkty podporující UMA jsou k dispozici u společnosti Gluu[19], Jericho Systems[20], ForgeRock[21], IDENTOS Inc. [22] a WSO2 Identity Server [23]

Srovnání s OAuth 2.0

Tento diagram poskytuje přehled na vysoké úrovni o entitách a vztazích zapojených do specifikace UMA.

Diagram (viz vpravo) zdůrazňuje klíčové doplňky, které UMA provádí v OAuth 2.0.

V typickém toku OAuth je vlastník lidských zdrojů (RO) provozující klientskou aplikaci přesměrován na autorizační server (AS), aby se mohl přihlásit a souhlasit s vydáním přístupového tokenu, aby klientská aplikace mohla získat přístup k serveru prostředků (RS) jménem RO v budoucnu, pravděpodobně omezeným (omezeným) způsobem. RS a AS s největší pravděpodobností fungují ve stejné bezpečnostní doméně a jakákoli komunikace mezi nimi není standardizována hlavní specifikací OAuth.

UMA přidává tři hlavní koncepty a odpovídající struktury a toky. Nejprve definuje standardizované API na AS, které se nazývá ochranné API, se kterým RS mluví; to umožňuje komunikaci více RS s jedním AS a naopak, a protože samotné API je zabezpečeno pomocí OAuth, umožňuje formální navázání důvěry mezi každou dvojicí. To také umožňuje AS prezentovat RO s centralizovaným uživatelským rozhraním. Zadruhé, UMA definuje formální představu o žádající straně (RqP), která je autonomní od RO, což umožňuje sdílení mezi stranami a delegování oprávnění k přístupu. RO nemusí souhlasit s vydáním tokenu za běhu, ale může nastavit zásadu v AS, což umožňuje RqP pokusit se o asynchronní přístup. Za třetí, UMA umožňuje pokusy o přístup k úspěšnému vydání tokenů spojených s autorizačními daty na základě procesu zvyšování důvěryhodnosti v RqP, například shromažďování deklarací identity nebo jiných deklarací z nich.

Použitelné případy použití

Architektura UMA může sloužit různým případům použití zaměřeným na spotřebitele a podniky. Skupina UMA shromažďuje případové studie na své wiki.[3]

Jeden příklad sady případů použití je v oblasti zdravotnictví v oblasti IT a zdraví spotřebitelů. V organizaci OpenID Foundation pracuje pracovní skupina s názvem Health Relationship Trust (SRDCE)[24] pracuje na „harmonizaci a vývoji souboru specifikací ochrany soukromí a zabezpečení, které jednotlivci umožní kontrolovat povolení přístupu k API pro sdílení údajů o zdraví souvisejících s RESTful“, vycházející mimo jiné z norem UMA.

Další ukázkový soubor případů použití, který původně ovlivnil vývoj UMA, je v oblasti „úložišť osobních údajů“ způsobem řízení vztahů s prodejci. V této koncepci si jednotlivec může vybrat operátora autorizační služby, který přijímá připojení od různých hostitelů digitálních prostředků orientovaných na spotřebitele, aby mohl nabídnout řídicí panel s možnostmi správy sdílení zdrojů.

Reference

  1. ^ https://kantarainitiative.org/confluence/display/LC/User+Managed+Access
  2. ^ http://kantarainitiative.org/confluence/display/uma/Charter
  3. ^ A b http://kantarainitiative.org/confluence/display/uma/Case+Studies
  4. ^ http://kantarainitiative.org/confluence/display/uma/Home UMA Work Group Wiki
  5. ^ http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes?src=contextnavchildmode Zápisy ze schůzky pracovní skupiny UMA
  6. ^ http://kantarainitiative.org/confluence/display/uma/Home
  7. ^ http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg Internetový koncept: OAuth 2.0 Dynamic Client Registration Core Protocol
  8. ^ https://tools.ietf.org/html/rfc7591
  9. ^ http://kantarainitiative.org/confluence/display/uma/UMA+Implementations
  10. ^ http://forgerock.org/openuma/
  11. ^ http://www.gluu.org/open-source/open-source-vs-on-demand/ Archivováno 09.02.2014 na Wayback Machine Implementace UMA od Gluu OSS
  12. ^ https://identos.com/ Federovaná výměna informací o ochraně osobních údajů IDENTOS Inc. (FPX)
  13. ^ https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/tree/uma[trvalý mrtvý odkaz ]
  14. ^ https://github.com/atricore/node-uma/ Atricore OSS implementace UMA pro Node.js
  15. ^ https://github.com/rohe/pyuma
  16. ^ http://www.keycloak.org/docs/4.0/release_notes/index.html
  17. ^ https://docs.wso2.com/display/IS580/User+Managed+Access
  18. ^ http://kantarainitiative.org/confluence/display/umadev/Home
  19. ^ http://www.gluu.org/gluu-server/access-management/
  20. ^ https://www.jerichosystems.com/company/pr04082015.html
  21. ^ https://www.forgerock.com/platform/user-managed-access/
  22. ^ https://identos.com/products-federated-privacy-exchange-fpe/
  23. ^ https://docs.wso2.com/display/IS580/User+Managed+Access
  24. ^ http://openid.net/wg/heart/

externí odkazy