Interne brukere

Interne brukere kan autentisere i én eller flere login autentiseringsmetoder i et miljø. Det gjør det mulig å tilpasse innloggingsopplevelsen til ulike applikasjonskrav.

Last opp brukerne dine fra en CSV-fil, med eller uten passord.

For en oversikt over brukerbegreper som interne brukere, eksterne brukere og eksterne brukerlager, se brukeroversikten.

Brukeridentifikatorer

Interne brukere støtter tre brukeridentifikatorer: e-post, telefonnummer og brukernavn. Disse identifikatorene utgjør legitimasjonen, altså brukernavndelen, når en bruker logger inn med brukernavn og passord.

Du kan aktivere én, to eller alle tre identifikatorene i innloggingsautentiseringsmetoden. Hvis mer enn én identifikator er aktivert, kan brukeren logge inn med hvilken som helst aktivert identifikator.

Bare telefonnummer som brukeridentifikator.

E-post, telefonnummer og brukernavn som brukeridentifikatorer.

Passordkontroll

Interne brukere kan autentisere med et passord. Passordet valideres mot den innebygde passordpolicyen (standard eller policygruppe) og eventuelt et eksternt passord-API.

Innebygd passordpolicy og aldring

Standard passordpolicy konfigureres i miljøinnstillingene i FoxIDs Control Client og gjelder når ingen passordpolicygruppe er tildelt brukeren.

1. Velg fanen Settings.
2. Velg fanen Environment.
3. Finn seksjonen Password settings.
4. Konfigurer boksen Default password policy:
   • Password min length og Password max length definerer det tillatte intervallet.
   • Check password complexity krever variasjon i tegnklasser og sikrer at passordet ikke inneholder deler av URL-en eller brukeridentifikatorer som e-post, telefon eller brukernavn.
   • Check password risk based on global password breaches avviser passord som finnes i risikolister. For self-hosted installasjoner, se risk passwords.
   • Banned characters (case-insensitive) blokkerer spesifikke tegn.
   • Password history (number of previous passwords, 0 to disable) forhindrer gjenbruk av nylig brukte passord.
   • Password max age in seconds (0 to disable) tvinger bytte når et passord blir for gammelt.
   • Soft password change in seconds (0 to disable) gir en overgangsperiode. Under innlogging blir brukeren bedt om å endre et passord som ikke oppfyller kravene eller har utløpt, men brukeren kan fortsatt logge inn til perioden utløper.
5. Klikk Update.

Passordpolicygrupper

Du kan definere opptil 10 passordpolicygrupper per miljø. En gruppe overstyrer standard passordpolicy for brukerne som er tildelt gruppen.

1. Velg fanen Settings.
2. Velg fanen Environment.
3. Finn seksjonen Password settings.
4. Konfigurer boksen Password policy groups.
5. Klikk Add policy group og angi policyverdiene, som er de samme feltene som i standardpolicyen, pluss et navn og eventuelt et visningsnavn.
6. Klikk Update.

Bruk en gruppe på en bruker i Internal Users → rediger brukeren → Advanced → Password policy, eller angi navnet på passordpolicyen ved provisionering via Control API. Hvis ingen gruppe er valgt, brukes miljøets standardpolicy.

Eksternt passord-API

Du kan valgfritt konfigurere et eksternt passord-API for å validere passord og/eller varsle om passordendringer.

Hvis den innebygde passordpolicyen avviser passordet, blir ikke det eksterne passord-API-et kalt. Varslingsmetoden i det eksterne passord-API-et kalles bare hvis passordet består alle konfigurerte policykontroller.

Passord eller engangskode (passordløs)

Login autentiseringsmetoden er som standard konfigurert for brukeridentifikator pluss passord.

Du kan også aktivere engangskode (OTP) via e-post og/eller SMS for passordløs innlogging, og du kan opprette flere login autentiseringsmetoder med ulike kombinasjoner.

Hvis både passord og OTP er aktivert, vises alle aktiverte metoder. Grensesnittet kan også tillate selvbetjent opprettelse av konto.

Hvis bare OTP via e-post er aktivert:

Opprett bruker

Avhengig av konfigurasjonen på valgt login metode kan brukere opprette en konto på nettet.

Brukeren velger å opprette en ny konto på innloggingssiden.

Dette eksemplet viser skjemaet for å opprette bruker.

Siden består av dynamiske elementer som kan tilpasses per login metode. I dette eksemplet inneholder skjemaet feltene Given name, Family name, Email og Password. Feltet Email er brukeridentifikatoren som brukes ved innlogging.

Dette er konfigurasjonen i login metoden. I tillegg legges claimen some_custom_claim til for hver bruker som en konstant via en claim transform.

Provisionering

Interne brukere kan opprettes, oppdateres og slettes i Control Client eller provisioneres via Control API. Du kan også laste opp mange brukere fra en CSV-fil.

Multi-faktor autentisering (MFA)

To-faktor og multi-faktor autentisering kan kreves per bruker. Brukeren må da fullføre en ekstra faktor og kan registrere en authenticator app hvis den ikke allerede er registrert.

Tilgjengelige faktorer bestemmes av login autentiseringsmetoden samt brukerens data og innstillinger. Se to-faktor og multi-faktor autentisering.

Du kan se om en authenticator app er registrert, og en administrator kan deaktivere den.

Passordhash

Bare et hash av passordet lagres.

Hashsystemet støtter videreutvikling over tid. Hashmetadata, altså algoritme og parametere, lagres sammen med hver hash slik at gamle hashverdier fortsatt kan valideres mens nye hashverdier bruker nyere algoritmer eller parametere.

Hashalgoritmen som for øyeblikket støttes P2HS512:10:

• HMAC (RFC 2104) med SHA-512 (FIPS 180-4)
• 10 iterasjoner lagret i hashmetadata, multiplisert med 10 000 PBKDF2-runder for totalt 100 000 iterasjoner
• Saltlengde: 64 byte
• Avledet nøkkellengde: 80 byte
• Hash og salt lagres som Base64 URL-kodede strenger, altså Base64 uten padding

Standardbiblioteker i .NET brukes til å beregne hashverdien.