Finns det behov av att kunna signalera eller verifiera att en viss kravställd nivå av tillit är uppfylld vid en specifik samverkan?

Hur ska detta ske? Genom återanvänding eller utökning av befintliga standards, alternativt out-of-band lösningar.

Scenarion eller exempel som kan användas som underlag till en diskussion kring vilka behov som finns och varför....


Scenario - Slutanvändare via e-tjänst som konsumerar ett API (tjänst) från annan organisation

Slutanvändaren skulle kunna vara från samma eller från en annan organisation än den som tillhandahåller/ansvarar för e-tjänsten. Därmed finns det i scenariot minst två, men kanske tre organisationer som behöver samverka och det behöver finnas adekvat tillit mellan organisationerna.

Fokus för detta scenario kommer att vara på den det API som e-tjänsten konsumerar som en del av användarens inloggade åtkomst, dvs "delegerad åtkomst".

Vad som krävs för åtkomst till API:et regleras av åtkomstpolicyn och innan åtkomst kan ges behöver API:et säkerställa att den är uppfylld och frågan som behöver besvaras är:

På vilket sätt (hur) kan API:et säkerställa att dess åtkomstpolcy är uppfylld avseende dess krav?


Namnlöst diagram-1761040676551

Problembeskrivning

Exempel:

  • En tjänsteproducent bjuder en tjänst som hanterar mycket känsliga personuppgifter vill kunna kräva dels att legitimering av slutanvändare skett på LOA-nivå 3 och att den behörighetsgrundande information som bifogas åtkomstbegäran kommer från en attributkälla med Ena tillitsnivå 4 och endast hanterats av komponenter som innehar Ena tillitsnivå 4.
  • En tjänstekonsument använder en SaaS-SAML-IdP (LoT3) för legitimering av sina medarbetare och en SaaS-AS (LoT4) med integration mot sitt personalsystem för att hämta behörighetsgrundande information (LoT3).
  • Nu kommer det en åtkomstbegäran för en medarbetare till tjänsteproducentens AS. Åtkomstbegäran innehåller en authorization grant utsälld av SaaS-ASen.
  • Kan ASen identifiera att den mycket kompetenta och tillitsfulla LoT4-ASen som stämplat inkommande grant förmedlat behörighetsgrundande från en LoT3-attributkälla (personalsystemet) och därmed vägra åtkomst?


Lösryckta reflektioner

  • Alternativ 1: Man kräver att en teknisk komponent med viss tillitsnivå endast tillåts integreras med andra komponenter med minst samma tillitsnivå. En aktör behöver då skapa parallella instanser med olika digitala identiteter om de vill sin komponent i sammanhang med bakomliggande komponenter med lägre tillitsnivå.
  • Alternativ 2: Man inför ett nytt claim i åtkomstbegäran som signalerar en tillitsnivå för begäran. Signalerad tillitsnivå kan vara lägre än tillitsnivån för den begärande komponenten.
  • Alternativ 3: Man återanvänder OIDC-claimet acr (Authentication Context Class Reference) och låter den komponent som tillför behörighetsgrundande attribut kopplade till den autentiserade identiteten kan sätta acr på authorization grant och sen på access token. 
  • Alternativ 4: Utan teknisk verifierbarhet hos den tänkta mottagaren, och bygger då istället på att avsändande part känner till och respekterar åtkomstpolicyn. Det vill säga att om man litar på den part som är avsändare så kan man även lite på att innehållet motsvarar eventuella krav på nivå etc. Ställer då rimligen krav på det omvända, dvs hur kan åtkomstpolicy spridas till alla parter, vem har då vilket ansvar och hur regleras det "mjukare" istället.


  • No labels