[ 
https://issues.apache.org/jira/browse/ATLAS-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Umesh Patil updated ATLAS-5365:
-------------------------------
    Description: 
h2. Summary

The rest-notification-webapp module (introduced in ATLAS-5207 / PR #622) is 
missing authorization on the Kafka hook notification REST endpoint POST 
/api/atlas/v2/notification/topic/\{topicName}.Rest-notification did not — 
allowing authenticated read-only users (e.g. DATA_SCIENTIST / rangertagsync) to 
POST hook messages (including ENTITY_CREATE_V2) to ATLAS_HOOK and reach the 
entity pipeline via Kafka.
h2. Related work
 * Parent feature JIRA: ATLAS-5207 (Closed — rest-notification module port)
 * Merged PR: [GitHub PR #622|https://github.com/apache/atlas/pull/622]
 * Webapp reference (correct behavior): 
webapp/src/main/java/org/apache/atlas/web/rest/NotificationREST.java line ~91

h2. Problem (before fix)
||Entry point||Authorization||
| | |
|rest-notification NotificationREST|Missing verifyAccess — VULNERABLE|

*Attack path:* Read-only user authenticates to rest-notification server (port 
41000) → POST ENTITY_CREATE_V2 JSON to 
/rest/api/atlas/v2/notification/topic/ATLAS_HOOK → message published to Kafka → 
main Atlas consumer processes entity create/update/delete.
h2. Expected behavior (requirement)

"Please refer to the authorization added in NotificationREST in Webapp module 
and apply it accordingly."

Read-only users must receive HTTP 403 on rest-notification POST. Admin users 
must still receive HTTP 204. Unauthenticated users must receive HTTP 401.
h2. Proposed fix

Add the same authorization line as webapp 
NotificationREST.handleNotifications():
{code:java}
AtlasAuthorizationUtils.verifyAccess(
    new AtlasAdminAccessRequest(AtlasPrivilege.SERVICE_NOTIFICATION_POST),
    "post on rest notification service");
{code}
*File:* 
rest-notification-webapp/src/main/java/org/apache/atlas/notification/rest/web/rest/NotificationREST.java

*Imports required:*
 * org.apache.atlas.authorize.AtlasAdminAccessRequest
 * org.apache.atlas.authorize.AtlasAuthorizationUtils
 * org.apache.atlas.authorize.AtlasPrivilege

h2. How to test
 # Start main Atlas (port 21000): atlas_start.py
 # Start rest-notification (port 41000): 
rest-notification-webapp/bin/rest_start.py
 # Distro default credentials: admin/admin, rangertagsync/rangertagsync

 * Test A — read-only POST to rest-notification → expect HTTP 403
 * Test B — admin POST to rest-notification → expect HTTP 204
 * Test C — read-only POST to webapp → expect HTTP 403 (unchanged)
 * Test D — entity GET after Test A → expect HTTP 404 (not created)
 * Test F — unauthenticated POST → expect HTTP 401

Example curl (read-only, must fail with 403):
{code:bash}
curl -v -u rangertagsync:rangertagsync \
  -X POST -H "Content-Type: application/json" \
  -d @/tmp/hook_entity_create.json \
  "http://localhost:41000/rest/api/atlas/v2/notification/topic/ATLAS_HOOK";
{code}

  was:
h2. Summary

The rest-notification-webapp module (introduced in ATLAS-5207 / PR #622) is 
missing authorization on the Kafka hook notification REST endpoint POST 
/api/atlas/v2/notification/topic/\{topicName}.Rest-notification did not — 
allowing authenticated read-only users (e.g. DATA_SCIENTIST / rangertagsync) to 
POST hook messages (including ENTITY_CREATE_V2) to ATLAS_HOOK and reach the 
entity pipeline via Kafka.
h2. Related work
 * Parent feature JIRA: ATLAS-5207 (Closed — rest-notification module port)
 * Merged PR: [GitHub PR #622|https://github.com/apache/atlas/pull/622]
 * Webapp reference (correct behavior): 
webapp/src/main/java/org/apache/atlas/web/rest/NotificationREST.java line ~91

h2. Problem (before fix)
||Entry point||Authorization||
|webapp NotificationREST|verifyAccess(SERVICE_NOTIFICATION_POST) — OK|
|rest-notification NotificationREST|Missing verifyAccess — VULNERABLE|

*Attack path:* Read-only user authenticates to rest-notification server (port 
41000) → POST ENTITY_CREATE_V2 JSON to 
/rest/api/atlas/v2/notification/topic/ATLAS_HOOK → message published to Kafka → 
main Atlas consumer processes entity create/update/delete.
h2. Expected behavior (requirement)

"Please refer to the authorization added in NotificationREST in Webapp module 
and apply it accordingly."

Read-only users must receive HTTP 403 on rest-notification POST. Admin users 
must still receive HTTP 204. Unauthenticated users must receive HTTP 401.
h2. Proposed fix

Add the same authorization line as webapp 
NotificationREST.handleNotifications():
{code:java}
AtlasAuthorizationUtils.verifyAccess(
    new AtlasAdminAccessRequest(AtlasPrivilege.SERVICE_NOTIFICATION_POST),
    "post on rest notification service");
{code}
*File:* 
rest-notification-webapp/src/main/java/org/apache/atlas/notification/rest/web/rest/NotificationREST.java

*Imports required:*
 * org.apache.atlas.authorize.AtlasAdminAccessRequest
 * org.apache.atlas.authorize.AtlasAuthorizationUtils
 * org.apache.atlas.authorize.AtlasPrivilege

h2. How to test
 # Start main Atlas (port 21000): atlas_start.py
 # Start rest-notification (port 41000): 
rest-notification-webapp/bin/rest_start.py
 # Distro default credentials: admin/admin, rangertagsync/rangertagsync

 * Test A — read-only POST to rest-notification → expect HTTP 403
 * Test B — admin POST to rest-notification → expect HTTP 204
 * Test C — read-only POST to webapp → expect HTTP 403 (unchanged)
 * Test D — entity GET after Test A → expect HTTP 404 (not created)
 * Test F — unauthenticated POST → expect HTTP 401

Example curl (read-only, must fail with 403):
{code:bash}
curl -v -u rangertagsync:rangertagsync \
  -X POST -H "Content-Type: application/json" \
  -d @/tmp/hook_entity_create.json \
  "http://localhost:41000/rest/api/atlas/v2/notification/topic/ATLAS_HOOK";
{code}


> Missing SERVICE_NOTIFICATION_POST authorization on rest-notification 
> NotificationREST POST /topic/{topicName}.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ATLAS-5365
>                 URL: https://issues.apache.org/jira/browse/ATLAS-5365
>             Project: Atlas
>          Issue Type: Bug
>          Components:  atlas-core
>    Affects Versions: 3.0.0
>         Environment: Apache Atlas 3.0.0-SNAPSHOT (local distro build from mvn 
> clean install)
> Services:
> - Main Atlas webapp: http://localhost:21000
> - Rest-notification server: http://localhost:41000
> - Embedded Kafka: localhost:9027
> Authentication: file-based (users-credentials.properties)
> Authorizer: simple (atlas-simple-authz-policy.json)
> Test users:
> - admin / admin (ROLE_ADMIN — has SERVICE_NOTIFICATION_POST)
> - rangertagsync / rangertagsync (DATA_SCIENTIST — read-only)
> Relevant config:
> - atlas.rest.server.http.port=41000 
> (distro/src/conf/atlas-application.properties)
> - Rest URL prefix: /rest/* (rest-notification-webapp WEB-INF/web.xml)
>            Reporter: Umesh Patil
>            Assignee: Umesh Patil
>            Priority: Major
>              Labels: ATLAS-5207-followup, authorization, rest-notification
>             Fix For: 3.0.0
>
>         Attachments: Screenshot from 2026-08-05 12-10-17.png
>
>   Original Estimate: 24h
>          Time Spent: 0.5h
>  Remaining Estimate: 23.5h
>
> h2. Summary
> The rest-notification-webapp module (introduced in ATLAS-5207 / PR #622) is 
> missing authorization on the Kafka hook notification REST endpoint POST 
> /api/atlas/v2/notification/topic/\{topicName}.Rest-notification did not — 
> allowing authenticated read-only users (e.g. DATA_SCIENTIST / rangertagsync) 
> to POST hook messages (including ENTITY_CREATE_V2) to ATLAS_HOOK and reach 
> the entity pipeline via Kafka.
> h2. Related work
>  * Parent feature JIRA: ATLAS-5207 (Closed — rest-notification module port)
>  * Merged PR: [GitHub PR #622|https://github.com/apache/atlas/pull/622]
>  * Webapp reference (correct behavior): 
> webapp/src/main/java/org/apache/atlas/web/rest/NotificationREST.java line ~91
> h2. Problem (before fix)
> ||Entry point||Authorization||
> | | |
> |rest-notification NotificationREST|Missing verifyAccess — VULNERABLE|
> *Attack path:* Read-only user authenticates to rest-notification server (port 
> 41000) → POST ENTITY_CREATE_V2 JSON to 
> /rest/api/atlas/v2/notification/topic/ATLAS_HOOK → message published to Kafka 
> → main Atlas consumer processes entity create/update/delete.
> h2. Expected behavior (requirement)
> "Please refer to the authorization added in NotificationREST in Webapp module 
> and apply it accordingly."
> Read-only users must receive HTTP 403 on rest-notification POST. Admin users 
> must still receive HTTP 204. Unauthenticated users must receive HTTP 401.
> h2. Proposed fix
> Add the same authorization line as webapp 
> NotificationREST.handleNotifications():
> {code:java}
> AtlasAuthorizationUtils.verifyAccess(
>     new AtlasAdminAccessRequest(AtlasPrivilege.SERVICE_NOTIFICATION_POST),
>     "post on rest notification service");
> {code}
> *File:* 
> rest-notification-webapp/src/main/java/org/apache/atlas/notification/rest/web/rest/NotificationREST.java
> *Imports required:*
>  * org.apache.atlas.authorize.AtlasAdminAccessRequest
>  * org.apache.atlas.authorize.AtlasAuthorizationUtils
>  * org.apache.atlas.authorize.AtlasPrivilege
> h2. How to test
>  # Start main Atlas (port 21000): atlas_start.py
>  # Start rest-notification (port 41000): 
> rest-notification-webapp/bin/rest_start.py
>  # Distro default credentials: admin/admin, rangertagsync/rangertagsync
>  * Test A — read-only POST to rest-notification → expect HTTP 403
>  * Test B — admin POST to rest-notification → expect HTTP 204
>  * Test C — read-only POST to webapp → expect HTTP 403 (unchanged)
>  * Test D — entity GET after Test A → expect HTTP 404 (not created)
>  * Test F — unauthenticated POST → expect HTTP 401
> Example curl (read-only, must fail with 403):
> {code:bash}
> curl -v -u rangertagsync:rangertagsync \
>   -X POST -H "Content-Type: application/json" \
>   -d @/tmp/hook_entity_create.json \
>   "http://localhost:41000/rest/api/atlas/v2/notification/topic/ATLAS_HOOK";
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to