Interne brukere

Interne brukere kan autentiseres i en eller flere login autentiseringsmetoder i et miljø, noe som gjør det mulig å tilpasse login opplevelsen, f.eks. avhengig av ulike applikasjons krav.

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

For en oversikt over brukerkonsepter (interne brukere, eksterne brukere og eksterne user stores) se brukeroversikten.

Bruker identifikatorer

Interne brukere støtter tre bruker identifikatorer: e-post, telefonnummer og brukernavn. Disse identifikatorene utgjør credential (brukernavn delen) når en bruker logger inn med brukernavn og passord.
Du kan velge å aktivere én, to eller alle tre.

Kun telefonnummer som bruker identifikator.

E-post, telefonnummer og brukernavn som bruker identifikatorer.

Passordkontroll

Interne brukere kan autentiseres med et passord. Passordet kontrolleres mot den innebygde passordpolicyen (standard eller policygruppe) og valgfritt en ekstern 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 deretter fanen Environment
3. Finn seksjonen Password settings
4. Konfigurer boksen Default password policy:
   • Password min length og Password max length for å definere tillatt intervall.
   • Check password complexity for å håndheve tegnklasser og sikre at passordet ikke inneholder deler av URL eller bruker identifikatorer (e-post, telefon, brukernavn).
   • Check password risk based on global password breaches for å avvise passord som finnes på risikolister (self-hosted se risk Passwords).
   • Banned characters (case-insensitive) for å blokkere spesifikke tegn.
   • Password history (number of previous passwords, 0 to disable) for å hindre gjenbruk av nylige passord.
   • Password max age in seconds (0 to disable) for å tvinge endring når et passord blir for gammelt.
   • Soft password change in seconds (0 to disable) for å gi en graceperiode: under login blir et ikke-kompatibelt eller utløpt passord bedt om å endres, men brukeren kan fortsatt logge inn til tidsvinduet utløper.
5. Klikk Update

Passordpolicygrupper

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

1. Velg fanen Settings
2. Velg deretter fanen Environment
3. Finn seksjonen Password settings
4. Konfigurer boksen Password policy groups:
   • Klikk Add policy group og sett policyverdiene (samme felter som standard policy) pluss et navn og et valgfritt visningsnavn.
5. Klikk Update
6. Bruk en gruppe på en bruker i Internal Users → rediger bruker → Advanced → Password policy, eller sett passordpolicynavnet ved provisionering via Control API. Hvis ingen gruppe er valgt, brukes standard miljøpolicy.

Ekstern passord API

Du kan valgfritt konfigurere en ekstern passord API for å validere passord og/eller varsle om passordendringer.

Hvis den innebygde passordpolicyen avviser passordet, kalles ikke den eksterne passord API. Varslingsmetoden til den eksterne passord API kalles bare hvis passordet har bestått alle konfigurerte policykontroller.

Passord eller engangspassord (passwordless)

Login autentiseringsmetoden er som standard konfigurert for brukernavn (bruker identifikator) + passord.
Du kan i tillegg aktivere engangspassord (OTP) via e-post og/eller SMS for passwordless login, og du kan opprette flere login autentiseringsmetoder med ulike kombinasjoner.

Hvis både passord og OTP er aktivert, tilbys alle aktiverte metoder. UI tillater også selvbetjent konto opprettelse.

Hvis kun OTP via e-post er aktivert:

Opprett bruker

Avhengig av valgt login metode konfigurasjon kan brukere opprette en konto online.

Bruker velger å opprette en ny konto på login siden.

Skjema for å opprette en bruker.

Siden består av dynamiske elementer som kan tilpasses per login metode.
I dette eksempelet inneholder skjemaet feltene Fornavn, Etternavn, E-post og Passord.
E-post feltet er en bruker identifikator brukt for login.

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

Provisionering

Interne brukere kan opprettes, oppdateres og slettes i Control Client eller provisioneres via Control API. Og last opp mange brukere fra en CSV fil.

Multi-faktor autentisering (MFA)

To faktor / multi faktor autentisering kan kreves per bruker. En bruker må da autentisere med en ekstra faktor (SMS, e-post eller authenticator app) og kan registrere en authenticator app hvis ikke allerede registrert.

Hvilke andre faktorer som er tilgjengelige kan konfigureres per bruker og per login metode. Se to faktor autentisering.
Du kan se om en authenticator app er registrert og en administrator kan deaktivere den.

Passord hash

Kun en passord hash lagres.

Hashing subsystemet støtter utvikling: hash metadata (algoritme + parametre) lagres med hver hash, slik at gamle hasher kan valideres mens nye hasher bruker nyere algoritmer / parametre.

For tiden støttet hash algoritme P2HS512:10 (definisjon):

• HMAC (RFC 2104) med SHA-512 (FIPS 180-4)
• 10 iterasjoner lagret i hash metadata, multiplisert med 10.000 PBKDF2 runder (100.000 totale iterasjoner)
• Salt lengde: 64 byte
• Avledet nøkkellengde: 80 byte
• Hash og salt lagres som Base64 URL kodede strenger (Base64 uten padding)

Standard .NET biblioteker brukes til å beregne hash.