Externa användare
Du kan använda just-in-time (JIT) provisionering för att skapa externa användare och koppla dem till en extern identitet. En extern användare är kopplad till en autentiseringsmetod (OpenID Connect, SAML 2.0, External Login eller Environment Link) och kan endast autentiseras med den autentiseringsmetoden. Användning av externa användare är valfritt; de skapas inte som standard.
Alla externa användare som är grupperade under en autentiseringsmetod är kopplade till samma claim typ (t.ex. sub claim typ) och användarna separeras av unika claim värden.
Med externa användare kan du lagra claims på varje användare. Till exempel lagra din user ID claim som representerar användaren i ditt system och därigenom mappa den externa user ID till din user ID.
En automatiskt genererad unik ID läggs som standard till varje extern användare.
För en översikt över användarkoncept (interna användare, externa användare och externa user stores) se användaröversikten.
Externa användare kan också tilldelas medlemskap i åtkomststruktur för att modellera hierarkisk åtkomst och lösa åtkomstclaims vid inloggning.
Skapa extern användare
Beroende på vald autentiseringsmetods konfiguration ombeds nya användare valfritt att fylla i ett formulär för att skapa en användare.
Sidan består av dynamiska element som kan anpassas per autentiseringsmetod. I detta exempel består skapa användare sidan av tre element: E-post, Förnamn och Efternamn, med e-post elementet överst.
Detta är konfigurationen i en OpenID Connect autentiseringsmetod.
Claim transformations kan läggas till som utförs precis innan den externa användaren skapas.
Om login sekvensen startas baserat på en login autentiseringsmetod, ger den grunden för UI look and feel (customise). Annars väljs standard login autentiseringsmetod som bas.
Provisionera och lösa in
Externa användare kan skapas, uppdateras och raderas med Control Client eller provisioneras via Control API.
Du känner förmodligen inte link claim värdet i förväg eftersom det är en extern user ID. Men om du gör det, är det möjligt att skapa användare och koppla dem till link claim värdet. Oftast känner du en redemption claim i förväg istället.
De externa användarna kan lösas in med en redemption claim typ (t.ex. email) och de kopplas sedan automatiskt till link claim typen.
Det är dålig praxis att länka användare baserat på deras e-post under lång tid, eftersom e-post kan ändras. Men e-posten ändras troligen inte inom den korta redemption perioden.
När användaren har lösts in loggas den externa användaren därefter in baserat på link claim värdet.
Denna autentiseringsmetod är konfigurerad med email claim redemption och sub link claim typ.
Och användare läggs till med sin kända e-post som redemption claim värde.
I detta exempel är användaren kopplad till Google Workspace med en OpenID Connect autentiseringsmetod och en app_user_id claim läggs till med en intern user ID.
Du kan återställa en inlöst användare genom att radera link claim värdet och vid behov även ändra redemption claim värdet. Den externa användaren löses då in igen nästa gång användaren loggar in.
Migrera externa användare mellan autentiseringsmetoder
Du kan migrera externa användare mellan autentiseringsmetoder och identitetsleverantörer samtidigt som du behåller den genererade unika externa user ID som utfärdas i local_sub claimet. Det betyder att en application eller backend inte behöver ändra sin användarreferens, så länge den är bunden till FoxIDs user ID och inte den identitetsleverantörsspecifika externa ID:n.
När en användare migreras och den externa user ID:n ändras, radera link claim värdet för att återställa den externa användaren. Användaren löses då in mot den konfigurerade autentiseringsmetoden nästa gång användaren loggar in. Om e-postadressen ändras ska redemption claim värdet också uppdateras.
Migrera från en identitetsleverantör till en annan där den gamla identitetsleverantören fasas ut.
Byt namn på den befintliga autentiseringsmetoden. De relaterade externa användarna blir då flytande användare, som för närvarande inte är bundna till en aktiv autentiseringsmetod med det namnet. Du kan sedan skapa den nya autentiseringsmetoden med det ursprungliga namnet, och de befintliga externa användarna kopplas därmed automatiskt till den. Om den externa user ID:n ändras från den gamla till den nya externa identitetsleverantören, radera link claim värdet. Användaren löses då in mot den nya identitetsleverantören nästa gång användaren loggar in. Om e-postadressen ändras ska redemption claim värdet också uppdateras.Migrera från en identitetsleverantör till en annan där den gamla identitetsleverantören förblir aktiv.
Uppdatera de externa användarna så att de pekar på den nya autentiseringsmetoden och radera link claim värdet. Detta kan göras via Control API genom att ändra den kopplade autentiseringsmetoden medUpdateUpPartyName, radera link claim värdet medUpdateLinkClaimValue = ""och, om e-postadressen ändras, uppdatera redemption claim värdet medUpdateRedemptionClaimValue.Migrera från en Entra ID tenant till en annan Entra ID tenant med en gemensam Entra ID autentiseringsmetod.
Detta scenario är relevant om tenants delar en gemensam Entra ID autentiseringsmetod och inte om varje kund har en separat autentiseringsmetod. En användare kan inte flyttas från en Entra ID tenant till en annan och samtidigt behålla samma externa user ID. Användaren representeras istället som en ny extern identitet i den nya tenanten, även om e-postadressen är densamma. Radera link claim värdet så att den externa användaren kan lösas in igen mot den nya Entra ID tenanten. Om e-postadressen ändras ska redemption claim värdet också uppdateras.