Interne brugere

Interne brugere kan autentificere i én eller flere login autentificeringsmetoder i et miljø. Det gør det muligt at tilpasse loginoplevelsen til forskellige applikationskrav.

Upload dine brugere fra en CSV-fil, med eller uden adgangskode.

For et overblik over brugerbegreber som interne brugere, eksterne brugere og eksterne brugerlagre, se brugeroversigten.

Brugeridentifikatorer

Interne brugere understøtter tre brugeridentifikatorer: e-mail, telefonnummer og brugernavn. Disse identifikatorer udgør legitimationsoplysningen, altså brugernavnsdelen, når en bruger logger ind med brugernavn og adgangskode.

E-mailidentifikatorer kan være op til 100 tegn, og brugernavne kan være op til 60 tegn. E-mailadresser og brugernavne skelner ikke mellem store og små bogstaver, og omgivende blanktegn fjernes før validering og matchning.

Du kan aktivere én, to eller alle tre identifikatorer i login autentificeringsmetoden. Hvis mere end én identifikator er aktiveret, kan brugeren logge ind med enhver aktiveret identifikator. Identifikatorer, der er defineret på en bruger, men deaktiveret i login autentificeringsmetoden, gemmes på brugeren, men kan ikke bruges til at logge ind via den loginmetode.

Kun telefonnummer som brugeridentifikator.

E-mail, telefonnummer og brugernavn som brugeridentifikatorer.

Adgangskodekontrol

Interne brugere kan autentificere med en adgangskode. Adgangskoden valideres mod den indbyggede adgangskodepolitik (standard eller policygruppe) og eventuelt et eksternt adgangskode-API.

Du kan også aktivere Directory Connector for miljøet. I så fald delegeres adgangskodeautentificering og adgangskodens livscyklus til et autoritativt eksternt katalog, mens brugerne forbliver interne brugere i FoxIDs.

Indbygget adgangskodepolitik og udløb

Standardadgangskodepolitikken konfigureres i miljøindstillingerne i FoxIDs Control Client og gælder, når der ikke er tildelt nogen adgangskodepolitikgruppe til brugeren.

1. Vælg fanen Indstillinger.
2. Vælg fanen Miljø.
3. Find afsnittet Adgangskodeindstillinger.
4. Konfigurer feltet Standardpolitik for adgangskoder:
   • Min. adgangskodelængde og Maks. adgangskodelængde definerer det tilladte interval.
   • Kontroller variation og gentagelse af tegn i adgangskoden kræver mindst tre af følgende tegnkategorier: små bogstaver, store bogstaver, tal og symboler. Den afviser også en adgangskode, hvis et tegn forekommer mindst max(3, floor(password length / 2)) gange; de gentagne tegn behøver ikke at være i træk.
   • Kontroller adgangskode mod e-mail, telefonnummer og brugernavn kontrollerer alle tilgængelige brugeridentifikatorer, der er knyttet til brugeren. E-mail-værdier opdeles ved @, ., - og _; brugernavnsværdier opdeles også ved :. Komponenter på fire eller flere tegn må ikke forekomme i adgangskoden. Et telefonnummer på fire eller flere tegn kontrolleres efter fjernelse af det foranstillede +. Sammenligningerne er ikke store- og småbogstavsfølsomme.
   • Kontroller adgangskode mod URL-relaterede ord afviser URL-værts- og service-sti-komponenter på fire eller flere tegn fra den aktuelle FoxIDs-kontekst. Sammenligningerne er ikke store- og småbogstavsfølsomme.
   • Kontroller adgangskoderisiko baseret på globale adgangskodebrud afviser adgangskoder, der findes på risikolister. For selvhostede installationer, se risikobetonede adgangskoder.
   • Forbudte tegn (ikke store- og småbogstavsfølsomt) blokerer bestemte tegn.
   • Adgangskodehistorik (antal tidligere adgangskoder, 0 for at deaktivere) forhindrer genbrug af nylige adgangskoder.
   • Maksimal alder for adgangskode i sekunder (0 for at deaktivere) tvinger en ændring, når en adgangskode bliver for gammel.
   • Blød adgangskodeskift i sekunder (0 for at deaktivere) giver en overgangsperiode. Ved login bliver brugeren bedt om at ændre en adgangskode, der ikke overholder kravene eller er udløbet, men brugeren kan stadig logge ind, indtil overgangsperioden udløber.
5. Klik på Opdater.

Kontrollen af de tre tegn, bruger-id'et og URL-konteksten er uafhængige af hinanden og er aktiveret som standard. De kan konfigureres separat både i standardadgangskodepolitikken og i hver enkelt adgangskodepolitikgruppe.

Adgangskodepolitikgrupper

Du kan definere op til 10 adgangskodepolitikgrupper pr. miljø. En gruppe tilsidesætter standardadgangskodepolitikken for de brugere, der er tildelt gruppen.

1. Vælg fanen Settings.
2. Vælg fanen Environment.
3. Find sektionen Password settings.
4. Konfigurer boksen Password policy groups.
5. Klik Add policy group og angiv politikværdierne, som er de samme felter som i standardpolitikken, plus et navn og eventuelt et visningsnavn.
6. Klik Update.

Anvend en gruppe på en bruger i Internal Users → rediger brugeren → Advanced → Password policy, eller angiv navnet på adgangskodepolitikken ved provisionering via Control API. Hvis ingen gruppe er valgt, bruges miljøets standardpolitik.

Eksternt adgangskode-API

Du kan valgfrit konfigurere et eksternt adgangskode-API til at validere adgangskoder og/eller give besked om ændringer af adgangskoder.

Hvis den indbyggede adgangskodepolitik afviser adgangskoden, bliver det eksterne adgangskode-API ikke kaldt. Notifikationsmetoden på det eksterne adgangskode-API kaldes kun, hvis adgangskoden består alle konfigurerede politikchecks.

Adgangskode eller engangskode (passwordless)

Login autentificeringsmetoden er som standard konfigureret til brugeridentifikator plus adgangskode.

Du kan også aktivere engangskode (OTP) via e-mail og/eller SMS til passwordless login, og du kan oprette flere login autentificeringsmetoder med forskellige kombinationer.

Hvis både adgangskode og OTP er aktiveret, vises alle aktiverede metoder. UI'et kan også tillade self-service oprettelse af konto.

Hvis kun OTP via e-mail er aktiveret:

Opret bruger

Afhængigt af konfigurationen på den valgte login metode kan brugere oprette en konto online.

Brugeren vælger at oprette en ny konto på login-siden.

Dette eksempel viser formularen til oprettelse af bruger.

Siden består af dynamiske elementer, som kan tilpasses pr. login metode. I dette eksempel indeholder formularen felterne Given name, Family name, Email og Password. Feltet Email er den brugeridentifikator, der bruges ved login.

Du kan begrænse online kontooprettelse til valgte e-maildomæner i login-metodens Create user konfiguration. Hvis der ikke er konfigureret tilladte e-maildomæner, kan brugere oprette en konto med en hvilken som helst gyldig e-mailadresse. Tilføj tilladte domæner uden @, for eksempel some-customer.dk. Domæneværdier skal være lowercase domæner uden mellemrum før eller efter. Når tilladte e-maildomæner er konfigureret, skal create-user formularen indeholde præcis ét påkrævet Email dynamisk element markeret som brugeridentifikator.

Domænebegrænsningen kontrolleres mod den e-mailadresse, brugeren har skrevet i create-user formularen, før create-user claim transforms anvendes. Det betyder, at en claim transform ikke kan gøre en sign-up gyldig ved at ændre det indsendte e-maildomæne.

Dette er konfigurationen i login metoden. Derudover tilføjes claimen some_custom_claim til hver bruger som en konstant via en claim transform.

Provisionering

Interne brugere kan oprettes, opdateres og slettes i Control Client eller provisioneres via Control API. Du kan også uploade mange brugere fra en CSV-fil.

Multi-faktor autentificering (MFA)

To-faktor og multi-faktor autentificering kan kræves pr. bruger. Brugeren skal derefter gennemføre en ekstra faktor og kan registrere en authenticator app, hvis den ikke allerede er registreret.

Tilgængelige faktorer bestemmes af login autentificeringsmetoden samt brugerens data og indstillinger. Se to-faktor og multi-faktor autentificering.

Under Internal Users → rediger brugeren → Advanced → Two-factor kan en administrator se hver registreret authenticator-app og fjerne registreringer enkeltvis. Listen viser det permanente registrerings-ID og registreringstidspunktet, når det findes; authenticator-secrets vises ikke. Registreringer kan også synkroniseres via Control API.

Adgangskodehash

Der lagres kun et hash af adgangskoden.

Hash-understøttelsen kan udvikles over tid. Hashmetadata, altså algoritme og parametre, lagres sammen med hvert hash, så gamle hashværdier stadig kan valideres, mens nye hashværdier bruger nyere algoritmer eller parametre.

Aktuelt understøttet hashalgoritme P2HS512:10:

• HMAC (RFC 2104) med SHA-512 (FIPS 180-4)
• 10 iterationer lagret i hashmetadata, ganget med 10.000 PBKDF2-runder for i alt 100.000 iterationer
• Saltlængde: 64 byte
• Afledt nøglelængde: 80 byte
• Hash og salt lagres som Base64 URL-kodede strenge, altså Base64 uden padding

Standardbiblioteker i .NET bruges til at beregne hashen.

Relateret dokumentation

• Brugere
• Eksterne brugere
• Directory Connector
• External Password API
• Upload mange brugere
• Adgangsstruktur
• Login & HRD
• To-faktor og multi-faktor autentificering