Ändringar av policyer i Okta Identity Engine

En av de största skillnaderna som administratörer kommer att märka när de flyttar från Classic till Identity Engine är en ny terminologi och en något annorlunda struktur i huvudpolicyn. Vid migrering av Okta kommer policys att konverteras, men det är klokt att ta en ordentlig titt på dem och göra några justeringar för att uppnå bästa resultat för både användare och säkerhet.

Andreas Faltin
31. oktober 2022

Okta har etablerat sig som den oberoende molnplattformen inom Identity and Access Management. Plattformen rankas regelbundet i toppen av Gartner’s Magic Quadrant för IAM och utvecklas ständigt. Som med all mjukvara finns det ibland behov av strukturella förändringar som inte bara kan tas bort eller ändras direkt ur lådan. Det är vad Identity Engine handlar om. Detta är varken en ny Okta-produkt eller ett nytt användningsområde. Det är helt enkelt samma Okta-plattform, men rekonstruerad.

→ Läs en introduktion till Okta Identity Engine

Nya kunder efter november 2021 får automatiskt börja använda Identity Engine. Befintliga kunder kommer att migreras under 2022.

Terminologi och administration

Även om kapacitet och funktionalitet är något annorlunda finns de viktigaste policys fortfarande i Okta Identity Engine, men med nya namn.

Terminologi og administrasjon

"(Multi-)factors” är nu "Authenticators" i Okta Identity Engine. Okta har justerat terminologin något för att bättre anpassa den till branschstandarderna. En "faktor" beskriver nu en typ av autentisering. Till exempel är autentiseraren "Password" av faktortyp "Knowledge", medan autentiseraren "Okta Verify" är av faktortyp "Possession" (+ Knowledge eller Biometric, beroende på inställningen).

Om du använder faktorsekvensering i Classic Engine kommer du för närvarande inte att migreras till Identity Engine. Factor Sequencing för Identity Engine är fortfarande under utveckling och kommer att vara tillgänglig senare i år.

Autentiseringsprocessen

Medan de andra ändringarna i stort sätt bara är namnändringar eller flyttningar är de största skillnaderna mellan Classic och Identity Engine i autentiseringsprinciperna. Tidigare kallades de "App Sign On Policies" och kunde konfigureras för varje program.

Nu har de en mer framträdande plats i förvaltningskonsolen samt i autentiseringsstrukturen. Medan de tidigare nästan kunde ignoreras om inga ändringar har gjorts, även om de alltid användes, är de nu en integrerad del av autentiseringsdesignen.

"Global Session Policy" fastställer sammanhanget för inloggningsförsöket och definierar en grundläggande uppsättning regler för den session som inleds.

Global Session Policy eksempel Example på en Global Session Policy

Efter "Global Session Policy", innan användaren beviljas tillträde, definierar "Authentication Policy" och dess regler de villkor och faktorer som krävs för att användaren ska få tillträde till varje program.*

Typisk autentiseringspolicy

I det här exemplet får medlemmar i gruppen "Contractors" tillgång till dessa program med ett lösenord och en ytterligare faktor (Okta Verify eller telefon). Andra användare tillämpar "Catch-all-regeln".

*Det är logiskt att tänka sig att både "Okta Dashboard" och "Okta Admin Console" är varsin applikation i detta sammanhang. De har också principer på applikationsnivå som gäller för dem.

Applikationpolicyregler i detalj

Applikationpolicyregler tillåter en komplex uppsättning regler för att justera autentiseringsupplevelsen för användarna. Varje princip tillåter flera regler, som sorteras efter prioritet (första matchning gäller).

Regeln kan innehålla följande:

1. IF

Det här avsnittet definierar NÄR en regel tillämpas.

Del med når en regel brukes

2. THEN

Denna del definierar VAD regeln verkställer..

Del med hva regelen håndhever

3. Frekvens för återautentisering

I den sista delen av regeln kan du definiera hur ofta användarna måste ange sitt lösenord på nytt eller autentisera sig på nytt med alla faktorer.

Eksempel på re-autentiseringsfrekvens Exempel på återautentiseringsfrekvens

Använd autentiseringsprinciper för appar

Autentiseringsprinciper kan tilldelas flera program, vilket gör det lättare för administratören att skilja mellan olika säkerhetskrav för olika program. Observera att vissa appar kräver separata policyer, till exempel Okta Admin Console eller Office 365.

Autentiseringspolicyer brukt på flere applikasjoner Autentiseringspolicyer som tillämpas på flera applikationer

Slutsats

Applikationspolicyer gör det möjligt för Okta-administratörer att finjustera sina autentiserings- och säkerhetspolicyer än vad som tidigare var möjligt med Classic Engine. Policyer på applikationsnivå gör det också möjligt att använda ytterligare förbättringar av Identity Engine, till exempel Okta FastPass.