Eksterne brukere
Du kan bruke just-in-time (JIT) provisionering for å opprette eksterne brukere og knytte dem til en ekstern identitet. En ekstern bruker er knyttet til én autentiseringsmetode (OpenID Connect, SAML 2.0, External Login eller Environment Link) og kan kun autentiseres med den autentiseringsmetoden. Bruk av eksterne brukere er valgfritt; de opprettes ikke som standard.
Alle eksterne brukere gruppert under en autentiseringsmetode er knyttet til samme claim type (f.eks. sub claim type) og brukerne skilles med unike claim verdier.
Med eksterne brukere kan du lagre claims på hver bruker. For eksempel lagre din user ID claim som representerer brukeren i systemet ditt og dermed mappe den eksterne bruker ID til din user ID.
En automatisk generert unik ID legges som standard til hver ekstern bruker.
For en oversikt over brukerkonsepter (interne brukere, eksterne brukere og eksterne user stores) se brukeroversikten.
Eksterne brukere kan også tildeles medlemskap i tilgangsstruktur for å modellere hierarkisk tilgang og løse tilgangsclaims under innlogging.
Opprett ekstern bruker
Avhengig av valgt autentiseringsmetodes konfigurasjon blir nye brukere valgfritt bedt om å fylle ut et skjema for å opprette en bruker.
Siden består av dynamiske elementer som kan tilpasses per autentiseringsmetode. I dette eksempelet består opprett bruker siden av tre elementer: E-post, Fornavn og Etternavn, med E-post øverst.
Dette er konfigurasjonen i en OpenID Connect autentiseringsmetode.
Claim transformations kan legges til og utføres like før den eksterne brukeren opprettes.
Hvis login sekvensen startes basert på en login autentiseringsmetode, danner den grunnlaget for UI look and feel (tilpasning). Ellers velges standard login autentiseringsmetode som basis.
Provisioner og innløs
Eksterne brukere kan opprettes, oppdateres og slettes med Control Client eller provisioneres via Control API.
Du kjenner sannsynligvis ikke link claim verdien på forhånd fordi det er en ekstern bruker ID. Men hvis du gjør det, er det mulig å opprette brukere og knytte dem til link claim verdien. Oftest kjenner du i stedet en redemption claim på forhånd.
De eksterne brukerne kan innløses med en redemption claim type (f.eks. email) og blir deretter automatisk knyttet til link claim typen.
Det er dårlig praksis å knytte brukere basert på e-post over lang tid, siden e-post kan endre seg. Men e-post endrer seg normalt ikke i den korte redemption perioden.
Når brukeren er innløst, logges den eksterne brukeren deretter inn basert på link claim verdien.
Denne autentiseringsmetoden er konfigurert med email claim redemption og sub link claim type.
Og brukere legges til med kjent e-post som redemption claim verdi.
I dette eksempelet er brukeren koblet til Google Workspace med en OpenID Connect autentiseringsmetode og en app_user_id claim legges til med en intern bruker ID.
Du kan tilbakestille en innløst bruker ved å slette link claim verdien og om nødvendig også endre redemption claim verdien. Den eksterne brukeren innløses da på nytt neste gang brukeren logger inn.
Migrer eksterne brukere mellom autentiseringsmetoder
Du kan migrere eksterne brukere mellom autentiseringsmetoder og identitetsleverandører samtidig som du beholder den genererte unike eksterne bruker ID-en som utstedes i local_sub claimet. Det betyr at en application eller backend ikke trenger å endre brukerreferansen, så lenge den er bundet til FoxIDs bruker ID og ikke den identitetsleverandør-spesifikke eksterne ID-en.
Når en bruker migreres og den eksterne bruker ID-en endres, slett link claim verdien for å tilbakestille den eksterne brukeren. Brukeren innløses deretter mot den konfigurerte autentiseringsmetoden neste gang brukeren logger inn. Hvis e-postadressen endres, skal redemption claim verdien også oppdateres.
Migrer fra en identitetsleverandør til en annen der den gamle identitetsleverandøren fases ut.
Gi den eksisterende autentiseringsmetoden nytt navn. De relaterte eksterne brukerne blir da flytende brukere, som for øyeblikket ikke er bundet til en aktiv autentiseringsmetode med det navnet. Du kan deretter opprette den nye autentiseringsmetoden med det opprinnelige navnet, og de eksisterende eksterne brukerne blir dermed automatisk koblet til den. Hvis den eksterne bruker ID-en endres fra den gamle til den nye eksterne identitetsleverandøren, slett link claim verdien. Brukeren innløses deretter mot den nye identitetsleverandøren neste gang brukeren logger inn. Hvis e-postadressen endres, skal redemption claim verdien også oppdateres.Migrer fra en identitetsleverandør til en annen der den gamle identitetsleverandøren forblir aktiv.
Oppdater de eksterne brukerne slik at de peker til den nye autentiseringsmetoden og slett link claim verdien. Dette kan gjøres via Control API ved å endre den tilkoblede autentiseringsmetoden medUpdateUpPartyName, slette link claim verdien medUpdateLinkClaimValue = ""og, hvis e-postadressen endres, oppdatere redemption claim verdien medUpdateRedemptionClaimValue.Migrer fra én Entra ID tenant til en annen Entra ID tenant med en felles Entra ID autentiseringsmetode.
Dette scenariet er relevant hvis tenants deler en felles Entra ID autentiseringsmetode, og ikke hvis hver kunde har en separat autentiseringsmetode. En bruker kan ikke flyttes fra én Entra ID tenant til en annen og samtidig beholde samme eksterne bruker ID. Brukeren representeres i stedet som en ny ekstern identitet i den nye tenanten, selv om e-postadressen er den samme. Slett link claim verdien slik at den eksterne brukeren kan innløses på nytt mot den nye Entra ID tenanten. Hvis e-postadressen endres, skal redemption claim verdien også oppdateres.