[
https://issues.apache.org/jira/browse/ATLAS-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chaitali borole updated ATLAS-5284:
-----------------------------------
Description:
Background
* Implement JWT-based authentication across Atlas ecosystem components to
enable secure, token-based communication between servers and hooks.
Problem Statement
Servers:
* Atlas core server
* Notification Ingestion Server
Hooks/Libraries:
* Hive Hook
* atlas-notification & atlas-client libraries (used by Spark, Impala hooks)
Key Requirements:
Server-side (Atlas + Notification Server):
* Add /auth/token endpoint for JWT issuance (OAuth2 compliant)
* Validate JWT in all hook endpoints (/notification/ingest, /entities/*)
* Support configurable JWKS endpoint for public key rotation
* Fallback to Basic Auth during migration
Client-side (Hooks/Libraries):
* Update atlas-client to acquire/manage JWT tokens
* Add token refresh logic (cache + auto-renewal)
* Support client credentials flow for service accounts
* Graceful fallback to Basic Auth for legacy hooks
Security: Token expiry: as mentioned by user, rotation every 30min, audit
logging of auth failures.
Proposed solution:
Header-based authentication (high level)
* Optional mode controlled by atlas.authn.header.*.
* A trusted proxy sends username (and optionally roles) in configurable HTTP
headers.
* Atlas maps those headers into the Spring Security context so the user is
treated as logged in without Atlas validating a password or token (trust is on
the network / proxy).
JWT authentication (high level)
* Validates JWTs from Authorization: Bearer and/or a cookie using JWKS and/or a
public key from config (often aligned with Knox SSO settings).
* On success, Atlas puts a normal Spring Security principal on the context;
browsers may be sent to login if JWT auth is attempted but fails.
* Java clients can send Bearer tokens when atlas.jwt.source is set so the token
is loaded from env/file/credentials as configured.
3 types of sources are available -environment ,File and CRED file based token
provision
Acceptance Criteria:
* Everything is additive by default. Header auth stays off until
atlas.authn.header.enabled=true and the right headers are set. With the flag
false, that filter does not establish a user; the rest of the chain behaves as
before.
* Existing authentications works as expected when header based is enabled
* JWT runs only when a request “looks like” JWT. The wrapper runs JWT handling
when there is no existing authenticated user and the request has a Bearer
header or the configured JWT cookie. API clients and browsers that never send
those stay on the previous login / SSO / basic / Kerberos paths.
* Filter order keeps earlier mechanisms first. Header pre-auth → Knox SSO →
then JWT wrapper (after Knox), then the same Basic / Kerberos / CSRF wiring as
today. Anything that already authenticates you before JWT runs is left alone.
* Audit / request id: If header pre-auth does not set a request id, AuditFilter
still falls back to a new UUID per request, like today.
* Java clients: AtlasBaseClient only switches to JWT + Bearer when
atlas.jwt.source is set. If that property is absent, client behavior matches
the old Kerberos / TLS / basic-auth logic.
was:
Background
* Implement JWT-based authentication across Atlas ecosystem components to
enable secure, token-based communication between servers and hooks.
Problem Statement
Servers:
* Atlas core server
* Notification Ingestion Server
Hooks/Libraries:
* Hive Hook
* atlas-notification & atlas-client libraries (used by Spark, Impala hooks)
Key Requirements:
Server-side (Atlas + Notification Server):
* Add /auth/token endpoint for JWT issuance (OAuth2 compliant)
* Validate JWT in all hook endpoints (/notification/ingest, /entities/*)
* Support configurable JWKS endpoint for public key rotation
* Fallback to Basic Auth during migration
Client-side (Hooks/Libraries):
* Update atlas-client to acquire/manage JWT tokens
* Add token refresh logic (cache + auto-renewal)
* Support client credentials flow for service accounts
* Graceful fallback to Basic Auth for legacy hooks
Security: Token expiry: as mentioned by user, rotation every 30min, audit
logging of auth failures.
Proposed solution:
* Header-based authentication (high level)
* Optional mode controlled by atlas.authn.header.*.
* A trusted proxy sends username (and optionally roles) in configurable HTTP
headers.
* Atlas maps those headers into the Spring Security context so the user is
treated as logged in without Atlas validating a password or token (trust is on
the network / proxy).
* JWT authentication (high level)
* Validates JWTs from Authorization: Bearer and/or a cookie using JWKS and/or a
public key from config (often aligned with Knox SSO settings).
* On success, Atlas puts a normal Spring Security principal on the context;
browsers may be sent to login if JWT auth is attempted but fails.
* Java clients can send Bearer tokens when atlas.jwt.source is set so the token
is loaded from env/file/credentials as configured.
3 types of sources are available -environment ,File and CRED file based token
provision
Acceptance Criteria:
* Everything is additive by default. Header auth stays off until
atlas.authn.header.enabled=true and the right headers are set. With the flag
false, that filter does not establish a user; the rest of the chain behaves as
before.
* Existing authentications works as expected when header based is enabled
* JWT runs only when a request “looks like” JWT. The wrapper runs JWT handling
when there is no existing authenticated user and the request has a Bearer
header or the configured JWT cookie. API clients and browsers that never send
those stay on the previous login / SSO / basic / Kerberos paths.
* Filter order keeps earlier mechanisms first. Header pre-auth → Knox SSO →
then JWT wrapper (after Knox), then the same Basic / Kerberos / CSRF wiring as
today. Anything that already authenticates you before JWT runs is left alone.
* Audit / request id: If header pre-auth does not set a request id, AuditFilter
still falls back to a new UUID per request, like today.
* Java clients: AtlasBaseClient only switches to JWT + Bearer when
atlas.jwt.source is set. If that property is absent, client behavior matches
the old Kerberos / TLS / basic-auth logic.
> Support JWT authentication for Atlas
> ------------------------------------
>
> Key: ATLAS-5284
> URL: https://issues.apache.org/jira/browse/ATLAS-5284
> Project: Atlas
> Issue Type: New Feature
> Components: atlas-core
> Affects Versions: 3.0.0, 2.4.0
> Reporter: chaitali borole
> Assignee: chaitali borole
> Priority: Major
>
> Background
> * Implement JWT-based authentication across Atlas ecosystem components to
> enable secure, token-based communication between servers and hooks.
> Problem Statement
> Servers:
> * Atlas core server
> * Notification Ingestion Server
> Hooks/Libraries:
> * Hive Hook
> * atlas-notification & atlas-client libraries (used by Spark, Impala hooks)
> Key Requirements:
> Server-side (Atlas + Notification Server):
> * Add /auth/token endpoint for JWT issuance (OAuth2 compliant)
> * Validate JWT in all hook endpoints (/notification/ingest, /entities/*)
> * Support configurable JWKS endpoint for public key rotation
> * Fallback to Basic Auth during migration
> Client-side (Hooks/Libraries):
> * Update atlas-client to acquire/manage JWT tokens
> * Add token refresh logic (cache + auto-renewal)
> * Support client credentials flow for service accounts
> * Graceful fallback to Basic Auth for legacy hooks
> Security: Token expiry: as mentioned by user, rotation every 30min, audit
> logging of auth failures.
> Proposed solution:
> Header-based authentication (high level)
> * Optional mode controlled by atlas.authn.header.*.
> * A trusted proxy sends username (and optionally roles) in configurable HTTP
> headers.
> * Atlas maps those headers into the Spring Security context so the user is
> treated as logged in without Atlas validating a password or token (trust is
> on the network / proxy).
> JWT authentication (high level)
> * Validates JWTs from Authorization: Bearer and/or a cookie using JWKS and/or
> a public key from config (often aligned with Knox SSO settings).
> * On success, Atlas puts a normal Spring Security principal on the context;
> browsers may be sent to login if JWT auth is attempted but fails.
> * Java clients can send Bearer tokens when atlas.jwt.source is set so the
> token is loaded from env/file/credentials as configured.
> 3 types of sources are available -environment ,File and CRED file based token
> provision
> Acceptance Criteria:
> * Everything is additive by default. Header auth stays off until
> atlas.authn.header.enabled=true and the right headers are set. With the flag
> false, that filter does not establish a user; the rest of the chain behaves
> as before.
> * Existing authentications works as expected when header based is enabled
> * JWT runs only when a request “looks like” JWT. The wrapper runs JWT
> handling when there is no existing authenticated user and the request has a
> Bearer header or the configured JWT cookie. API clients and browsers that
> never send those stay on the previous login / SSO / basic / Kerberos paths.
> * Filter order keeps earlier mechanisms first. Header pre-auth → Knox SSO →
> then JWT wrapper (after Knox), then the same Basic / Kerberos / CSRF wiring
> as today. Anything that already authenticates you before JWT runs is left
> alone.
> * Audit / request id: If header pre-auth does not set a request id,
> AuditFilter still falls back to a new UUID per request, like today.
> * Java clients: AtlasBaseClient only switches to JWT + Bearer when
> atlas.jwt.source is set. If that property is absent, client behavior matches
> the old Kerberos / TLS / basic-auth logic.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
