chaitali borole created ATLAS-5284:
--------------------------------------
Summary: Suuport 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: 2.4.0, 3.0.0
Reporter: chaitali borole
Assignee: chaitali borole
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)
