Brugere

Brugere gemmes i miljøets user repository. For at opnå flere user stores opretter du flere miljøer og dermed flere user stores.

Der er to forskellige typer brugere:

  • Internal users som autentificeres med login autentificeringsmetoden.
  • External users som er knyttet af en autentificeringsmetode til en ekstern user/identity med en claim. Brugerne autentificeres i en ekstern Identity Provider og kan indløses baseret på f.eks. en email claim (se Provision and redeem sektionen i external users dokumentet).

Du kan bruge Directory Connector, når interne brugere skal findes i FoxIDs-miljøet, men adgangskodeautentificering og adgangskodens livscyklus skal delegeres til et autoritativt eksternt katalog.

En anden mulighed er at autentificere mod en eksisterende ekstern user store via et API. I dette tilfælde gemmes brugerne ikke som internal users i miljøet. Brugerne kan valgfrit oprettes som external users.

Du kan også modellere hierarkisk adgang for både interne og eksterne brugere med adgangsstruktur og tildele medlemskaber til adgangsstrukturens noder.

Tilbagekaldelse af refresh tokens og aktive sessioner

FoxIDs tilbagekalder automatisk en brugers refresh token grants og aktive sessioner, når en intern eller ekstern bruger deaktiveres eller slettes. Det samme gælder, når en udløbet ekstern bruger fjernes. Authorization codes tilbagekaldes ikke, fordi de har kort levetid og kun kan bruges én gang.

Ændringer i medlemskaber i en adgangsstruktur tilbagekalder også berørte refresh token grants og aktive sessioner. Det sker, når en brugers medlemskaber ændres, eller når en adgangsstruktur begynder at deaktivere brugere eller slettes. Tidsbegrænsede medlemskaber kontrolleres, når et refresh token eller en aktiv session bruges, så udløbet eller fjernet adgang ikke fortsat kan benyttes.

I FoxIDs Control Client kan du bruge fanerne Refresh Token Grants og Active Sessions på miljøets brugerside til at finde og tilbagekalde adgang. Du kan søge med et FoxIDs-bruger-ID, en emailadresse, et telefonnummer, et brugernavn eller sub. Federerede brugere, som ikke er gemt i FoxIDs, kan findes via de identifikatorer, der er tilgængelige for dem. Yderligere filtre gør det muligt at afgrænse resultaterne til en bestemt authentication method, applikation eller session.

Når en aktiv session tilbagekaldes, tilbagekaldes også de refresh token grants, der er knyttet til sessionen og matcher de valgte filtre. Detaljerne for den aktive session viser navn og type på den autentificeringsmetode, der oprettede sessionen.

Når et miljø slettes, fjernes dets aktive sessioner og refresh token grants. Når en tenant slettes, fjernes de samme data fra alle tenantens miljøer.

Refresh token grants har en maksimal inaktivitetslevetid og absolut levetid på ét år. Hver fornyelse bruger applikationens aktuelle levetidsindstillinger, herunder ændringer foretaget efter udstedelsen af grantet. Den absolutte levetid måles fra grantets oprindelige oprettelse; fornyelse og tokenrotation bevarer dette udgangspunkt. Hver vellykket fornyelse fornyer inaktivitetslevetiden inden for den absolutte grænse. Et grant, der har nået sin absolutte levetid, afvises og slettes, når det bruges.

Når et refresh token udstedes eller fornyes, bevarer FoxIDs den tilknyttede aktive session i tokenets aktuelle resterende levetid. Hvis flere refresh token grants deler en session, bevares sessionen indtil det seneste nødvendige udløbstidspunkt. Login gennem FoxIDs med en eksisterende brugersession kan forlænge den aktive session i henhold til autentificeringsmetodens sessionsindstillinger uden at forny refresh token grantet. Aktivitet med refresh tokens forlænger ikke brugerens login-session i browseren. Den aktive session kan fortsat bruges til refresh tokens, efter at login-sessionen i browseren er udløbet. Eksplicit tilbagekaldelse ugyldiggør sessionen og de tilknyttede grants.

Spærring ved mislykkede loginforsøg

FoxIDs tæller antallet af mislykkede loginforsøg for hver brugeridentifikator og fejltype. Når grænsen for mislykkede loginforsøg nås inden for den konfigurerede tidsramme, blokeres yderligere forsøg i spærringsperioden. Brugeren låses automatisk op, når denne periode udløber.

Directory Connector bruger samme indstillinger til at begrænse, hvor mange gange en bruger kan indtaste e-mail, telefonnummer eller brugernavn i én loginsekvens. Alle identifikatorer i sekvensen deler grænsen. Når den nås, skal brugeren vente på spærringsperiodens udløb eller starte en ny loginsekvens.

Spærringen gælder for brugergodkendelse ved hjælp af autentificeringsmetoderne login og eksternt login, herunder fejl ved verifikation med adgangskode, engangskode og MFA.

Denne sikkerhedsfunktion hjælper med at forhindre brute-force-angreb på brugerkonti. Konfigurer antallet af forsøg, tidsrammen for forsøg og spærreperioden, så de passer til dine sikkerhedskrav.

I FoxIDs Control Client vælges miljøet, og Users > Failing Login Lockout åbnes for at se aktive spærringer. Vælg End lockout for at fjerne en spærring før udløb.

Låsningen konfigureres i miljøindstillingerne i FoxIDs Control Client.

  1. Vælg fanen Indstillinger.
  2. Vælg fanen Miljø.
  3. Find afsnittet Spærring ved mislykket login.
  4. Indstil Grænsen for mislykkede loginforsøg, f.eks. 5 forsøg.
  5. Indstil Tidsramme for mislykkede loginforsøg i sekunder, f.eks. 36000 i 10 timer.
  6. Indstil Spærringsperiode i sekunder, f.eks. 3600 i 60 minutter. Spærring ved mislykket login
  7. Klik på Opdater.