SCIM-provisjonering

SCIM-provisjonering lar identitetsleverandøren din (IdP) — for eksempel Microsoft Entra ID — administrere mTime-brukere automatisk. Når noen ansettes, endres eller slutter i katalogen din, kaller IdP-en mTimes SCIM 2.0-endepunkt, og brukeren opprettes, oppdateres eller deaktiveres uten at noen rører mTime.

Gruppemedlemskap i IdP-en tilsvarer mTime-roller: legges en person til i en tilknyttet gruppe, tildeles rollen — fjernes personen, trekkes den tilbake.

Hvem eier hva

IdP-en kan aldri endre en rolles tillatelser — bare dens eksistens og medlemmer. Selve brukerne og gruppene administreres i IdP-en din: når SCIM-provisjonering er i gang, oppretter, endrer og fjerner du dem der, ikke i mTime.

Slik provisjoneres brukere

1. IdP-en sender en ny bruker — alltid med e-postadressen sin, og valgfritt et stabilt ansattnummer (SCIM-feltet externalId, som aldri trenger å fylles ut).
2. mTime leter etter den samsvarende ansatte, i denne rekkefølgen:
   • Via ansattnummer — bare når integrasjonens innstilling Koble externalId til ansattattributt peker på et ansattattributt og IdP-en sendte en externalId: da vinner den ansatte som bærer det nummeret i det koblede attributtet.
   • Via e-postadresse — ellers (eller når nummeret ikke traff noen) brukes den ansatte med samme e-postadresse, uavhengig av store og små bokstaver.
   • Ingen treff? Det opprettes ingen ansatt ennå — brukeren blir et utkast.
3. Med en matchende ansatt opprettes brukeren som invitert med rollen employee (pluss manager når vedkommende er leder for noen) og mottar den vanlige invitasjons-e-posten. Etter aktivering logger vedkommende inn som vanlig (f.eks. “Logg inn med Microsoft”).

Brukere uten ansatt (utkast)

Ikke alle IdP-en din oppretter, er ansatte — en IT-administrator eller en ekstern revisor trenger kanskje bare en rolle som workspace-admin eller read-only. Derfor oppretter mTime en ansatt bare når en rolle krever det:

• Uten matchende ansatt opprettes brukeren som et utkast: ingen ansatt, ingen rolle og ingen invitasjons-e-post. Et utkast kan ikke logge inn.
• Når IdP-en legger brukeren til i en gruppe, får vedkommende gruppens rolle. Krever rollen en ansatt (employee, manager eller en egendefinert rolle med Krever tilknyttet ansatt ), knytter mTime først til den matchende ansatte — eller oppretter en minimal post (navn, e-post — pluss nummeret, når det er koblet), som HR-integrasjonen din beriker senere.
• Et utkasts første rolle sender invitasjons-e-posten.
• Fjernes en bruker fra sin siste gruppe, står vedkommende uten rolle og kan ikke logge inn før en gruppe gir en rolle igjen. En eventuell ansatt forblir tilknyttet.

Hvor ansattnummeret lagres

Å sende en externalId er valgfritt, og som standard brukes den ikke. Sender IdP-en din likevel en, husker mTime den på brukeren — det er denne IdP-en bruker for å gjenkjenne brukeren ved senere synkroniseringer. Vil du at den også skal styre ansattkoblingen, velger du et ansattattributt i integrasjonens innstilling Koble externalId til ansattattributt . Samsvarende og nyopprettede ansatte bærer da nummeret i det attributtet (synlig i attributtseksjonen på den ansattes side), og det er også slik HR-integrasjonen din holder postene forbundet. Som standard er ingenting koblet, og brukerne knyttes til ansatte via e-postadressen alene.

Bruke identitetsleverandørens navn på ansatte

Som standard blir navnet IdP-en sender, værende på brukeren: den tilknyttede ansatte beholder navnet som vedlikeholdes i mTime eller av HR-integrasjonen, og det er det som vises i vaktplaner, rapporter og lønnseksporter. Et navnebytte i IdP-en (giftemål, en rettelse, et foretrukket navn) endrer altså innloggingen, ikke den ansatte. Skal IdP-en eie navnene overalt, slår du på integrasjonens innstilling Bruk navn fra identitetsleverandøren som ansattnavn : når en bruker opprettes eller oppdateres, skrives navnet fra IdP-en da også til den tilknyttede ansatte, og hvert navnebytte registreres i Admin › Integrasjonslogg sammen med navnet det erstattet.

• Det får virkning ved hver brukers neste SCIM-oppdatering — å slå det på gir ikke eksisterende ansatte nytt navn. Vil du bruke et navn med en gang, provisjonerer du brukeren på forespørsel fra IdP-en.
• Navnet fra IdP-en overstyrer da et navn som vedlikeholdes i mTime eller av en HR-integrasjon. Synkroniserer også en HR-integrasjon navn, vil de to bytte på å overskrive hverandre — la innstillingen være av når HR eier navnene.

Deaktivering og sletting

• Når IdP-en deaktiverer en bruker, suspenderes vedkommende i mTime og logges ut umiddelbart. Aktiveres brukeren igjen i IdP-en, reaktiveres den.
• Når IdP-en sletter en bruker, utfører mTime sin vanlige myke sletting — kontoen fjernes, men historikken (tidsregistreringer, godkjenninger, ansattposten) bevares.

Slik blir grupper til roller

• En ny IdP-gruppe oppretter en tom egendefinert rolle (ingen tillatelser) med gruppens navn. Den vises på rollesiden, der en administrator avgjør hva den skal kunne.
• En gruppe med navn som samsvarer nøyaktig med en eksisterende rolle, knyttes til den rollen i stedet — ingen duplikater.
• Gruppens medlemmer har den tilknyttede rollen; medlemsendringer i IdP-en tildeler og trekker den tilbake automatisk. Roller som styres slik, bærer merket “Styres av IdP-gruppe”, og manuelle medlemsendringer rettes tilbake ved IdP-ens neste synkronisering.

• Rollen owner kan aldri administreres via SCIM.
• For en eksisterende rolle (inkludert innebygde som hr-admin eller workspace-admin) kan IdP-en først administrere medlemskap etter at en arbeidsområde-eier har godkjent rollen: åpne den på rollesiden og legg til provisioning under Kan tildeles av. Å lagre en rolle endrer aldri denne listen av seg selv.
• Slettes en gruppe i IdP-en, fjernes medlemmene fra rollen. Selve rollen slettes bare hvis den fortsatt var det ukonfigurerte skallet — en rolle en administrator har konfigurert, består.

Hva synkroniseres når

IdP-en din snakker med mTime på to måter, og de oppfører seg ikke likt:

Provisjonering på forespørsel er ypperlig for å teste tilkoblingen og tilordningene, men ikke bli overrasket om en bruker du deaktiverte eller slettet i IdP-en, fortsatt er aktiv i mTime — den endringen kommer med neste planlagte syklus, ikke på forespørsel.

Oppsett

Følg den trinnvise veiledningen: Sett opp SCIM med Microsoft Entra ID. Den går gjennom alt — mTime-innstillingene, provisjonerings-servicebrukeren og API-nøkkelen dens, enterprise-applikasjonen i Entra, attributtilordningene og hvordan du tester før du setter det i drift.

Sikkerhetsnotater

• API-nøkkelen er bundet til arbeidsområdet ditt, virker kun på SCIM-endepunktene og kan når som helst trekkes tilbake fra servicebrukerens nøkkelliste — tilbaketrekking stenger IdP-en ute umiddelbart.
• Det kan bare finnes én provisjonerings-servicebruker per arbeidsområde; roter legitimasjon på nøkkelnivå (opprett en ny nøkkel, oppdater IdP-en, trekk tilbake den gamle).
• Alle endringer gjort via SCIM registreres i endringshistorikken, tilskrevet provisjonerings-servicebrukeren.