User-Managed Access (UMA) er en standard tilgangsadministrasjonsprotokoll basert på OAuth . Versjon 1.0 av standarden ble godkjent av Kantara Initiative 23. mars 2015 [1] .
Som beskrevet i charteret til gruppen som utviklet UMA, [2] er formålet med protokollspesifikasjonen å "tillate en ressurseier å kontrollere autorisasjonen av datadeling og annen tilgang til den beskyttede ressursen mellom nettjenester på vegne av eier eller med tillatelse fra eier, fra en autonom forespørrende part". Dette formålet har personvern- og samtykkeimplikasjoner for nettapplikasjoner og tingenes internett (IoT), som utforsket av samlingen av casestudier bidratt av deltakere i standardgruppen. [3]
Kantara Initiatives UMA -arbeidsgruppe [4] holdt sitt første møte [5] 6. august 2009. UMAs designprinsipper og tekniske design var basert på tidligere arbeid fra Sun Microsystems-ansatte, som startet i mars 2008, på en protokoll kalt ProtectServe. På sin side har ProtectServe blitt påvirket av målene til Vendor Relationship Management (VRM)-bevegelsen og dens gren kalt feed-basert VRM. Tidlige versjoner av ProtectServe og UMA utnyttet OAuth 1.0-protokollen. Ettersom OAuth har gjennomgått betydelige endringer gjennom publiseringen av Web Resource Authorization Protocol (WRAP)-spesifikasjonen og, senere, OAuth 2.0-utkastet, har UMA-spesifikasjonen holdt tritt, og bruker nå OAuth 2.0-spesifikasjonsfamilien for de forskjellige strømmer. protokollnøkkelen .
UMA bruker ikke og er avhengig av OpenID 2.0 som et middel for brukeridentifikasjon. Imidlertid bruker den valgfritt den OAuth-baserte OpenID Connect-protokollen, som et verktøy for å samle inn påstander om identiteten til en forespørsel, for å forsøke å oppfylle tilgangskriteriene til den autoriserende brukeren.
Videre bruker eller er ikke UMA avhengig av eXtensible Access Control Markup Language ( XACML )-spesifikasjonen som et middel til å kode brukerautorisasjonspolicyer eller for å be om avgjørelser om autorisasjonspolicyer. UMA definerer ikke autorisasjonspolicyformatet, da evalueringen av policyene/kriteriene gjøres internt til autorisasjonsserveren, fra et UMA-perspektiv. Imidlertid har UMA-strømmer, for å be om tilgangstillatelse, noen kjennetegn til felles med XACML-protokollen.
UMA-gruppen utfører sitt arbeid under Kantara-initiativet [6] og har også bidratt med en rekke Internet-Draft-spesifikasjoner til Internet Engineering Task Force (IETF) som et mulig sted for UMAs standardiseringsarbeid. For dette formål bidro arbeidsgruppen med flere individuelle Internett-utkast til IETF for vurderinger. En av disse, en spesifikasjon for «OAuth dynamisk klientregistrering», [7] fungerte som input for den mer generaliserte mekanismen som til slutt ble utviklet for OAuth. [8]
Kjernen i UMA-protokollen har flere implementeringer, [9] inkludert flere åpen kildekode-implementeringer. Kilder til aktive og tilgjengelige åpen kildekode-implementeringer inkluderer, i alfabetisk rekkefølge, ForgeRock , [10] Gluu, [11] MITREid Connect, [12] og Roland Hedberg. [13] En arbeidsgruppe ved Kantara Initiative jobber med utviklingen av "fri og åpen kildekode-programvare (FOSS), på forskjellige programmeringsspråk, som lar utviklere bygge inn UMA-sikkerhets- og autorisasjons-APIer i applikasjoner, tjenester og enheter" [14 ]
UMA-aktiverte produkter er tilgjengelige fra Gluu [15] og Jericho Systems [16] og kommer fra ForgeRock.
Diagrammet (se til høyre) fremhever de store forbedringene UMA gjør i OAuth 2.0. I en typisk OAuth-flyt blir en (menneskelig) ressurseier (RO) som opererer på en klientapplikasjon, omdirigert til en "autorisasjonsserver" (AS) for å få tilgang til og samtykke til utstedelse av et "tilgangstoken" som klienten kan bruke. få tilgang til ressursserveren (RS) på vegne av RO i fremtiden, antagelig på en scope-begrenset måte (“ scoped ”). RS og AS vil sannsynligvis operere innenfor samme sikkerhetsdomene, og all kommunikasjon mellom dem er ikke-standardisert av OAuth-hovedspesifikasjonen.
UMA legger til tre hovedkonsepter og tilsvarende strukturer og flyter. For det første definerer den en standardisert API på AS-nivå, kalt "Protection API", som ressursserveren kan samhandle med; Dette gjør at flere RS-er kan kommunisere med et AS og omvendt, og siden API-en i seg selv er sikret med OAuth, lar den det formelle tillitsforholdet etableres mellom hvert par. Dette gjør det også mulig for AS å presentere for RO med et sentralisert brukergrensesnitt. For det andre definerer UMA en formell forestilling om "Requesting Party" (RqP)-enheten som er autonom fra en RO, som tillater en deling fra ett subjekt til en annen enhet og delegering av tilgangsautorisasjon. En RO trenger ikke å samtykke til utgivelsen av token ved kjøring, men kan sette policyer på AS, slik at en RqP kan forsøke å logge på asynkront. For det tredje lar UMA deg administrere autorisasjonsprosessen og dermed utstedelsen av tokens knyttet til autorisasjonsdata basert på en prosess for å øke tillitsnivået til RqP, for eksempel gjennom innsamling av identitetskrav eller andre kreditter direkte fra RqP.
UMA Architecture kan betjene en rekke brukstilfeller for både forbruker- og bedriftsbruk. UMA-gruppen samler casestudier i sin wiki. [3]
Et sett med eksempler på bruk er innen helsevesen og forbrukerhelse. I organisasjonen av OpenID Foundation jobber en arbeidsgruppe kalt Health Relationship Trust (HEART) [17] med å "harmonisere og utvikle et sett med sikkerhets- og personvernspesifikasjoner som lar en person kontrollere autorisasjonen av tilgang til helsedata basert på RESTful API for deling ", basert, blant andre standarder, på UMA.
Et annet sett med brukstilfeller, som opprinnelig påvirket utviklingen av UMA, er i området "personlige datalagre", basert på "Vendor Relations Management"-paradigmet. I denne oppfatningen kan en person velge en operatør av en tjeneste autorisasjon som aksepterer tilkoblinger fra en rekke forbrukerrettede digitale aktivaverter for å gi et dashbord med administrasjonsfunksjoner for aktivadeling.