fix: Align AccessPolicyConstraint methods / types enums with actual API casing

[BinoyOza-okta]

Fixes: Align AccessPolicyConstraint methods / types enums with actual API casing

Summary

Fixes Pydantic ValidationError raised by PolicyApi.list_policy_rules() (GET /api/v1/policies/{policyId}/rules)
when an access policy rule contains lowercase methods or types values inside its constraints[] block.

The Okta API returns these values in lowercase (e.g. "password", "push", "webauthn"), but the OpenAPI spec defined the enums as UPPERCASE-only, causing every modern authentication policy rule to fail deserialization.

Problem

Calling list_policy_rules() against a policy whose rules carry a KnowledgeConstraint (or PossessionConstraint, or base AccessPolicyConstraint) raised:

each list item must be one of ('PASSWORD', 'SECURITY_QUESTION', 'SMS', 'VOICE', 'EMAIL', 'PUSH', 'SIGNED_NONCE', 'OTP', 'TOTP', 'WEBAUTHN', 'DUO', 'IDP', 'CERT')

Root Cause

Enum case mismatch between the OAS3 spec (policies.yaml →openapi/api.yaml) and the live API response for:

• AccessPolicyConstraint.methods[]
• AccessPolicyConstraint.types[]

KnowledgeConstraint and PossessionConstraint inherit the same field definitions, so all three generated Pydantic models carried the incorrect UPPERCASE allow-list.

Solution

Per the JIRA's chosen resolution ("Update the OpenAPI spec to define enums as lowercase (matching what the API actually returns)"):

1. OpenAPI spec (openapi/api.yaml)

Redefined both enums in lowercase to mirror the API contract:

• methods[]:
  password, security_question, sms, voice, email, push, signed_nonce, otp, totp, webauthn, duo, idp, cert
• types[]: security_key, phone, email, password, security_question, app, federated

2. Regenerated models

The three affected Pydantic v2 models had their field_validator
allow-lists and error messages regenerated to lowercase:

• okta/models/access_policy_constraint.py
• okta/models/knowledge_constraint.py
• okta/models/possession_constraint.py

No model class names, field names, or method signatures changed — only the contents of the validator sets and the corresponding ValueError messages.

Files Changed

File	Type	Change
openapi/api.yaml	Spec	methods / types enums → lowercase on AccessPolicyConstraint, KnowledgeConstraint, PossessionConstraint
okta/models/access_policy_constraint.py	Generated	Regenerated lowercase allow-list + error messages
okta/models/knowledge_constraint.py	Generated	Regenerated lowercase allow-list + error messages
okta/models/possession_constraint.py	Generated	Regenerated lowercase allow-list + error messages

Testing

• Live org: Verified against an Okta org with an access policy whose knowledge constraint contains "types": ["password"]. client.list_policy_rules(policy_id) now returns the full rule list without raising ValidationError, and the lowercase values deserialize cleanly into KnowledgeConstraint.types.
• Spot checks: Confirmed methods values such as "push", "webauthn", and "signed_nonce" are also accepted post-fix.
• No regressions: No other policy / factor code paths were touched; existing tests in tests/ continue to pass.

Backward Compatibility

This is a wire-format alignment fix. Before this change the SDK could not deserialize real API responses for affected policies at all, so no previously-working call is broken.

⚠️ Callers that construct AccessPolicyConstraint /
KnowledgeConstraint / PossessionConstraint objects on the client side must now supply the constraint values in lowercase (e.g. types=["password"] rather than types=["PASSWORD"]). This matches the casing the API itself uses on both request and response.

Related

• JIRA: OKTA-1172239
• Endpoint: GET /api/v1/policies/{policyId}/rules
  (PolicyApi.list_policy_rules)
• Upstream: fixed in the OAS3 spec; this PR pulls the same fix into openapi/api.yaml and regenerates the affected models.