Ændringer af politikkerne i Okta Identity Engine

Ændringer af politikkerne i Okta Identity Engine

En af de største forskelle, administratorer vil bemærke, når de flytter fra Classic til Identity Engine, er forskellig terminologi samt lidt anderledes opbygning i hovedpolitikkerne. Ved migrering af Okta vil politikkerne blive konverteret, men det giver mening at se godt på dem og foretage nogle justeringer for at opnå de bedste resultater for både brugere og sikkerhed.

Terminologi og administration

Selvom muligheder og funktionalitet er lidt anderledes, er hovedpolitikkerne stadig i Okta Identity Engine, men med nye navne.

Terminologi og administrasjonTerminologi og administration

"(Multi-)Factors" er nu "Authenticators" i Okta Identity Engine. Okta har justeret terminologien lidt for bedre at tilpasse sig industristandarder. En "faktor" beskriver nu en type godkendelse. For eksempel er autentificeringsenheden "Password" af faktortypen "Knowledge", mens autentificeringsenheden "Okta Verify" er af faktortypen "Possession" (+ Knowledge eller Biometric, afhængig af opsætningen).

Hvis du bruger faktorsekvensering i Classic Engine, vil du ikke blive migreret til Identity Engine allerede nu. Factor Sequencing for Identity Engine er stadig under udvikling og vil blive frigivet senere i år.

Autentificeringsprocessen

Mens andre ændringer for det meste kun er at omdøbe eller flytte, er de største forskelle mellem Classic og Identity Engine i godkendelsespolitikkerne. Tidligere blev de kaldt "App Sign On Policies" og kunne konfigureres for hver applikation.

Nu har de en mere fremtrædende plads i administrationskonsollen såvel som i autentificeringsstrukturen. Mens de tidligere næsten kunne ignoreres, hvis der ikke var foretaget ændringer, selvom de altid blev brugt, er de nu en integreret del af autentificeringsdesignet.

"Global sessionspolitik" angiver konteksten for loginforsøget og definerer et grundlæggende sæt regler for den session, der startes.

Global Session Policy eksempelGlobal Session Policy eksempel

Efter "Global Session Policy", før brugeren får adgang, definerer "Authentication Policy" og deres regler de betingelser og faktorer, der kræves for at give brugeren adgang til hver applikation. *

Typisk godkendelsespolitikTypisk godkendelsespolitik

I dette eksempel får medlemmer af gruppen "Contractors" adgang til disse applikationer med en adgangskode og en ekstra faktor (Okta Verify eller telefon). Andre brugere bruger "Catch-all-reglen".

* Det giver mening at tænke, at både "Okta Dashboard" og "Okta Admin Console" hver især er en applikation i denne sammenhæng. De har også politikker på app-niveau, der gælder for dem.

Ansøgningspolitik-regler i detaljer

Godkendelsespolitikker tillader et komplekst sæt regler for at justere godkendelsesoplevelsen for brugerne. Hver politik tillader flere regler, som er sorteret efter prioritet (første hit gælder).

Reglen kan indeholde følgende:

1. IF

Dette afsnit definerer, HVORNÅR en regel bruges.

Del, når en regel bruges

2. THEN

Dette afsnit definerer, hvad reglen håndhæver.

Del med hvad reglen håndhæver

3. Gen-autentificeringsfrekvens

I den sidste del af reglen kan du definere, hvor ofte brugere skal indtaste deres adgangskode igen eller genautentificere med alle faktorer.

Eksempel på gen-autentificeringsfrekvensEksempel på gen-autentificeringsfrekvens

Brug godkendelsespolitikker for apps

Godkendelsespolitikker kan tildeles til flere applikationer, hvilket gør det nemmere for administratoren at adskille forskellige sikkerhedskrav for forskellige applikationer. Bemærk, at nogle apps kræver separate politikker, såsom Okta Admin Console eller Office 365.

Godkendelsespolitikker anvendt på flere applikationerGodkendelsespolitikker anvendt på flere applikationer

Konklusion

Applikationspolitikker giver Okta-administratorer mulighed for at finjustere deres autentificerings- og sikkerhedspolitikker ud over, hvad der tidligere var muligt med Classic Engine. Politikker på app-niveau tillader også brugen af ​​yderligere Identity Engine-forbedringer, såsom Okta FastPass.