SCIM-provisionering

SCIM-provisionering lader din identitetsudbyder (IdP) — f.eks. Microsoft Entra ID — administrere mTime-brugere automatisk. Når nogen ansættes, ændres eller fratræder i dit brugerkatalog, kalder IdP’en mTimes SCIM 2.0-endpoint, og brugeren oprettes, opdateres eller deaktiveres, uden at nogen behøver at gøre noget i mTime.

Gruppemedlemskaber i IdP’en svarer til roller i mTime: Tilføjes en person til en tilknyttet gruppe, får personen rollen — fjernes personen, trækkes rollen tilbage.

Hvem ejer hvad

IdP’en kan aldrig ændre en rolles tilladelser — kun om rollen findes, og hvem der er medlem af den. Brugere og grupper administreres inde i din IdP: når SCIM-provisionering kører, opretter, ændrer og fjerner du dem dér, ikke i mTime.

Sådan provisioneres brugere

1. IdP’en sender en ny bruger — altid med vedkommendes e-mailadresse og valgfrit et stabilt medarbejdernummer (SCIM-feltet externalId, som aldrig behøver at blive udfyldt).
2. mTime leder efter den matchende medarbejder i denne rækkefølge:
   • Efter medarbejdernummer — kun når integrationens indstilling Kæd externalId til medarbejderattribut peger på en medarbejderattribut, og IdP’en sendte et externalId: så bruges den medarbejder, der har nummeret i den sammenkædede attribut.
   • Efter e-mailadresse — ellers (eller når nummeret ikke matchede nogen) bruges medarbejderen med samme e-mailadresse, uanset store/små bogstaver.
   • Matchede ingen af delene? Der oprettes endnu ingen medarbejder — brugeren bliver en kladde.
3. Med en matchende medarbejder oprettes brugeren som inviteret med rollen Medarbejder (plus Leder, når vedkommende er leder for nogen) og modtager den sædvanlige invitationsmail. Efter aktivering logger vedkommende ind som normalt (f.eks. “Log ind med Microsoft”).

Brugere uden medarbejder (kladder)

Ikke alle, som din IdP opretter, er medarbejdere. En IT-administrator eller en ekstern revisor har måske kun brug for en rolle som Arbejdsområdeadministrator eller Skrivebeskyttet. Derfor opretter mTime kun en medarbejder, når en rolle kræver det:

• Uden en matchende medarbejder oprettes brugeren som en kladde: ingen medarbejder, ingen rolle og ingen invitationsmail. En kladde kan ikke logge ind.
• Når IdP’en føjer brugeren til en gruppe, får vedkommende gruppens rolle. Kræver rollen en medarbejder (Medarbejder, Leder eller en brugerdefineret rolle med Kræver tilknyttet medarbejder ), knytter mTime først den matchende medarbejder til brugeren — eller opretter en minimal medarbejderpost (navn, e-mail — plus nummeret, når attributten er kædet sammen), som din HR-integration senere supplerer.
• Det er en kladdes første rolle, der sender invitationsmailen.
• Fjernes en bruger fra sin sidste gruppe, står vedkommende uden rolle og kan ikke logge ind, før en gruppe giver en rolle igen. En eventuel medarbejder forbliver tilknyttet.

Hvor medarbejdernummeret gemmes

Det er valgfrit at sende et externalId, og som standard bruges det ikke. Sender din IdP et, husker mTime det på brugeren — det er det, IdP’en bruger til at genkende brugeren ved senere synkroniseringer. Vil du også bruge det til at matche medarbejdere, skal du vælge en medarbejderattribut i integrationens indstilling Kæd externalId til medarbejderattribut . Matchede og nyoprettede medarbejdere får så nummeret i den attribut (det kan ses i attributsektionen på medarbejderens side), og det er også sådan, din HR-integration holder posterne sammenkædet. Som standard er intet kædet sammen, og matchingen sker alene på e-mailadressen.

Brug identitetsudbyderens navn på medarbejdere

Som standard bliver det navn, din IdP sender, kun på brugeren — den tilknyttede medarbejder beholder det navn, der vedligeholdes i mTime eller af din HR-integration, og det er det, der vises i vagtplaner, rapporter og løneksporter. Et nyt navn i IdP’en (ægteskab, en rettelse, et foretrukket navn) ændrer altså loginnet, ikke medarbejderen. Skal din IdP eje navnene hele vejen igennem, så slå integrationens indstilling Brug navne fra identitetsudbyderen som medarbejdernavne til: Når en bruger oprettes eller opdateres, skrives IdP’ens navn så også til den tilknyttede medarbejder, og hver sådan omdøbning registreres i Admin › Integrationslog sammen med det navn, den erstattede.

• Det træder i kraft ved hver brugers næste SCIM-opdatering — at slå det til omdøber ikke eksisterende medarbejdere. Vil du anvende et navn med det samme, så provisionér brugeren efter behov fra IdP’en.
• IdP’ens navn overskriver derefter et navn, der vedligeholdes i mTime eller af en HR-integration. Synkroniserer en HR-integration også navne, vil de to skiftes — lad indstillingen være slået fra, når HR ejer navnene.

Deaktivering og sletning

• Når IdP’en deaktiverer en bruger, suspenderes vedkommende i mTime og logges ud med det samme. Genaktivering gør brugeren aktiv igen.
• Når IdP’en sletter en bruger, sletter mTime den på den sædvanlige måde — kontoen fjernes, men historikken (tidsregistreringer, godkendelser, medarbejderposten) bevares.

Sådan bliver grupper til roller

• En ny IdP-gruppe opretter en tom brugerdefineret rolle (ingen tilladelser) med gruppens navn. Den vises på rollesiden, hvor en administrator afgør, hvad den må.
• En gruppe, hvis navn matcher en eksisterende rolle præcist, knyttes til den rolle i stedet — ingen dubletter.
• Gruppens medlemmer har den tilknyttede rolle; medlemsændringer i IdP’en tildeler og tilbagekalder den automatisk. Roller, der styres på den måde, er mærket “Styres af IdP-gruppe”, og manuelle ændringer af medlemskab rulles tilbage ved IdP’ens næste synkronisering.

• Rollen Ejer kan aldrig administreres via SCIM.
• For en rolle, der fandtes i forvejen (også indbyggede roller som HR-administrator eller Arbejdsområdeadministrator), må IdP’en først administrere medlemskabet, når ejeren af arbejdsområdet har åbnet for det: Åbn rollen på siden Roller, og tilføj Provisionering under Kan tildeles af . Listen ændres aldrig af sig selv, når en rolle gemmes.
• Slettes en gruppe i IdP’en, fjernes dens medlemmer fra rollen. Selve rollen slettes kun, hvis den stadig er tom og ikke sat op — en rolle, som en administrator har konfigureret, bevares.

Hvad synkroniseres hvornår

Din IdP taler med mTime på to måder, og de opfører sig ikke ens:

Provisionering efter behov er god til at teste forbindelsen og attributtilknytningerne, men bliv ikke overrasket, hvis en bruger, du har deaktiveret eller slettet i IdP’en, stadig er aktiv i mTime — ændringen kommer med den næste planlagte cyklus, ikke efter behov.

Opsætning

Følg trin-for-trin-guiden: Opsæt SCIM med Microsoft Entra ID. Den gennemgår alt — mTime-indstillingerne, servicebrugeren til provisionering og dens API-nøgle, enterprise-applikationen i Entra, attributtilknytninger, og hvordan du tester, før du går i drift.

Sikkerhedsnoter

• API-nøglen er bundet til dit arbejdsområde, virker kun på SCIM-endpoints og kan til enhver tid tilbagekaldes fra servicebrugerens nøgleliste — når nøglen tilbagekaldes, mister IdP’en straks adgang.
• Der kan kun findes én servicebruger til provisionering pr. arbejdsområde. Udskift loginoplysninger ved at skifte nøglen (opret en ny nøgle, opdatér IdP’en, tilbagekald den gamle).
• Alle ændringer via SCIM registreres i ændringshistorikken med servicebrugeren til provisionering som afsender.