Skip to content

Repository files navigation

Elastauth

Docker Repository on QuayCIMaintainabilityGo Reference

Kibana LDAP/Active Directory Authentication Proxy

This project provides a specialized Traefik forwardAuth proxy solution to enable LDAP/Active Directory (AD) authentication for Kibana/Elasticsearch without requiring a paid subscription.

While designed and tested for Traefik, the core concepts can be adapted for other reverse proxies that support a forwardAuth mechanism (e.g., Nginx).


🎯 Quick Overview

elastauth acts as a secure bridge between your infrastructure components:

User → Traefik → Authelia (LDAP Check) → elastauth (Account Mgmt) → Kibana

The system ensures users are authenticated against AD/LDAP while maintaining seamless access to Kibana through automatically managed local accounts with role-based permissions.


💡 How It Works: Multi-Stage Authentication Flow

The system orchestrates a two-stage authentication process to ensure AD security is maintained while integrating with Kibana's local user system.

Stage 1: LDAP Authentication (Authelia)

  1. User Request: A user attempts to access Kibana, intercepted by Traefik.
  2. External Check: Traefik's chain middleware forwards the request to Authelia (forwardAuth #1).
  3. AD Validation:Authelia validates credentials against your LDAP/Active Directory server.
  4. Result:
    • Success (HTTP 200): Authelia enriches the request with user headers (remote-user, remote-groups, remote-email) and passes control to the next middleware.
    • Failure: Request is denied or redirected by Authelia.

Stage 2: Kibana Account Management (elastauth)

Upon successful LDAP authentication, elastauth handles local account management:

  1. Proxy Receives Request: Traefik forwards the authenticated request with user headers to elastauth (forwardAuth #2).
  2. Cache Validation: elastauth checks Redis for a valid cached password for this user.
  3. If Cache is Valid:
    • Retrieves the cached credentials and proceeds.
  4. If Cache is Expired/Missing:
    • Generates a new, random, short-lived password (separate from LDAP password).
    • Creates or updates the local Kibana account via the Elasticsearch API.
    • Maps the user's AD groups to appropriate Kibana roles.
    • Stores the new password and expiry in Redis.
  5. Generate Auth Header: elastauth creates an Authorization: Basic header with the username and password.
  6. Return to Traefik: Traefik receives the auth header and forwards the request to Kibana.

Stage 3: Transparent Login (Kibana)

  1. Final Forward: Traefik proxies the original request to Kibana with the generated Authorization header.
  2. Instant Access: Kibana accepts the Basic auth, logging the user in with their managed local account and inherited AD roles.

Security Note: Local Kibana passwords are short-lived and automatically regenerated on each access, ensuring a strong security posture without requiring user password changes.


🔗 Authentication Headers

The following headers are passed through the authentication chain and used by elastauth for account management:

HeaderPurpose
remote-userUsername/login identifier
remote-emailUser's email address
remote-groupsComma-separated list of AD groups
remote-nameUser's full name

📊 Visual Flows

Diagram 1: High-Level Flow (Decision & Data Flow)

This diagram illustrates the complete authentication journey with decision points and component interactions:

flowchart TD
Start[Request]@{shape: cloud} -- 1. starting request --> ForwardAuthAuthelia
subgraph LDAP[LDAP]
end
subgraph Kibana[Kibana]
end
subgraph Redis[Redis]
end
AccessGranted -- 9 --> Kibana
Authelia <-- 3. veryfying credentials against LDAP --> LDAP
subgraph Traefik
subgraph chain middleware
ForwardAuthAuthelia(forward auth Authelia)
ForwardAuthElastauth(forward auth Elastauth)
end
subgraph Result
AccessDenied[Access Denied]
AccessGranted[Access Granted]
end
end
subgraph Authelia[Authelia]
ForwardAuthAuthelia -- 2. forwarding request to Authelia --> Authelia
Authelia -- 4a. Authentication Successfull --> ForwardAuthElastauth
Authelia -- 4b. Authentication Failed --> AccessDenied
end
subgraph Elastauth(Elastauth)@{img: "https://github.com/wasilak/elastauth/blob/main/gopher.png?raw=true", h: 200, constraint: on}
CacheValid{Is credentials cache valid?}
GenerateRandomPassword[Generate random password]
UpsertUser[Create/update Elasticsearch/Kibana local account]
GenerateAuth[Generate Basic Authorization Header]
AuthCredentials[Auth Credentials into Basic Auth header]
ForwardAuthElastauth -- 5. Forwarding User details as headers --> Elastauth
Elastauth --> CacheValid
CacheValid -- 6a. Yes --> Redis
CacheValid -- 6b. No --> GenerateRandomPassword
GenerateRandomPassword --> UpsertUser
UpsertUser --> GenerateAuth
GenerateAuth -- 7b --> AuthCredentials
Redis -- 7a. Getting cached credentials --> AuthCredentials
AuthCredentials -- 8--> AccessGranted
end
Loading

Key Decision Points:

  • Auth OK? - Authelia validates user credentials against LDAP
  • Is cache valid? - elastauth checks Redis for existing cached credentials
  • Color coding: 🟢 Green = Success path, 🔴 Red = Failure path

Diagram 2: Sequence Flow (Step-by-Step Timeline)

This diagram shows the detailed sequence of interactions between all components in chronological order:

sequenceDiagram
participant User as User/Request
participant T_Chain as Traefik (chain middleware)
participant AutheliaMW as forward auth Authelia
participant ElastauthMW as forward auth Elastauth
participant A as Authelia
participant L as LDAP
participant P as Elastauth
participant R as Redis
participant K as Kibana
User->>T_Chain: 1. starting request
%% First Middleware: Authelia (Authentication)
T_Chain->>AutheliaMW: Call First Middleware
AutheliaMW->>A: 2. forwarding request to Authelia
A->>L: 3. veryfying credentials against LDAP
L-->>A: Credentials Check Result
alt 4a. Authentication Successful (200 OK)
A-->>AutheliaMW: Auth Success (200 OK)
AutheliaMW-->>T_Chain: Continue Chain (with user headers)
%% Second Middleware: Elastauth (Account Management)
T_Chain->>ElastauthMW: Call Second Middleware
ElastauthMW->>P: 5. Forwarding User details as headers
P->>R: 6a. Is credentials cache valid?
alt 7a. Cache Valid (Yes)
R-->>P: 7a. Getting cached credentials
else 6b. Cache Invalid (No)
P->>P: 6b. Generate random password
P->>K: UpsertUser (Create/update local account)
K-->>P: Account Update Success
P->>P: Generate Basic Authorization Header
P->>R: Cache New Credentials & Expiry
end
P-->>ElastauthMW: 8. Authorization: Basic Header
ElastauthMW-->>T_Chain: Auth Header Acquired
%% Final Forward to Kibana
T_Chain->>K: 9. Access Granted (Final Forward to Kibana)
K-->>User: Kibana Interface / Content
else 4b. Authentication Failed
A-->>AutheliaMW: 4b. Authentication Failed
AutheliaMW-->>T_Chain: Access Denied
T_Chain-->>User: Access Denied / Redirect
end
Loading

Timeline Highlights:

  • Steps 1-3: Request validation phase (Traefik → Authelia → LDAP)
  • Steps 4-5: Cache check phase (elastauth receives validated request)
  • Steps 6-8: Account management phase (password generation/caching)
  • Step 9: Final access granted to Kibana

About

forwardAuth proxy for Kibana providing integration for ldap

Topics

Resources

Stars

16 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages