Repository navigation
fix(spec): relax required boolean constraints on SamlApplicationSettingsSignOn - #580
Merged
Merged
Conversation
…ngsSignOn Remove the five boolean attributes from the `required` list of the `SamlApplicationSettingsSignOn` schema in the OpenAPI spec, so the generate as `Optional[StrictBool]` with a `None` default: - allowMultipleAcsEndpoints - assertionSigned - honorForceAuthn - requestCompressed - responseSigned Root cause: the create (POST) and read (GET) contracts for `settings.signOn` are asymmetric. App Catalog / OIN SAML apps are serialized on GET as override types that carry only override deltas (e.g. `destinationOverride`), so these attributes are legitimately absent from valid API responses. Because the spec marked them `required`, the generated Pydantic model declared them as non-nullable `StrictBool` and raised `ValidationError` on those payloads. As `list_applications()` is paginated, a single such app failed deserialization for the entire response page. A flat OAS 3.0 schema cannot express the inter-attribute dependencies the API validators enforce, and an OpenAPI 3.1 migration is not planned. Relaxing the read side is the agreed resolution: a too-strict `required` list crashes reads unrecoverably, whereas a relaxed one only under-documents writes, which the API already backstops with specific validation errors. This completes the pattern applied to ten string attributes on the same schema in 3.4.3 (commit 4c5e79d); these five booleans were the remainder. No `default` value is introduced, so the SDK does not fabricate `false` for an attribute the API never returned - relevant because these are Java primitives on the backend that overwrite stored values on update. No okta-core behaviour change is required; this is a spec-accuracy fix. Refs: okta/okta-mcp-server#48, #546
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
list_applications()raisesValidationErrorwhen an org contains App Catalog / OIN SAML applications, making the operation unusable. This relaxes the last five over-strictrequiredconstraints on theSamlApplicationSettingsSignOnschema, completing the fix started in 3.4.3.Root Cause
The create (POST) and read (GET) contracts for
settings.signOnare asymmetric:ssoAcsUrl,audience,recipient,destination,signatureAlgorithmanddigestAlgorithm.The OAS3 spec marked five booleans
required, so the generated Pydantic model declared them as non-nullableStrictBool. Valid API responses omitting them failed validation — and because the response is paginated, one such application poisoned an entire page.Changes
openapi/api.yamlrequiredblock fromSamlApplicationSettingsSignOnokta/models/saml_application_settings_sign_on.pyOptional[StrictBool] = Field(default=None, ...)docs/SamlApplicationSettingsSignOn.md[optional]Attributes relaxed:
allowMultipleAcsEndpoints,assertionSigned,honorForceAuthn,requestCompressed,responseSigned.Why This Is Safe
requiredtoday, so every application that deserializes successfully now has a real boolean present in the payload. Making them optional does not change parsing when a value is present.Nonecan therefore only surface where the SDK currently raisesValidationError. No existing working code path changes behaviour — the change converts a hard failure into a readable value.4c5e79db).Caller impact: code reading these attributes on catalog / override apps will now receive
Noneinstead of an exception, and should handle it. Previously that code could not run at all.Verification
Confirmed no other schema on the SAML deserialization path carries a stale
requiredconstraint:SamlApplication,SamlApplicationSettings,SamlAssertionEncryption,SingleLogout,SloParticipate,SamlSpCertificate,SamlAttributeStatement,SignOnInlineHook— none declarerequired.AcsEndpointrequiresurlandindex, which is correct: those entries only exist whenallowMultipleAcsEndpointsis true, and the API validator guarantees both.These five booleans were the last remaining constraint, so this completes the read-side fix rather than partially addressing it.
Notes
The customer's entry point,
okta-mcp-server, is still pinned tookta-sdk-python3.4.1 and needs upgrading once this release ships for the reported issue to be resolved end to end.Related
4c5e79db— the 3.4.3 fix this completes