feat(sso): classify an SSO configuration as authentication only - #807
Conversation
Adds sso.configureAuthenticationOnly and surfaces the classification on the SSO settings responses. An authentication-only SSO configuration verifies a person's identity without creating, updating or signing in a user, so it grants no access to the application. A tenant can then keep one connection for application login and another purely to verify external people, and tell them apart through the API. ssoId is required: the tenant's default configuration cannot be classified. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
🐕 Shuni ReviewNo new issues found. 🤖 Model: Review scope: Full review Reviewed files (4)
🐕 Review complete — View session on Shuni Portal 🐾 🤖 Model: |
![shuni-bot[bot]](https://avatars.githubusercontent.com/in/2536750?s=60&v=4){kind=small}
The classification is stored on the configuration's settings rows, which the tenant's default configuration has too, so ssoId becomes optional and moves after the required argument: omit it to target the default. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The dedicated method is gone. The classification is per SSO connection, so it now travels on the SAML, by-metadata and OIDC settings objects like every other per-connection setting. Left out it is not sent, so an ordinary settings save keeps whatever the tenant configured instead of clearing it.
dorsha
left a comment
dorsha
left a comment
There was a problem hiding this comment.
Review against backend#2713. configureSAMLSettings and configureSAMLByMetadata post settings whole and configureOIDCSettings spreads it, so nothing is dropped and false is preserved; tests assert the wire body; loadSettings / loadAllSettings hit the v2 routes and return SSOSettings, which carries the field. Nothing blocking.
- Parity gap shared with go-sdk#855:
XAASettingshas noauthenticationOnlyandconfigureXAASettingspicks fields explicitly, so the backend'sConfigureXAASettingsRequest.authenticationOnlyis unreachable from this SDK. - README shows
disableSignRequestin the SSO section (1094-1101); addauthenticationOnlybeside it with the omit / false semantics. - Nit: no test for
configureSAMLByMetadata, and none pinning thatauthenticationOnlysurvivestransformSettingsResponseon load.
The OIDC settings type doubles as the oidc field of the load response, where the server never sets the classification. Without a note a reader checks the nested field and silently gets false.
configureXAASettings picks its request fields explicitly, so XAASettings had no way to express the classification and it would have been dropped even if a caller passed it. Adds the by-metadata, Cross-App Access and load-decoding tests, and documents the omit-keeps / false-clears semantics in the README.
|
Added Also the tests that were missing: |
1 participant
Description
Adds
authenticationOnlyto the SSO settings types —SSOSAMLSettings,SSOSAMLByMetadataSettingsandSSOOIDCSettings— and surfaces it on the SSO settings responses.A connection classified this way verifies a person's identity without creating, updating or signing in a user: the login authenticates against the IdP and returns the IdP response, with no user and no session behind it. See descope/backend#2713.
It is optional. Left out it is not sent, so an ordinary settings save keeps whatever the tenant configured instead of clearing it;
falseclears it. Setting it through any one protocol classifies the whole connection, including the tenant's default one.Tests
configureSAMLSettingsandconfigureOIDCSettingssend it when set, sendfalseexplicitly so the classification can be cleared rather than dropped as a falsy value, and omit it entirely when the caller says nothing.🤖 Generated with Claude Code