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.

Interne brukere kan også tildeles medlemskap i tilgangsstruktur for å modellere hierarkisk tilgang og løse tilgangsclaims under innlogging.

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.

E-postidentifikatorer kan være opptil 100 tegn lange, og brukernavn kan være opptil 60 tegn lange. E-postadresser og brukernavn skiller ikke mellom store og små bokstaver, og omgivende blanktegn fjernes før validering og samsvar.

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. Identifikatorer som er definert på en bruker, men deaktivert i innloggingsautentiseringsmetoden, lagres på brukeren, men kan ikke brukes til å logge inn via den innloggingsmetoden.

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.

Du kan også aktivere Directory Connector for miljøet. I så fall delegeres passordautentisering og passordlivssyklus til et autoritativt eksternt katalog, mens brukerne fortsatt er interne brukere i FoxIDs.

Innebygd passordpolicy og utløp

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

1. Velg fanen Innstillinger.
2. Velg fanen Miljø.
3. Finn seksjonen Passordinstillinger.
4. Konfigurer feltet Standard passordpolicy:
   • Min. passordlengde og Maks. passordlengde definerer det tillatte området.
   • Kontroller variasjon og repetisjon av passordtegn krever minst tre av følgende tegngrupper: små bokstaver, store bokstaver, tall og symboler. Det avviser også et passord hvis ett tegn forekommer minst max(3, floor(password length / 2)) ganger; de gjentatte tegnene trenger ikke å være på rad.
   • Sjekk passord mot e-post, telefonnummer og brukernavn sjekker alle tilgjengelige brukeridentifikatorer knyttet til brukeren. E-postverdier deles opp i @, ., - og _; brukernavnsverdier deles også opp i :. Komponenter på fire eller flere tegn må ikke forekomme i passordet. Et telefonnummer på fire eller flere tegn sjekkes etter at + er fjernet fra begynnelsen. Sammenligningene er ikke skiftesensitive.
   • Sjekk passord mot URL-relaterte ord avviser URL-vert- og tjenestebane-komponenter på fire eller flere tegn fra den gjeldende FoxIDs-konteksten. Sammenligningene er ikke skiftesensitive.
   • Sjekk passordrisiko basert på globale passordbrudd avviser passord som finnes i risikolister. For selvhostede distribusjoner, se risikopassord.
   • Forbudte tegn (ikke skiftesensitivt) blokkerer bestemte tegn.
   • Passordhistorikk (antall tidligere passord, 0 for å deaktivere) forhindrer gjenbruk av nylige passord.
   • Maksimal passordalder i sekunder (0 for å deaktivere) tvinger frem en endring når et passord blir for gammelt.
   • Myk passordendring i sekunder (0 for å deaktivere) gir en overgangsperiode. Ved innlogging blir brukeren bedt om å endre et passord som ikke oppfyller kravene eller har utløpt, men brukeren kan fortsatt logge seg inn inntil overgangsperioden utløper.
5. Klikk på Oppdater.

Kontrollene av tre tegn, bruker-ID og URL-kontekst er uavhengige av hverandre og er aktivert som standard. De kan konfigureres separat både i standardpassordpolicyen og i hver passordpolicygruppe.

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.

Du kan begrense kontoopprettelse online til valgte e-postdomener i login-metodens Create user konfigurasjon. Hvis ingen tillatte e-postdomener er konfigurert, kan brukere opprette en konto med hvilken som helst gyldig e-postadresse. Legg til tillatte domener uten @, for eksempel some-customer.dk. Domeneverdier må være lowercase-domener uten innledende eller avsluttende mellomrom. Når tillatte e-postdomener er konfigurert, må create-user skjemaet inneholde nøyaktig ett påkrevd dynamisk Email-element merket som brukeridentifikator.

Domenebegrensningen kontrolleres mot e-postadressen brukeren har skrevet i create-user skjemaet før create-user claim transforms brukes. Det betyr at en claim transform ikke kan gjøre en sign-up gyldig ved å endre det innsendte e-postdomenet.

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.

Under Internal Users → rediger brukeren → Advanced → Two-factor kan en administrator se hver registrert authenticator-app og fjerne registreringer enkeltvis. Listen viser permanent registrerings-ID og registreringstid når den finnes; authenticator-secrets vises ikke. Registreringer kan også synkroniseres via Control API.

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.

Relatert dokumentasjon

• Brukere
• Eksterne brukere
• Directory Connector
• External Password API
• Last opp mange brukere
• Tilgangsstruktur
• Innlogging og Home Realm Discovery
• To-faktor og multi-faktor autentisering