[
https://issues.apache.org/jira/browse/ATLAS-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chaitali borole updated ATLAS-5284:
-----------------------------------
Summary: Support JWT authentication for Atlas (was: Suuport JWT
authentication for Atlas)
> 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)
