Skip to content

fix: allow admins to set app_identity via applications PUT API #1649#1727

Merged
DmytroZaichenkoDev merged 4 commits into
developmentfrom
fix/issue-1649-admin-managed-fields
Jul 17, 2026
Merged

fix: allow admins to set app_identity via applications PUT API #1649#1727
DmytroZaichenkoDev merged 4 commits into
developmentfrom
fix/issue-1649-admin-managed-fields

Conversation

@DmytroZaichenkoDev

Copy link
Copy Markdown
Contributor

Admin PUT to the public bucket is now authoritative for the admin-managed application fields (app_identity, allow_user_external_services), and app_identity becomes readable on raw resource GET for admins. This unblocks the Admin UI, which manages public-bucket applications through the plain applications PUT API (Core-direct) and therefore could never grant or display OBO trust with admin/apply as the only authoritative channel.

Applicable issues

Description of changes

  • Replaced the all-or-nothing AdminManagedFieldsWriteMode enum with a per-field AdminManagedFieldsWrite policy record: config file / admin-apply honor both fields (unchanged), an admin PUT to the public bucket honors exactly the fields present in the request body, every other write (non-admin, user-bucket, copy/move, publication) honors neither.
  • Presence-based semantics on the admin PUT: an omitted field inherits the stored value, so a read-modify-write client (Admin UI edit, chat UI admin edit) can never wipe a grant; present-as-null/false is an explicit revoke.
  • app_identity is returned on raw resource reads to admins only — it is verification material (a key hash or workload client_id), not a presentable credential; client_secret/code_verifier stripping stays unconditional for all roles. Deployment views and non-admin reads keep stripping it.
  • User-bucket writes stay strip/inherit even for admins, preserving the invariant that OBO grants can only exist on config apps and public-bucket apps.
  • Tests: admin public PUT grant proven end-to-end through the OBO gate; explicit revoke; wipe-safety on field-omitting edits; user-bucket admin PUT still stripped; admin read exposure and non-admin read stripping.

Checklist

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

🤖 Generated with Claude Code

…by admins #1649

The Admin UI creates and edits public-bucket applications through the plain
applications PUT API (Core-direct), so admin/apply cannot be the only
authoritative channel for app_identity / allow_user_external_services. An
admin PUT to the public bucket now honors each field when present in the body
(present-as-null/false explicitly revokes) and inherits when absent, so a
read-modify-write client can never wipe a grant. app_identity is returned on
raw resource reads to admins only - it is verification material (key hash /
workload client_id), not a credential; client_secret stripping stays
unconditional. Non-admin writes, user-bucket writes, copy/move and publication
keep strip/inherit semantics, so grants still cannot exist on user-bucket apps.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ai-dial-actions

This comment has been minimized.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ai-dial-actions

This comment has been minimized.

Comment thread server/src/main/java/com/epam/aidial/core/server/service/ApplicationService.java Outdated
…ction into the record #1649

Addresses review: class name must be a noun, 'write' argument renamed to
'mode', admin-public-write presence logic moved to a factory on the record.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ai-dial-actions

This comment has been minimized.

@ai-dial-actions

Copy link
Copy Markdown
Contributor

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@DmytroZaichenkoDev
DmytroZaichenkoDev merged commit 24f13aa into development Jul 17, 2026
9 checks passed
@DmytroZaichenkoDev
DmytroZaichenkoDev deleted the fix/issue-1649-admin-managed-fields branch July 17, 2026 09:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Headless on-behalf-of credential retrieval for external services (Scheduler support)

3 participants