Ena IAM - Pilot
Sammanfattning
Denna Proof of Concept (POC) syftar till att praktiskt testa och demonstrera hur en federativ infrastruktur enligt OpenID Federation-modellen kan realiseras för digital samverkan mellan organisationer. Fokus ligger på att visa hur en användare i Organisation A genom ett it-system kan anropa ett skyddat API i Organisation B, med säkerhets- och tillitsinformation som förmedlas via federationsinfrastrukturen.
Pilotens komponenter byggs upp enbart för testmiljön. Det handlar alltså inte om en skarp pilot med riktiga aktörer i en produktionsmiljö, utan om en teknisk modell för att verifiera arkitektur, flöden och specifikationer.
Tabellen nedan beskriver de användningsfall (AF) som piloten omfattar. Varje användningsfall dokumenteras med:
- en kort beskrivning av vad som sker i steget,
- POC-kriterier för att bedöma om steget lyckats,
- en lista över ingående komponenter och ansvariga aktörer,
- de lösningsmönster och specifikationer som används,
- samt eventuella kommentarer som förklarar avgränsningar eller särskilda testfall.
Tillsammans visar användningsfallen hela kedjan: från användarens inloggning i Systemet (AF 1), via generering och verifiering av åtkomstunderlag (AF 2–3.1), till att ett API i en annan organisation både kan verifiera access token och säkerställa att klienten är en giltig federationsmedlem (AF 4–4.1).
Användningsfall
Federationsinfrastruktur
| Användningsfall | Beskrivning | POC-kriterier | Ingående komponenter (ansvarig aktör) | Lösningsmönster & Specifikationer | Kommentar |
|---|---|---|---|---|---|
| FI010 – Metadatapublicering | En Tillitsankartjänst (Trust Anchor) publicerar och signerar sitt federation metadata statement. | Säkerställa att metadata kan publiceras, distribueras och signaturen verifieras av andra parter. | Tillitsankartjänst (Trust Anchor) – Federationsoperatör | OpenID Federation 1.0, Entity Statements (Entity Configuration, Trust Chain) | Grund för teknisk tillit i federationen. |
| FI020 – Metadataförmedling | En Anslutningstjänst (Intermediate Entity) agerar länk mellan Tillitsankartjänst och underordnade entiteter (OP, RP, API:er). Den kan även applicera lokala policies. | Validera att Anslutningstjänst korrekt kan hämta metadata från Tillitsankartjänst, applicera policy och vidareförmedla metadata. | Anslutningstjänst (Intermediate Entity) – Anslutningsoperatör | OpenID Federation 1.0, Policy claims, Authority Hints | Möjliggör skalbarhet och delegerad tillit. |
| FI030 – Metadatauppslag och verifiering | En Uppslags- och verifieringstjänst (Resolver) kan hämta metadata för en entitet genom att bygga en trust chain från Tillitsankartjänsten. | Kontrollera att trust chain kan byggas korrekt (top-down/bottom-up), signaturer verifieras och metadata returneras komplett. | Uppslags- och verifieringstjänst (Resolver) – Operatör eller leverantör | OpenID Federation 1.0, Authority Hints, Trust Chain Resolution | Avlastar digitala tjänster från komplex verifieringslogik. |
| FI040 – Tillitsmärkeshantering | En Tillitsmärkestjänst (Trust Mark Issuer) utfärdar tillitsmärken som styrker att en entitet uppfyller definierade tillitsskapande krav. | Säkerställa att tillitsmärken är signerade, giltiga och verifierbara enligt policy. | Tillitsmärkestjänst (Trust Mark Issuer) – Tillitsoperatör | OpenID Federation 1.0, Trust Marks (JWT), Policykrav | Bygger policybaserad tillit inom federationen. |
Digital samverkan
| Användningsfall | Beskrivning | POC-kriterier | Ingående komponenter (ansvarig aktör) | Lösningsmönster & Specifikationer | Kommentar |
|---|---|---|---|---|---|
| DS001 – Inloggning i system (MCSS) | En användare loggar in i System A via en legitimeringstjänst (SAML IdP). Resultatet är en aktiv inloggningssession i System A | Säkerställa att SAML-inloggning fungerar och att sessionen etableras. | Legitimeringstjänst (IdP – Org A) System A (MCSS – Org A) | SAML 2.0, Single Sign-On | Grundförutsättning för federativ åtkomst. |
| DS002 – Lokal auktorisation & SSO | Klient interagerar med en lokal auktorisationstjänst för att fastställa användarens behörigheter. SSO återanvänder sessionen mot IdP för andra system. | Verifiera att lokal auktorisation fungerar och att SSO-sessionen kan återanvändas. | Auktorisationstjänst (Org A) Legitimeringstjänst (IdP – Org A) System A (MCSS) | OIDC/OAuth2 (Access Token, ID Token), SAML SSO | Möjliggör lokal policytillämpning och SSO-flöde. |
| DS003 – Åtkomstbegäran till annan organisation | System A begär åtkomstintyg från Organisation B:s auktorisationstjänst för att få åtkomst till resurs i B:s miljö. | Kontrollera att Organisation B:s auktorisationstjänst kan utfärda och returnera giltigt intyg som System A kan validera. | Auktorisationstjänst (Org B) Resursserver (Org B) System A (Org A) | OIDC/OAuth2 Token Exchange, JWT Grants | Möjliggör system-till-system-samverkan över organisationsgränser. |
| DS004 – Metadatahantering via federationsinfrastruktur | Metadata för IdP, RP och auktorisationstjänster hanteras via OIDF-federationskomponenter. I piloten används Internetstiftelsens Resolver, Tillitsankartjänst, Tillitsmärkestjänst och Anslutningstjänst. Batch-jobb integrerar mot Resolver för schemalagd hämtning av metadata. | Säkerställa att metadata kan hämtas, verifieras och cache:as via Resolver, och att trust chain kan valideras till Tillitsankaren. | Tillitsankartjänst (Internetstiftelsen) Anslutningstjänst (Internetstiftelsen) Tillitsmärkestjänst (Internetstiftelsen) Uppslags- och verifieringstjänst (Internetstiftelsen) | OpenID Federation 1.0, Entity Statements, Trust Chains, Trust Marks | Batch-lösningen är ett pilotval; i full drift används realtidsupplösning via Resolver. |