OKTA Policies & Rules

Learn how to configure security policies in OKTA including sign-on policies, password policies, and MFA policies. This guide covers policy types, rules, conditions, and enforcement.

Table of Contents

1. Policies Overview

Policies in OKTA define security rules and requirements for authentication, passwords, and multi-factor authentication. Policies control how users authenticate, what password requirements they must follow, and when MFA is required.

Key policy types:

  • Sign-On Policies: Control authentication methods and requirements
  • Password Policies: Define password complexity and expiration rules
  • MFA Policies: Control when multi-factor authentication is required
  • IdP Discovery Policies: Route users to appropriate identity providers
  • OAuth Authorization Policies: Control OAuth token issuance

1.1 Policy Structure

Policies consist of:

  • Policy: Container for multiple rules
  • Rules: Individual conditions and actions
  • Conditions: When the rule applies (users, groups, locations)
  • Actions: What happens when conditions are met
  • Priority: Order in which rules are evaluated

1.2 Policy Assignment

Policies can be assigned to:

  • All users (default policy)
  • Specific groups
  • Specific applications
  • Specific identity providers

2. Sign-On Policies

Sign-On Policies control how users authenticate to OKTA and applications. They define authentication factors, session duration, and access conditions.

2.1 Policy Rules

Sign-on policy rules define:

  • Authentication factors: Password, MFA, certificate, etc.
  • Session duration: How long sessions remain active
  • Session idle timeout: Inactivity timeout
  • Network zones: Trusted vs untrusted networks
  • Device trust: Require trusted devices

2.2 Rule Conditions

Rules can apply based on:

  • User: Specific users or groups
  • Application: Specific applications
  • Network zone: IP address or location
  • Device: Device type or trust status
  • Risk: Risk score from threat detection

2.3 Example Sign-On Policy

Example: Require MFA for external access

  • Rule 1: If user is in "External" group AND network is untrusted → Require password + MFA
  • Rule 2: If user is in "Internal" group AND network is trusted → Require password only
  • Default: Require password + MFA

2.4 Session Management

Sign-on policies control sessions:

  • Session lifetime: Maximum session duration (e.g., 8 hours)
  • Idle timeout: Time before session expires due to inactivity
  • Persistent sessions: Remember user across browser sessions
  • Session binding: Bind session to IP address or device

3. Password Policies

Password Policies define password complexity requirements, expiration rules, and password management settings.

3.1 Password Complexity

Password complexity settings:

  • Minimum length: Minimum number of characters (e.g., 8, 12)
  • Require uppercase: Must contain uppercase letters
  • Require lowercase: Must contain lowercase letters
  • Require numbers: Must contain numeric digits
  • Require symbols: Must contain special characters
  • Exclude username: Password cannot contain username
  • Exclude first/last name: Password cannot contain user's name

3.2 Password History

Password history settings:

  • Prevent reuse: Prevent using previous passwords
  • History count: Number of previous passwords to remember (e.g., 12)
  • Minimum age: Minimum time before password can be changed

3.3 Password Expiration

Password expiration settings:

  • Expire password: Enable password expiration
  • Expiration period: Days until password expires (e.g., 90 days)
  • Warn before expiration: Notify users before expiration
  • Warning period: Days before expiration to warn (e.g., 7 days)

3.4 Password Dictionary

Password dictionary settings:

  • Exclude common passwords: Block commonly used passwords
  • Exclude dictionary words: Prevent dictionary words
  • Custom dictionary: Add organization-specific words to exclude

3.5 Password Reset

Password reset settings:

  • Self-service reset: Allow users to reset passwords
  • Reset methods: Email, SMS, security questions
  • Admin reset: Allow admins to reset passwords
  • Require MFA for reset: Require MFA to reset password

4. MFA Policies

MFA Policies control when and how multi-factor authentication is required. They define which MFA factors are allowed and when MFA must be used.

4.1 MFA Enrollment

MFA enrollment settings:

  • Require enrollment: Force users to enroll in MFA
  • Enrollment deadline: Date by which enrollment is required
  • Grace period: Allow access before enrollment
  • Reminder frequency: How often to remind users to enroll

4.2 MFA Factors

Configure allowed MFA factors:

  • OKTA Verify: Push notification and TOTP
  • SMS: Text message codes
  • Email: Email codes
  • Security Questions: Pre-configured questions
  • Hardware Tokens: YubiKey, RSA SecurID
  • WebAuthn: FIDO2 security keys

4.3 MFA Requirements

MFA requirement rules:

  • Always require: MFA required for every login
  • Per session: MFA required once per session
  • Conditional: MFA required based on conditions
  • Per application: MFA required for specific applications

4.4 Conditional MFA

Conditional MFA based on:

  • Network zone: Require MFA from untrusted networks
  • Device: Require MFA from untrusted devices
  • Risk score: Require MFA for high-risk logins
  • Application: Require MFA for sensitive applications
  • User group: Require MFA for specific groups

4.5 MFA Factor Priority

Configure factor priority:

  • Order factors by preference
  • Users see factors in priority order
  • Can require specific factors
  • Can allow multiple factors as backup

5. Policy Rules

Policy Rules define specific conditions and actions within a policy. Rules are evaluated in priority order, and the first matching rule is applied.

5.1 Rule Structure

Each rule contains:

  • Name: Descriptive name for the rule
  • Priority: Evaluation order (lower numbers evaluated first)
  • Conditions: When the rule applies
  • Actions: What happens when conditions match
  • Status: Active or inactive

5.2 Rule Conditions

Common condition types:

  • User is member of: Specific groups
  • User is: Specific users
  • Network is: Trusted or untrusted zones
  • Device is: Trusted or untrusted
  • Application is: Specific applications
  • Risk score is: Risk level thresholds

5.3 Rule Actions

Rule actions define what happens:

  • Allow: Permit access with specified requirements
  • Deny: Block access
  • Require: Require specific authentication factors
  • Challenge: Challenge user with additional factors

5.4 Creating Rules

To create a policy rule:

  1. Open the policy
  2. Click Add Rule
  3. Enter rule name
  4. Configure conditions
  5. Configure actions
  6. Set priority
  7. Save the rule

6. Policy Priority

Policy Priority determines which policy applies when multiple policies could match. Understanding priority is crucial for correct policy enforcement.

6.1 Rule Evaluation

Rules are evaluated:

  • In priority order (lowest number first)
  • First matching rule is applied
  • Remaining rules are not evaluated
  • Default rule applies if no rules match

6.2 Policy Assignment Priority

When multiple policies apply:

  1. Application-specific policies: Highest priority
  2. Group-specific policies: Medium priority
  3. Default policies: Lowest priority

6.3 Best Practices

  • Start with most specific rules first
  • Use descriptive rule names
  • Test policies before deploying
  • Document policy purposes
  • Review policies regularly
  • Use groups for policy assignment
  • Avoid conflicting rules
  • Always have a default rule

Summary

OKTA policies provide granular control over authentication, passwords, and MFA requirements. Sign-on policies control how users authenticate, password policies define complexity and expiration rules, and MFA policies control when additional factors are required. Policies consist of rules with conditions and actions, evaluated in priority order. Understanding policy structure, rule creation, and priority is essential for implementing effective security controls that balance security and user experience.

Post a Comment

0 Comments