Okta har etableret sig som den uafhængige cloud-platform til Identity and Access Management. Regelmæssigt i toppen af Gartner Magic Quadrant til IAM og et produkt i konstant forbedring. Som med alle softwareprodukter kræves der dog strukturelle ændringer af og til, der ikke bare kan fjernes eller ændres uden at dreje det store hjul. Det er hvad Identity Engine handler om. Det er ikke et nyt produkt eller en anden slags use case, det er den kendte Okta-platform rekonstrueret.
→ Læs en introduktion til Okta Identity Engine
Nye kunder fra november 2021 og frem er automatisk på Identity Engine. Eksisterende kunder vil blive migreret i løbet af 2022.
Terminologi og administration
Selvom muligheder og funktionalitet er lidt anderledes, er hovedpolitikkerne stadig i Okta Identity Engine, men med nye navne.
Terminologi 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 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 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.
2. THEN
Dette afsnit definerer, 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-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 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.