Brukere

Brukere lagres i miljøets user repository. For å oppnå flere user stores oppretter du flere miljøer og dermed flere user stores.

Det finnes to forskjellige typer brukere:

  • Internal users som autentiseres med login autentiseringsmetoden.
  • External users som er koblet av en autentiseringsmetode til en ekstern user/identity med en claim. Brukerne autentiseres i en ekstern Identity Provider og kan innløses basert på f.eks. en email claim (se Provision and redeem seksjonen i external users dokumentet).

Du kan bruke Directory Connector når interne brukere skal finnes i FoxIDs-miljøet, men passordautentisering og passordlivssyklus skal delegeres til et autoritativt eksternt katalog.

En annen mulighet er å autentisere mot et eksisterende ekstern user store via et API. I dette tilfellet lagres ikke brukerne som internal users i miljøet. Brukerne kan valgfritt opprettes som external users.

Du kan også modellere hierarkisk tilgang for både interne og eksterne brukere med tilgangsstruktur og tildele medlemskap til noder i tilgangsstrukturen.

Tilbakekalle refresh tokens og aktive sesjoner

FoxIDs tilbakekaller automatisk en brukers refresh token grants og aktive sesjoner når en intern eller ekstern bruker deaktiveres eller slettes. Det samme gjelder når en utløpt ekstern bruker fjernes. Authorization codes tilbakekalles ikke fordi de har kort levetid og bare kan brukes én gang.

Endringer i medlemskap i en tilgangsstruktur tilbakekaller også berørte refresh token grants og aktive sesjoner. Dette skjer når en brukers medlemskap endres, eller når en tilgangsstruktur begynner å deaktivere brukere eller slettes. Tidsbegrensede medlemskap kontrolleres når et refresh token eller en aktiv sesjon brukes, slik at utløpt eller fjernet tilgang ikke kan fortsette å bli brukt.

I FoxIDs Control Client bruker du fanene Refresh Token Grants og Active Sessions på miljøets brukerside for å finne og tilbakekalle tilgang. Du kan søke med en FoxIDs-bruker-ID, en e-postadresse, et telefonnummer, et brukernavn eller sub. Fødererte brukere som ikke er lagret i FoxIDs, kan finnes ved hjelp av identifikatorene som er tilgjengelige for dem. Ytterligere filtre lar deg avgrense resultatene til en bestemt authentication method, applikasjon eller sesjon.

Når en aktiv sesjon tilbakekalles, tilbakekalles også refresh token grants som er knyttet til sesjonen og samsvarer med de valgte filtrene. Detaljene for den aktive sesjonen viser navnet og typen på autentiseringsmetoden som opprettet sesjonen.

Når et miljø slettes, fjernes miljøets aktive sesjoner og refresh token grants. Når en tenant slettes, fjernes de samme dataene fra alle miljøene.

Refresh token grants har en maksimal inaktivitetslevetid og absolutt levetid på ett år. Hver fornyelse bruker applikasjonens gjeldende levetidsinnstillinger, inkludert endringer som er gjort etter at grantet ble utstedt. Den absolutte levetiden måles fra grantets opprinnelige opprettelse; fornyelse og tokenrotasjon bevarer dette utgangspunktet. Hver vellykket fornyelse fornyer inaktivitetslevetiden innenfor den absolutte grensen. Et grant som har nådd sin absolutte levetid, avvises og slettes når det brukes.

Når et refresh token utstedes eller fornyes, beholder FoxIDs den tilknyttede aktive sesjonen i tokenets gjeldende gjenværende levetid. Hvis flere refresh token grants deler en sesjon, beholdes sesjonen frem til det seneste nødvendige utløpstidspunktet. Innlogging gjennom FoxIDs med en eksisterende brukersesjon kan forlenge den aktive sesjonen i henhold til autentiseringsmetodens sesjonsinnstillinger uten å fornye refresh token grantet. Aktivitet med refresh tokens forlenger ikke brukerens innloggingssesjon i nettleseren. Den aktive sesjonen kan fortsatt være tilgjengelig for refresh tokens etter at innloggingssesjonen i nettleseren har utløpt. Eksplisitt tilbakekalling ugyldiggjør sesjonen og de tilknyttede grantene.

Sperring ved mislykkede innloggingsforsøk

FoxIDs teller antall mislykkede innloggingsforsøk for hver brukeridentifikator og feiltype. Når grensen for mislykkede innloggingsforsøk er nådd innenfor den konfigurerte tidsrammen, blokkeres ytterligere forsøk i sperreperioden. Brukeren låses automatisk opp når perioden er over.

Directory Connector bruker samme innstillinger for å begrense hvor mange ganger en bruker kan oppgi e-post, telefonnummer eller brukernavn i én innloggingssekvens. Alle identifikatorer i sekvensen deler grensen. Når den nås, må brukeren vente til sperreperioden utløper eller starte en ny innloggingssekvens.

Sperringen gjelder for brukerautentisering med autentiseringsmetodene pålogging og ekstern pålogging, inkludert feil ved verifisering med passord, engangskode og MFA.

Denne sikkerhetsfunksjonen bidrar til å forhindre brute-force-angrep på brukerkontoer. Konfigurer antall forsøk, tidsramme for forsøk og sperreperiode slik at det passer til dine sikkerhetskrav.

Velg miljø i FoxIDs Control Client, og åpne Users > Failing Login Lockout for å se aktive sperrer. Velg End lockout for å fjerne en sperre før den utløper.

Låsingen konfigureres i miljøinnstillingene i FoxIDs Control Client.

  1. Velg fanen Innstillinger.
  2. Velg fanen Miljø.
  3. Finn avsnittet Sperring ved mislykket pålogging.
  4. Angi Grensen for mislykkede påloggingsforsøk, f.eks. 5 forsøk.
  5. Angi Tidsramme for mislykkede påloggingsforsøk i sekunder, f.eks. 36000 i 10 timer.
  6. Angi Sperreperiode i sekunder, f.eks. 3600 i 60 minutter. Sperring ved mislykket pålogging
  7. Klikk på Oppdater.