Hur IDOmbud hanterar detta
IDOmbud kan använda integrationer i flera riktningar: hämta information, bearbeta den, uppdatera system, ansluta applikationer och lämna underlag för uppföljning.
Hämta information
Identitetsflöden börjar ofta i ett källsystem. Det kan vara ett HR-system, ett elevsystem, en kunddatabas, Active Directory, Entra ID, LDAP eller ett verksamhetssystem där externa användare, uppdrag eller organisatoriska relationer finns registrerade.
Informationen kan hämtas via API, databasanslutning, katalogfråga eller fil. Exempel på tekniker är REST, Microsoft Graph, SCIM, SQL, LDAP, CSV och XML. I vissa fall sker hämtning enligt schema. I andra fall kan flöden triggas av händelser eller API-anrop.
Bearbeta och normalisera
När data hämtas behöver den ofta matchas, valideras och normaliseras innan den används. IDOmbud kan användas för att koppla ihop identiteter mellan flera system, berika användarprofiler, identifiera förändringar, beräkna attribut, skapa regler för behörighet och upptäcka avvikelser.
Exempel:
- matcha person, konto och extern identitet
- koppla användare till chef, sponsor eller resursägare
- beräkna grupper eller roller utifrån organisation, uppdrag eller anställning
- filtrera bort poster som inte ska hanteras
- identifiera konton utan ägare eller användare utan giltigt uppdrag
- avgöra om en behörighet ska skapas, ändras, tidsbegränsas eller avslutas
Uppdatera system
När reglerna är tillämpade kan IDOmbud uppdatera anslutna mål. Det kan handla om att skapa eller ändra konton i Active Directory eller Entra ID, uppdatera grupper, skriva till databaser, anropa REST- eller Graph-API:er, skicka SCIM-provisionering, skapa filer eller leverera rapporter.
Typiska mål är:
- Active Directory och Entra ID
- LDAP-kataloger
- applikationsdatabaser
- SaaS-tjänster med API eller SCIM
- verksamhetssystem med REST-API
- filbaserade mottagare via CSV/XML
- rapport- eller analysmiljöer
- notifieringskanaler som e-post eller Teams
Ansluta applikationer
För autentisering och federation ansluts applikationer till IDOmbud via standardprotokoll. SAML används ofta i etablerade enterprise- och myndighetsnära miljöer. OIDC är vanligt i moderna webb-, mobil- och API-nära lösningar.
Här handlar integrationen inte bara om teknisk SSO. Applikationen behöver få rätt identitetsinformation i rätt format, till exempel claims eller assertions, och rätt tillitskontext. Det behöver definieras vilka attribut applikationen behöver, vilka användargrupper som ska kunna logga in, vilken autentiseringsmetod som krävs och hur händelser ska loggas.
Automatisera livscykel och behörigheter
Integrationer gör Joiner/Mover/Leaver praktiskt genomförbart. När en person börjar kan IDOmbud hämta startinformation från HR, skapa konto, sätta attribut, tilldela grundläggande grupper och initiera eventuella attestflöden. När personen byter roll kan attribut och behörigheter uppdateras. När personen slutar kan konton stängas, behörigheter tas bort och e-Legitimation eller credential återkallas.
Samma integrationsmodell kan användas för externa användare, konsulter, partners, elever, servicekonton och tidsbegränsade uppdrag. Skillnaden ligger i datakälla, ansvar och regler.
Följa upp och exportera
Integrationer används också för uppföljning. IDOmbud kan skapa underlag för revision, governance, loggning och analys. Det kan handla om rapporter över behörigheter, användare utan ägare, avvikelser i livscykel, atteststatus, certifieringsresultat eller händelser som behöver vidare till SIEM eller annan logghantering.
Vad kunden behöver ta ställning till
- vilka system som är källor för identitetsdata
- vilka system som är mål för konton, attribut och behörigheter
- vilka applikationer som ska anslutas för SSO, federation eller stark autentisering
- om integration ska ske via API, katalog, databas, fil, SCIM, Graph eller annan metod
- vilka attribut som behövs och vilket system som är källa för respektive attribut
- hur identiteter ska matchas mellan system
- hur fel, dubbletter och ofullständig data ska hanteras
- vilka flöden som ska vara schemalagda och vilka som ska vara händelsestyrda
- vilka tekniska konton, behörigheter, brandväggsöppningar och nätverksvägar som krävs
- hur integrationer ska testas, övervakas och felsökas
- vilka loggar och rapporter som ska skapas
- hur ansvar för datakvalitet, regelverk och drift ska fördelas