fix: add authorization checks to Studio OAuth service endpoints#16127
fix: add authorization checks to Studio OAuth service endpoints#16127adilburaksen wants to merge 3 commits into
Conversation
OAuthHandler endpoints that create/read OAuth providers and credentials lacked any permission enforcement, while the adjacent ConnectionHandler enforces ContextAccessEnforcer checks on every endpoint. Add enforceOnParent(SYSTEM_APP_ENTITY, NamespaceId.SYSTEM, ...) to: - putOAuthProvider (CREATE) -- prevents unauthorized provider registration and arbitrary tokenRefreshURL injection - putOAuthCredential (CREATE) -- prevents unauthorized credential storage - getOAuthCredential (GET) -- prevents unauthorized OAuth access token retrieval Without these checks, any authenticated caller who can reach the Studio system-service route can read or exchange stored OAuth credentials for access tokens belonging to other users.
There was a problem hiding this comment.
Code Review
This pull request introduces authorization checks in OAuthHandler by integrating ContextAccessEnforcer into several endpoints. However, the current implementation will fail to compile because the checked AccessException is neither imported nor handled with try-catch blocks. Additionally, the use of StandardPermission.GET in getOAuthCredential violates the API contract for parent-level enforcement, and several other endpoints in the handler are still missing necessary authorization checks.
- Change StandardPermission.GET to LIST in getOAuthCredential; GET has isCheckedOnParent()=false so auth backends may skip the check entirely - Add LIST check to getAuthURL (was unprotected) - Add CREATE check to deleteOAuthProvider (was unprotected) - Add LIST check to getOAuthCredentialValidity (was unprotected) All six handler methods now enforce on the parent entity before executing any store or network operation.
|
Addressed all review feedback in the follow-up commit
Three uncovered endpoints: Added |
DELETE operation should enforce DELETE permission, not CREATE. The previous commit incorrectly used StandardPermission.CREATE for a delete endpoint.
55c88af to
e7d5e51
Compare
Summary
OAuthHandlerexposes three endpoints for managing OAuth providers and credentialsunder the Studio data-pipeline service:
GET /v1/oauth/provider/{provider}/credential/{credential}— returns an OAuth access tokenPUT /v1/oauth/provider/{provider}/credential/{credential}— stores credentialsPUT /v1/oauth/provider/{provider}— stores a provider configUnlike the adjacent
ConnectionHandler, which callsContextAccessEnforceron everyoperation,
OAuthHandlerperformed no authorization checks. Any authenticated user(or an unauthenticated request if the namespace is world-readable) could read back
OAuth access tokens stored by other users.
Fix
Initialize
ContextAccessEnforcerfromcontext.getContextAccessEnforcer()ininitialize(), then callenforceOnParent(EntityType.SYSTEM_APP_ENTITY, NamespaceId.SYSTEM, StandardPermission.GET/CREATE)at the entry point of eachhandler method, following the pattern already established in
ConnectionHandler.java.Testing
Existing
OAuthHandlerTestexercises the happy path. Authorization rejection iscovered by the enforcer's own unit tests; the pattern mirrors the already-tested
ConnectionHandlerusage.