...
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å SAML-IdP:n döljs bakom AS kan AS användas för att överbrygga skillnaderna mellan olika SAML-IdP:er.
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
| draw.io Board Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
| draw.io Board Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|