Kommentar kring hantering av SAML, 

• OBS! Man kan inte bara beskriva arkitekturen utgående från OpenID Fed. Man måste på alla ställen där man hänvisar till detta, ochså beskriva komonenten utgående från SAML. Detta för att SAML är en stor del av vad som finns i dagsläget. Gäller hela dokumentet.

• Det vi har hunnit beskriva hittills och det vi beskriver här är federationsinfrastruktur för förmedling av tillitsinformation och den är baserad på OIDF. Hela arkitekturen behöver omfatta hur vi ska hantera SAML
• Inom digital samverkan avser vi beskriva mönster för hur man utifrån en legitimering i SAML-världen kan "brygga" detta till åtkomstbeslut som tas i OAuth-världen. Man behöver då dölja sina SAML-komponenter bakom komponenter som kan representeras i OIDF.
  Är det du talar om att beskriva och dela metadata för tekniska komponenter baserade på SAML genom federationsinfrastrukturen? Henric Norlander väl medveten om att beskrivningarna nedan mera passar in på digital samverkan så vill jag ändå tömma ut mina ideer kring nyttjande av SAML på denna plats.

• 
  

Beskrivning av nuläget

I "nuläget" finns det användnng av SAML för att nå de egna e-tjänsterna men även för att använda samma IdP för inloggning till andra organisationers e-tjänster. Samma IdP kan användas för att göra en intygsväxling in i Oauth2-världen. "Nuläget" kan sägas vara den situation när ehälsomyndigheten har gått över till sin senaste säkerhetslösning med SAML-intygspropagering och en Sweden Connect-IdP för inloggning till sin e-tjänst.

Andra organisationers e-tjänster hänvisar till sin egen IdP som i sin tur kan försörjas med användardata med provisionering.

Sammantaget ger det en splittrad bild av IAM-lösningarna.

Mellanläge

Då en total övergång till Oauth2 och OIDC inte är realistisk, måste det finnas förutsättngar att återanvända de SAML-IdP: som redan är realiserade.

Följande användningsfall finns beskrivna i bilden

Organisationen A har e-tjänster som använder SAML som protokoll för inloggning

Organisation As SAML-IdP kan användas för inloggning i andra organisationers e-tjänster

Organisation A har en AS som kan agera SP gentemot As SAML-IdP för åtkomst till annan organisations API. Genom att använda Refresh Token kan sessionen upprätthållas.

Då organisation As AS kan agera OP kan den också användas för åtkomst till andra organisationers e-tjänst  (organisation C) där enbart ID-token och Access-token krävs av e-tjänsten

Framtiden

I framtiden kommer det fortfarande att vara möjligt att nå e-tjänster baserade på identitetsintyg när bara identiteten krävs. Däremot kan autentisering göras via AS och åtkomstintyg där det så krävs, dvs inloggning till en e-tjänst betraktas som en skyddad resurs precis som ett API.

Vi kan då konsolidera autentiseringslösningen till en AS-OP för utfärdande av nödvändiga intyg och utnyttja federationsinfrastrukturen för att hantera metadata. Det förutsätts då att alla övergår till OIDC och Oauth2 som protokoll.

I bilden har organisation A:s e-tjänster gått över till OIDC för sin autentisering. Organisation B kräver åtkomstintyg för åtkomst till sin e-tjänst, vilket den får från sin egen AS, autentisering av användaren sker via organisations B:s IdP. Autentisering av användare i organisation A görs av samma komponent då den stödjer både Oauth2 och OIDC. Organisation C har gått över till OIDC för sina autentiseringar.

Detta möjliggör för organisation A att samla sin IAM-lösning på ett ställe och använda den i alla användningsfall, egna e-tjänster, andras e-tjänster och andras API:er. Observera också att attributkällan nu hänger på AS - OP då SAML-IdP:n inte längre finns.