1. Inledning

Digital samverkan avser den praktiska tillämpningen – där två eller flera aktörer utbyter information digitalt med stöd av gemensamma lösningsmönster och etablerade standarder. Fokus ligger på att möjliggöra säker och interoperabel informationsdelning mellan olika organisationer. För att skapa en enhetlig och återanvändbar grund bygger digital samverkan på internationellt vedertagna protokoll. Genom nationell profilering och vägledning anpassas dessa till offentlig sektors behov och krav, vilket möjliggör samverkan med hög grad av interoperabilitet mellan olika aktörer Digitala samverkan möjliggör därmed att e-tjänster, intygstjänster, attributkällor och API:er kan kopplas samman i dynamiska och automatiserade flöden – där tillit, interoperabilitet och säkerhet är inbyggda egenskaper.

Digital samverkan utgör tillsammans med tillitshanteringen och federationsinfrastrukturen en sammanhängande helhet där informationsutbyten mellan parter sker med stöd av den tekniska infrastrukturen och det ramverk för tillit som tillitshanteringen beskriver.

Mönster och specifikationer för hur förmedling av IAM-relaterad information (såsom uppgift om identitet och behörighet) ger en förutsägbarhet i hur digital samverkan mellan organisationer går till. Detta förenklar anpassning av tjänster och möjliggör exempelvis tydlig kravställning vid upphandling och standardiserade komponenter.

Exakta krav kvarstår att utforma, men nedan listas några exempel på krav som kan ställas på en organisation:

1. Registrerad hos Skatteverket
2. Har ansvarsförsäkring
3. Har ledningssystem för informationssäkerhetsarbete
4. Processer för säkerhetsgranskning, kodhantering, patchhantering, incidenthantering, m.m. efterlevs och kan påvisas genom dokumentation.
5. Årlig IT-revision genomförs
6. Uppfyller överenskomna tekniska standarder och profiler
7. Har avsatta resurser för löpande förvaltning av anslutna tekniska komponenter

De tekniska kraven är olika beroende på vilka förmågor som erbjuds av en viss komponent man ansluter till federationsinfrastrukturen. Gemensamt för alla är att man har en adekvata tekniska förmågor att hantera kryptografiskt material och att behandla överförda personuppgifter och annan skyddsvärd information. Därefter kan det komma att skilja sig beroende på om komponenten agerar som API-klient, E-tjänst, eller API-producent. Man kan också ansluta komponenter som erbjuder funktionalitet för till exempel e-legitimering, attributförsörjning, eller åtkomstbeslut. För dessa komponenter kan det ställas helt andra krav.

Åtkomstbeslut baseras på identitet på konsumerande system och dess anslutning till dels federationsinfrastrukturen, dels den specifika samverkan (jmfr T2:s informationsfederationer). Åtkomst kan också baseras på åtkomsstyrande attribut för den användare som orsakat åtkomstbegäran.

I efterföljande bilder detaljeras identifierade samverkansmönster och vilka krav de tillgodoser. I dessa bilder utelämnas federationsinfrastrukturen och komponenters interaktioner med den för att säkerställa tillit.

2. Mönster 

Nedan presenterar vi på konceptuell nivå de olika identifierade mönstren för för samverkan över organisationsgränser. Exakt hur tillits-, identitets- och behörighetshantering kan realiseras för de olika mönstren beskrivs i de profileringar och rekommendationer som kommer tas fram under det fortsatta arbetet (se kapitel 4 nedan för referens).

2.1. Medarbetare anropar annan organisations e-tjänst, utan förprovisionerade användaruppgifter

1. Medarbetare öppnar E-tjänsten
2. Medarbetaren väljer att legitimera sig emot sin uppdragsgivares IdP
3. E-tjänsten redirectar medarbetaren till tjänsteproducentens åtkomstintygstjänst
4. Åtkomsintygstjänsten tar ett åtkomstbeslut baserat på medarbetarens attribut som beskriver roller och uppdrag medarbetaren har i sin uppdragsgivare organisation, och eventuellt andra attributkällor som åtkomstintygstjänsten har tillgång till.

2.2. Medarbetare anropar annan organisations e-tjänst, med förprovisionerat användarkonto

1. Medarbetare öppnar E-tjänsten
2. Medarbetaren väljer att legitimera sig emot en IdP som stödjer medarbetarens e-tjänstelegitimation
3. E-tjänsten redirectar medarbetaren till tjänsteproducentens åtkomstintygstjänst
4. Åtkomsintygstjänsten tar ett åtkomstbeslut baserat på det förprovisionerade kontot för medarbetaren

2.3. System anropar system i annan organisation under egen identitet

I detta mönster delegerar tjänsteproducenten åtkomsthantering till tjänstekonsumentens API-klient. 

• Klient begär åtkomst baserat på sin egen identitet från åtkomstintygstjänsten
• Klienten och dess organisationstillhörighet behöver finnas registrerad i federationsinfrastrukturens metadata

2.4. System anropar system på uppdrag av invånare

• Invånare legitimerar sig mot klienten via en IdP som stödjer användarens e-legitimation
• Klienten begär åtkomst och bifogar invånarens identitet som beslutsunderlag
• Åtkomstintygstjänsten tar åtkomstbeslut till APIet baserat på klientens identitet och tar beslut om den specifika resursen som anropas baserat på invånarens identitet.

2.5. System anropar system på uppdrag av medarbetare

1. Medarbetare legitimerar sig mot klienten via sin uppdrgasgivares medarbetar-IdP
2. Medarbetare ges åtkomst till klienten via sin uppdragsgivares åtkomstintygstjänst, vilken inhämtar åtkomststyrande attribut från en attributkälla - detta gäller de attribut som inte följde med från legitimeringen.
3. Klienten begär delegerad åtkomst till ett externt API å medarbetarens vägnar. Åtkomstbegäran görs mot tjänsteproducentens åtkomstintygstjänst och medarbetarens åtkomststyrande attribut ligger till grund för åtkomstbeslutet.

3.  Hur fungerar Samordnad identitet och behörighet ihop med dagens autentiseringslösningar baserade på SAML

Stora investeringar har gjorts i autentiseringslösningar som bygger på protokollet SAMLv2. Det är nödvändigt att dessa investeringar ska kunna användas även inom ramen för Samordnad identitet och behörighet, med mönster som visar hur detta ska göras för autentisering av e-tjänster men även för API-åtkomst.

SAMLv2 är ett vida spritt protokoll för autentisering av e-tjänster och är standardiserad i dagens federationer för inloggning, till exempel Sambi , Skolfederationen och Sweden Connect. Även eIDAS bygger på SAMLv2. 

Många av de identitetsintygstjänster som har stöd för SAMLv2 har även stöd för out-of-band autentisering, det vill säga autentisering sker via en separat kanal, vilket i praktiken ofta innebär autentisering sker via en mobil bärare.

Investeringarna i dessa lösningar har gjorts för att i möjligaste mån konsolidera all autentisering av användare till en tjänst som i sin tur har en attributkälla som verksamheten har kontroll över. Denna attributkälla är den viktigaste basen för livscykelhantering av användare, åtkomst till e-tjänster och åtkomsträttigheter. Oavsett om den använda identitetsintygstjänsten och attributkällan är lokalt driftsatta tjänster eller molnbaserade tjänster, är det verksamhetens ansvar att attributkällan har korrekta uppgifter.

Samordnad identitet och behörighet erbjuder en federation som ska fungera för autentisering av e-tjänster men även för API-åtkomst, främst i andra organisationer. 

Från verksamhetens perspektiv utkristalliserar det sig tre användningsfall där samma identitetsintygstjänst med protokollet SAMLv2 ska kunna användas.

3.1. Inloggning i den egna organisationens e-tjänster

3.2. Inloggning i andra organisationers e-tjänster

3.3. API-åtkomst hos en annan organisations API

E-tjänsten i organisation A har behov av information i organisation B via dess API och begär därför ett åtkomstintyg. Bilden är en förenkling då åtkomstintyget som utfärdas i organisation A inte kan användas direkt. Det viktiga är dock att organisation As auktorisationsserver bryggar över till organisationens SAML IdP genom att uppträda som SP mot IdP:n. 

Nedan följer ett sekvensdiagram som mera i detalj beskriver interaktionerna i användningsfallet.

4. Profiler och specifikationer

De tekniska specifikationerna för digital samverkan – inklusive attributprofiler, flödesbeskrivningar och policyrekommendationer – kommer göras tillgängliga i Samordnad identitet och behörighets öppna dokumentation på GitHub: https://github.com/ena-infrastructure/specificationsi takt med att de tas fram.