Omada#
Indledning#
Integrationen henter brugerdata fra Omada og indlæser dem i OS2mo. Integrationen beriger allerede eksisterende brugere i OS2mo og opretter også helt nye brugere, der er manuelt oprettet i Omada.
Integrationen understøtter at samme bruger kan have flere AD-konti og flere engagementer (ansættelser) samt at disse kan bindes sammen.
Forudsætninger#
For at integrationen kan aktiveres, skal følgende være på plads:
- Et view udstilles i Omada med alle relevante data.
- Brugertyperne opmærkes.
- Der laves en servicekonto til Magenta, som har læserettigheder til viewet.
- Der tilvejebringes en testinstans til Omada.
- Autentificering foregår via OIDC eller HTTP Basic Auth.
- En nøgle, der kan identificere en bruger unikt i hhv. Omada og OS2mo, tilvejebringes.
- Det identificeres hvordan der kan skelnes mellem nyoprettede og allerede eksisterende brugere. Det skal dog først verificeres om det er nødvendigt i det lokale setup.
Omada view#
Data fra Omada bliver indlæst i OS2mo via et view. Nedenstående data vil blive synkroniseret.
Alle brugere har en VALIDFROM/VALIDTO, der bliver importeret ind i MO på hvert synkroniseret objekt. Vikarer har disse felter for personerne:
- Fornavne
- Efternavn
- CPRnr.
Samt felter for engagementerne:
- Stillingsbetegnelse - Passer præcist med de jobtitler, der allerede eksisterer i MO. Hvis ikke sættes en standard-jobtitel.
- Organisationskode - Det kan være AD GUID, hvis disse er opsat som IT-konti på enhederne. Kan også være enhedsnummeret (bvn - brugervendt nøgle).
- Synlighed - Sæt en adresse til 'hemmelig', 'må vises internt' eller 'må vises eksternt'.
Derudover bliver adresser synkroniseret for fx felter:
- Direkte telefonnummer
- Mobiltelefonnummer
Og IT-konti for følgende felter:
- ObjectGuid fra Active Directory
- AD-login / SamAccountName
Skelnen mellem eksisterende og manuelt oprettede medarbejdere#
Manuelt oprettede brugere bliver kun oprettet, hvis de har en identitetskode. Allerede eksisterende brugere vil have en anden identitetskode, så det er muligt at skelne.
Manglende historik på slettede brugere#
Når en bruger slettes i Omada (og ikke længere er med i viewet), vil brugerens engagement også blive slettet i MO, og der vil altså ikke fremgå nogen historik på engagementet i MOs GUI (fortidsfanen) - Det er en konsekvens af, at Omada ikke opererer med bitemportalitet ligesom MO. Man vil dog altid kunne finde historikken i MOs database om nødvendigt.
Datahåndtering i MO GUI#
I OS2mo vil ObjectGuid og ad-login (SamAccountName) blive skrevet under fanen it-system på brugeren, og adresser vil blive placeret under adressefanen.
Der vil være relationer mellem engagementer og adresser samt it-konti og engagementer. Det vil sørge for at en bruger med flere engagementer og flere it-konti kan få tildelt differentierede rettigheder i fx FK Organisation.
Bemærk at objectguid og ad-login (SamAccountName) vil fremgå af hver sin række i OS2mo’s GUI under fanen it-system.
Adgangsstyring & autentificering#
For at kunne tilgå viewet, skal OS2mo have en servicekonto, som har læserettigheder til viewet. Den foretrukne autentificeringsmetode mod API'et er via OIDC.
Frekvens#
Omada er ikke event-baseret, så det er OS2mo der skal spørge Omada om ændringer. Os2mo kan gøre det med et interval, der er nærmere specificeret af kunden, fx hvert kvarter eller hvert minut.