Beskrivning

I "Appva-spåret" i EFI-piloten ingår Appva med systemet MCSS för att integrera mot E-hälsomyndighetens system NLL. Denna sida beskriver de tekniska komponenter som ingår i piloten tillsammans med ansvarig aktör. 

För att åstadkomma API-anrop mellan System och API behöver ett vissa förutsättningar finnas och inledande steg genomföras, dessa beskrivs nedan. 

Steg 1 - Inloggning av användare i System

Användaren loggar in i MCSS. Detta sker genom en legitimationstjänst (SAML-IDP) och resulterar i att användaren har en inloggningssession i MCSS.

<utveckla resonemanget enligt appvas förutsättningar / komponenter>

Steg 2 - Interaktion med lokal auktorisationstjänst och SSO mot IDP

<utveckla resonemanget enligt appvas förutsättningar / komponenter>

Steg 3 - Begäran av åtkomstintyg från organisation B

<>

Steg 3b - Metadatahantering

I Piloten körs OIDF-infrastruktur hos Internetstiftelsen. Ett antal komponenter finns där:

• Resolver
• Trust Anchor (TA)
• Trust Mark Issuer (TMI)
• Intermediate (IM)

Batch integrerar mot Resolver för tillgång till metadata. Batch plockar regelbundet hem Ena metadata genom schemalagd körning.

De infrastrukturkomponenter (roller) som OIDF-noden innehar beskriver tillsammans ett metadata-set där relevanta delar i PoCen är beskrivna:

• AS-A är beskriven som en entitet i metadata av typen OAuth Authorization server
• AS-A har ett tillitsmärke "Tillitsmärke POC" knuten till sig 
• System är beskriven som en entitet i metadata av typen OAuth Client

Steg 4 - API-anrop mot API i organisation B

System har nu förutsättningar att utföra API-anrop mot API med åtkomstintyg som bärare av säkerhetsinformation. 

System kan nu utföra API-anrop till API och anger access token som Bearer token enligt RFCxxx. API verifierar att access token (genom signatur) är utställd (avkrypterar) av AS-B. API kontrollerar även scope. 

Beskrivning av komponenter i POC

Användare

Användare representerar själva användaren ("personen bakom tangentbordet") och den klient användaren använder (webbläsare). E-legitimation används inte i POC, utan ersätts av praktiska skäl av användare och passord. 

System

System representerar ett it-system i organisation A, som skulle kunna motsvaras av exempelvis ett journalsystem eller Pascal eller något liknande. Detta system har ett behov av att (föranlett av en aktivitet användaren utför i systemet) utföra ett API-anrop till API i organisation B. I POCen är detta en quarkus-applikation med följande funktionalitet:

• Agera webb-applikation 
• Inloggning av användare
• SAML-SP mot SAML-IDP (SAML-SP är en keycloak-instans som gör request mot SAML-IDP, quarkus-applikationen kör OAuth code-flow mot keycloak).
• Möjlighet för användare (via "knapptryck") initiera API-anrop mot API
• OAuth-klient enligt Authorization code-flow mot AS-A för att begära user-JWT
• Tillverka signerad "klient-JWT" för client authentication mot AS-B
• OAuth-klient mot AS-B för att göra åtkomstbegäran med user-JWT samt klient-autentisering med client-JWT
• API-klient mot API för att utföra API-anrop med access token som bärare av säkerhetsinformation.

SAML-IDP

Den legitimeringstjänst som användaren använder för att göra en inloggning i System. Denna legitimeringstjänst används även av AS-A (som SAML-SP) för att köra webSSO. SAML-IDPn är en instans av Keycloak konfigurerad att agera SAML-SP. Den har lokala användare konfigurerade och autentisering av Användare sker med username, password.

• Agera SAML-IDP för System
• Agera SAML-IDP för AS-A (SSO)
• Autentisering av användare med username+password
• Är beskriven i Sambi-trial metadata

AS-A

Auktorisationstjänst i organisation A. Används av System för att begära åtkomstunderlag (user-JWT) för att i nästa steg används som underlag mot AS-B för åtkomstbegäran. AS-A är en Keycloak-instans som tillhandahåller ett OAuth auth code-flow mot System. Detta initierar ett webSSO-flöde mot SAML-IDP för göra SAML AuthnRequest för att få ut en SAML Response för användaren i fråga. AS-A är i detta flöde SAML-SP mot SAML-IDP. AS-A kommer vid lyckad autentisering (antingen via SSO eller ny autentisering av användaren)

• Tillhandahålla OAuth Auth code-flow för System
• Agera SAML-SP mot göra AuthnRequest mot SAML-IDP
• Överföra relevant information i SAML Response (AttributeStatement, AuthnContextClassRef) till JWT, samt signera denna JWT med privat nyckel

AS-B

Autktorisationstjänst i organisation B. Tar emot OAuth åtkomstförfrågan (enligt RFC7523) och ställer ut access token. Quarkus-applikation med följande funktionalitet:

• Implementerar RFC7523 avseende authorization grant (user-JWT)
• Implementerar RFC7523 avseende client credentials (client-JWT)
• Whitelisting av klienter
• Kontrollerar utfärdare, signering samt tillitsmärken för user-JWT mot Ena metadata via resolver/batch.
• Kontrollerar utfärdare, signering samt tillitsmärken för client-JWT mot Ena metadata via resolver/batch.
• Tillverkar och signerar access token

API

API representerar det "skyddade API" som System vill anropa. Detta är en Java-applikation som implementerar ett enkelt REST-API. Det relevanta i POC är att den tar emot och kontrollerar accesstoken, alltså att denna är signerad/krypterad av AS-B. 

• REST-server
• Hantering/kontroll av accesstoken (Enligt RFC Bearer token)