Arkitekturöversikt

Övergripande teknisk modell för IDOmbuds modulära tjänsteområden.

Hur IDOmbud hanterar detta

IDOmbud samlar flera identitetsnära funktioner i en gemensam tjänstemodell. Identitetsinformation kan hämtas från betrodda källor som HR-system, kataloger, databaser, API:er eller andra verksamhetssystem. Informationen kan bearbetas enligt organisationens regler och användas för att skapa, uppdatera, styra eller följa upp identiteter och åtkomst.

Autentiseringslagret fungerar som en gemensam punkt för inloggning, federation och tillitsstyrning. Applikationer kan anslutas via standardiserade protokoll och ta emot rätt identitetsinformation, till exempel genom OpenID Connect (OIDC) claims eller SAML assertions. Där kan organisationen styra metod, tillitsnivå, MFA, step-up och lösenordsfria flöden utifrån användare, applikation och risk.

IDOmbuds e-Legitimation tillför en organisationsstyrd digital identitet för arbetsrelaterade sammanhang. Den kan användas där organisationen behöver starkare kontroll över utfärdande, användning och återkallelse än vad privata e-legitimationer normalt ger. När e-legitimationen används tillsammans med autentiseringslagret kan den verifierade identiteten kopplas vidare till applikationer och åtkomstbeslut.

Governance-området ger struktur för ansvar, behörigheter, attestering, certifiering och uppföljning. Det gör att organisationen kan besvara frågor som vem som har åtkomst, varför åtkomsten finns, vem som godkänt den och om den fortfarande är motiverad.

Kundens egna system behåller sina roller. HR-system, kataloger och andra datakällor kan vara källor för identitetsinformation. Applikationer och resurser är mål för inloggning och åtkomst. Säkerhets-, logg- och analysverktyg kan vara mottagare av underlag för uppföljning. IDOmbud fungerar som det styrande och samlande lagret mellan dessa delar.

Införandet kan ske stegvis. En organisation kan börja med starkare inloggning, externa användare, e-legitimation, automatiserade identitetsflöden eller governance. När fler områden kopplas in kan samma grundmodell användas för att skapa en mer sammanhängande kedja från identitet och autentisering till åtkomst, ansvar och revision.

Vad kunden behöver ta ställning till

  • vilka användargrupper som ska omfattas först
  • vilka applikationer och resurser som är viktigast att ansluta
  • vilka identitetskällor som ska vara styrande
  • vilka tillitsnivåer och autentiseringsmetoder som krävs
  • hur ansvar för identiteter, resurser och behörigheter ska fördelas
  • vilka händelser som behöver loggas och följas upp
  • vilka krav som finns på drift, dataägarskap, export, arkivering och incidenthantering
  • om införandet ska börja med ett avgränsat tjänsteområde eller planeras som en bredare målarkitektur

Vanliga frågor

Måste hela plattformen införas på en gång?

Nej. Införandet kan börja med ett avgränsat tjänsteområde eller planeras som en bredare målarkitektur. Valet är en av de saker organisationen behöver ta ställning till.

Vilken identitetskälla ska vara styrande?

Det avgörs per organisation. Modellen förutsätter att det är bestämt vilka identitetskällor som är styrande, vilka applikationer som ska anslutas först och hur ansvar för identiteter, resurser och behörigheter fördelas.

Hur hänger autentisering och behörigheter ihop tekniskt?

Autentiseringslagret är en gemensam punkt för inloggning, federation och tillitsstyrning. Anslutna applikationer får identitetsinformation via standardprotokoll, medan behörigheter styrs och följs upp i governance-lagret.

Vill ni gå igenom arkitektur, integrationer eller driftkrav?