1 Bakgrund och syfte

1.1 Övergripande beskrivning

Auktorisation innebär behörighetskontroll, det vill säga att kontrollera vad en identifierad aktör kan/får göra/utföra samt kontrollera ifall en aktör är behörig att ta del av information eller använda en funktion (resurs). En resurs kan till exempel vara en e-tjänst eller ett API.

Aktörer definieras inom byggblocket Identitet som människor, organisationer och smarta saker. Inom ramen för den digitala infrastrukturen agerar människor främst i rollen som (externa) konsumenter av information och tjänster. Organisationer och smarta saker kan agera både som konsumenter och producenter av information och tjänster.

Beslutet att ge en aktör åtkomst till en resurs ligger hos resursägaren. En behörighetskontroll bör göras när aktör vill få tillgång till en resurs och vilken behörighetskontroll som bör göras är beroende av vilken resurs aktören vill få tillgång till.

Tillgång till aktuell behörighetsinformation är centralt för kontrollera om en aktör ska få tillgång till, och vilken typ tillgång till, en digital tjänst.

För att enskilda resursägare ska kunna göra en behörighetskontroll behövs möjligheter att inhämta attribut om aktören som ska ligga till grund för beslutet att tillåta åtkomst eller inte.

I de fall aktören är en människa kan behörighetsattribut vara:

• Identitetrelaterade
• Uppdragsrelaterade,
  • grunddata, till exempel vilken funktion eller roll en användare har inom ett företag
  • anställning, till exempel vilken roll eller vilka uppdrag en medarbetare har blivit tilldelad av sin arbetsgivare
• Ombudsrelaterade, till exempel om användaren är ombud för ett företag

Klicka här för att förstora bilden "Attributförsörjning"

Exempel på olika fall när människor eller organisationer behöver auktoriseras och olika källor för behörighetsgrundande information.

1.2 Scenarion

Inom byggblocket har fem generella scenarion för åtkomsthantering identifierats.

1. Användare använder e-tjänst - en slutanvändare nyttjar en webbtjänst via webbläsare hos tjänsteproducenten.
2. Användare anropar API via konsumentsystem - en slutanvändare nyttjar ett konsumerande system (till exempel ett verksamhetssystem eller mobilapplikation), vilket i sin tur nyttjar ett API hos tjänsteproducenten.
3. Användare agerar ombud och använder e-tjänst – en slutanvändare agerar ombud (ställföreträdare eller fullmaktsinnehavare) för någon och använder en E-tjänst hos tjänsteproducenten.
4. Användare agerar ombud och anropar API via konsumentsystem – en slutanvändare agerar ombud för någon i ett konsumentsystem, vilket i sin tur nyttjar ett API hos tjänsteproducenten.
5. System anropar API under egen identitet - Ett konsumerande system nyttjar ett API hos tjänsteproducenten och har antingen ingen inloggad användare till hands eller behöver inte exponera användaren för tjänsteproducenten då åtkomst baseras på organisationstillit.

1.3 Målbild

Visionen för byggblocket är att det ska vara enkelt och säkert att genomföra en behörighetskontroll av en aktör som vill använda en tjänst inom den digitala infrastrukturen.

Inom den digitala infrastrukturen ska det vara:

• Enkelt att hitta information om hur man ansluter och ansluta tjänster till infrastrukturen
• Enkelt att ingå avtal med andra aktörer eftersom avtalsstrukturer finns färdiga
• Enkelt att förstå vilken åtkomstpolicy som gäller för att nyttja en tjänst inom infrastrukturen
• Enkelt att integrera med andra aktörer då man arbetar med standardiserade lösningsmönster samt delar tillitsramverk
• Enklare och billigare att utveckla nya och förvalta redan befintliga tjänster tack vare standardiserad infrastruktur

För att nå målbilden har byggblocket tagit fram ett antal värdeerbjudanden.

1.3.1 Värdeerbjudanden (BMC)

En översiktstavla enligt modellen Business Model Canvas (BMC) Länk till annan webbplats. har tagits fram för att visualisera och tydliggöra byggblockets olika värdeerbjudanden för aktuella kundsegment

Klicka här för att förstora bilden "BMC"

Värdeerbjudanden inom byggblock auktorisation:

1. Säker auktorisation av människor
   • Privatpersoner
   • Medarbetare inom offentlig sektor
   • Ombud
2. Säker auktorisation av organisationer
3. Vägledning om attributsförsörjning vid elektronisk auktorisation

1.3.2 Värdekartor (VPC)

Varje värdeerbjudande i BMC-modellen kan detaljeras i en s.k. värdekarta (Value Proposition Canvas, VPC Länk till annan webbplats.). Värdekartan beskriver hur ett visst värdeerbjudande består av produkter och tjänster inom byggblocket som matchar behov hos ett visst kundsegment som är identifierat för byggblocket.

Klicka här för att förstora bilden "VPC - person"

För att underlätta för organisationer att auktorisera användare i sina e-tjänster behövs likriktning inom den digitala infrastrukturen. Idag förekommer många olika sorters behörighetsinformation, till exempel personliga, uppdragsrelaterade eller avtalade. Det leder till att integrationer kan behöva göras med flera andra aktörer, som använder sig av olika tekniska lösningar och avtalsstrukturer.

Klicka här för att förstora bilden "VPC - organisation"

Aktörer inom den digitala infrastrukturen behöver kunna auktorisera andra organisationer, vilket på samma sätt som för auktorisation av människor kan innebära att man behöver ingå avtal med flera olika parter samt skapa integrationer mot olika tekniska lösningar.

Klicka här för att förstora bilden "VPC - attributförsörjning"

För att kunna genomföra en säker auktorisation av både personer/individer och organisationer behövs väl strukturerad och tillförlitlig behörighetsinformation. Inom den digitala infrastrukturen kommer med stor sannolikhet mycket av informationen vara distribuerad. Det innebär att det behövs tydlig vägledning i form av riktlinjer, regelverk och standarder, om hur digitala tjänster ska försörjas med behörighetsgrundande information.

1.3.3 Leveranser nu och inom två år:

1. Åtkomstpolicyer
   Struktur för hur en tjänsteproducent kan beskriva villkor och krav som gäller för att en aktör ska få nyttja en specifik tjänst inom Ena
2. Målbild auktorisationstjänster inom Ena
   Hur ska olika aktörers auktorisationstjänster kunna inhämta behörighetsstyrande attribut och samverka med andra auktorisations- och legitimeringstjänster.
3. Målbild för attributtjänster för eID för medarbetare
   Hur ska behörighetsstyrande attribut hanteras för medarbetare
4. Målbild för nationella attributkällor
   Identifierade nationella attributkällor som behövs för att digitala tjänster ska kunna uppfylla sin åtkomstpolicy
5. En referensarkitektur med väl beskrivna lösningsmönster för identifierade scenarion.
   • Användare använder e-tjänst
   • Användare anropar API via konsumentsystem
   • Användare agerar ombud och använder e-tjänst
   • Användare agerar ombud och anropar API via konsumentsystem
   • System anropar API under egen identitet
     
   • Referensarkitekturen behövs för att uppnå
     • Interoperabilitet
     • Skalbarhet
     • Flexibilitet
   • Referensarkitekturen är till för att både konsumenter och producenter få stöd i utvecklingen av nya, eller integrationer mellan redan etablerade, tjänster.
6. En eller flera behörighetsfederationer. Syftet är att federationerna ska hålla reda på information om alla tekniskt anslutna parter. De ska även hjälpa medlemmar att identifiera och auktorisera andra aktörer, och kan även innehålla den information som krävs för att etablera teknisk anslutning.

På längre sikt ser också ut att finnas behov av

• Stöd för anonymisering och pseudonymisering
• Att öppna upp delar av den digitala infrastrukturen för privat sektor

1.4 Målgrupper

Målgrupper för byggblock Auktorisation är:

1. offentlig förvaltning (primär målgrupp)
2. privatpersoner och företag som användare
3. leverantörer, däribland privata och offentliga eID-utfärdare
4. förlitande aktörer/parter inom privat sektor

1.5 Införandestrategi

Ett införande skulle kunna ske i tre steg, först förvaltningsgemensam arkitektur och specifikationer för att uppnå interoperabilitet, sedan federationstjänster för att ytterligare underlätta för aktörer att integrera med varandra och till slut etablera förvaltningsgemensamma auktorisationstjänster för små aktörer eller inom en eller flera sektorer.

1.5.1 Referensarkitektur

Första steget för att börja etablera en förvaltningsgemensam infrastruktur för auktorisation blir att ta fram en referensarkitektur och definiera vilka specifikationer/protokoll som ska användas. För varje specifikation/protokoll behövs även en nationell profil för att uppnå interoperabilitet.

Referensarkitekturen möjliggör att aktörer inom infrastrukturen kan etablera egna auktorisationslösningar och uppnå interoperabilitet med andra aktörer.

Klicka här för att förstora bilden "Konceptuell arkitektur"

Byggblocket har tagit fram en konceptuell arkitektur för att visa hur det är möjligt att realisera identifierade scenarion. Den konceptuella arkitekturen omfattar redan befintlig nationell infrastruktur och nya tjänster som behöver ingå i ett auktorisationsflöde.

• Åtkomstpolicy, tjänsteproducenten för en digital tjänst beskriver vilka egenskaper som användaren behöver för att nyttja tjänsten
• Åtkomstintygstjänst, samlar in beslutsunderlag om användaren och utfärdar åtkomstintyg som sedan tjänstekonsumenten använder vid anrop till en digital tjänst
• Regelverkstjänst, kan användas för att utvärdera insamlade attribut enligt den digitala tjänsten åtkomstpolicy. Kan vara en del av åtkomstintygstjänsten
• Attributtjänster, behövs för att åtkomstintygstjänsten ska kunna samla in underlag för beslut

Den konceptuella arkitekturen behöver kompletteras med vilka standarder som ska användas för respektive lösningsmönster och skapa nationella riktlinjer hur dessa standarder ska användas.

1.5.2 Federation

För att förenkla för aktörer att etablera auktorisationslösningar kan infrastrukturen tillhandahålla stödtjänster, tex att tillhandahålla ett metadataregister över ingående aktörers systemidentiteter. Ett sådant metadataregister kan användas för att upprätta en federation av ingående tjänster, både konsument-, producent- och auktorisationstjänster.

Tack vare en federation med gemensamma regelverk och tekniska specifikationer kan tillit mellan två aktörer som ska utbyta information uppnås.

Klicka här för att förstora bild "Federation"

Utifrån den organisationstillit som finns samt vilka lagar och avtal som ger ramarna för informationsutbytet behöver tjänsteproducenten ta fram en åtkomstpolicy, dvs vilka krav som gäller för att tjänstekonsumenten får använda tjänsten. Åtkomstpolicyn bestämmer vilket underlag för åtkomst som behövs.

För att uppnå interoperabilitet mellan aktörer behöver övergripande åtkomstpolicyer etableras inom infrastrukturen och utifrån behoven ta fram tekniska lösningsmönster som kan användas som underlag för åtkomst för respektive policy.

Exempel på lösningar för underlag för åtkomst

• Certifikat
• Åtkomstintyg – delegering
• Åtkomstintyg – intygsväxling
• Åtkomstintyg – propagering

1.5.3 Förvaltningsgemensamma tjänster

Inom federationen skulle förvaltningsgemensamma auktorisationstjänster kunna etableras. Dessa tjänster skulle i första hand vara lämpliga för små aktörer som inte har möjlighet att etablera en egen auktorisationstjänst enligt framtagen referensarkitektur. Tjänsteproducenten skulle i dessa fall kunna lita på ett åtkomstintyg från en förvaltningsgemensam auktorisationstjänst.

Förvaltningsgemensamma auktorisationstjänster skulle även kunna etableras inom en specifik sektor där behoven av åtkomststyrande attribut sammanfaller.

1.6 Avgränsningar

Byggblockets specifikationer kommer att fokusera på nationella profiler och undvika att ta in sektorsspecifika behov, däremot ska de nationella profilerna kunna användas som grund för sektorspecifika lösningar.