carverauto/serviceradar

Fork

You've already forked serviceradar

Code Issues 190 Pull requests 16 Projects Releases 173 Packages Wiki Activity Actions

authentication #882

New issue

Closed

opened 2026-03-28 04:29:31 +00:00 by mfreeman451 · 1 comment

mfreeman451 commented

2026-03-28 04:29:31 +00:00

Owner

Copy link

Imported from GitHub.

Original GitHub issue: #2542
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2542
Original created: 2026-01-27T13:03:32Z

Issue: Implement Instance-Level Dynamic Authentication (SSO, OIDC, and SAML)

Description

Currently, the application relies on a single hardcoded admin user. We need to allow instance owners to configure their own Identity Providers (IdP) through the UI. Because each tenant has a dedicated application instance, the authentication configuration will be specific to that instance but stored in the database.

This will enable users to log in via modern OIDC (Google, Azure AD) or legacy Enterprise SAML.

User Story

As an Instance Admin, I want to configure my organization's SSO provider via the UI so that my users can log in using their corporate credentials without me having to manually edit configuration files or restart the server.

Technical Requirements

1. Database Schema (Instance-Specific)

We need a table to store the SSO configuration for the current instance in the platform schema

Create auth_settings table:
- provider_type: :oidc or :saml
- client_id / client_secret: (Encrypted via cloak or similar)
- idp_metadata_url: (For OIDC discovery or SAML)
- saml_issuer: The "Entity ID" for the service provider.
- is_enabled: Boolean to toggle SSO on/off.

2. Runtime Configuration Loader

Since Elixir/Phoenix libraries (like ueberauth) typically expect compile-time config, we need to load settings from the database at the moment the user initiates a login.

Implement a Dynamic Config Fetcher: A module that reads auth_settings from the DB and merges them into the Ueberauth configuration at runtime.
JIT (Just-In-Time) User Provisioning: When a user successfully authenticates via SSO, if they don't exist in the local users table, create them and assign default roles.

3. Admin Configuration UI (LiveView)

A dedicated settings page for instance administrators.

Protocol Toggle: Choice between "Standard (Email/Pass)", "OpenID Connect", and "SAML".
SAML Configuration:
- Fields for IdP Metadata URL or Metadata XML.
- Display the ACS (Assertion Consumer Service) URL that the admin must provide to their IdP (e.g., https://tenant.myapp.com/sso/sp/consume).
OIDC Configuration:
- Fields for Client ID, Client Secret, and Discovery URL.
Validation: A "Test Configuration" flow to ensure the app can successfully communicate with the IdP before locking out password-based login.

4. The Login Flow

Modify the Login Page to show an "Enterprise Login" button if SSO is enabled.
SSO Redirect: Route the user to the configured provider.
Callback Handling: Implement the controller logic to handle the returning JWT (OIDC) or XML Assertion (SAML), verify the signature, and establish the user session.

Task List

Migrations: Create auth_settings table.
Encryption: Ensure client_secret and SAML private keys are encrypted at rest.
SAML Support: Integrate ueberauth_saml for XML-based enterprise auth.
OIDC Support: Integrate ueberauth_oidcc for modern JSON-based enterprise auth.
UI: Build the "Authentication" settings tab in the Admin UI.
Session Management: Ensure SSO-initiated sessions follow the same RBAC rules as local users.

Security Considerations

SAML Signature Validation: Must strictly validate the IdP's certificate to prevent assertion spoofing.
Schema Isolation: Ensure that even if auth is shared, the User record is provisioned into the correct tenant-specific context as defined by the instance's DB connection.
Fallback Mechanism: Ensure the initial local admin can still log in via a "backdoor" or password if the SSO configuration is misconfigured (to avoid permanent lockouts).

Success Criteria

An admin can configure Okta/Azure via the UI.
A user can log in without a password via their corporate dashboard.
The system automatically creates a local record for the user on their first successful login.

Imported from GitHub. Original GitHub issue: #2542 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2542 Original created: 2026-01-27T13:03:32Z --- ## Issue: Implement Instance-Level Dynamic Authentication (SSO, OIDC, and SAML) ### Description Currently, the application relies on a single hardcoded admin user. We need to allow instance owners to configure their own Identity Providers (IdP) through the UI. Because each tenant has a dedicated application instance, the authentication configuration will be specific to that instance but stored in the database. This will enable users to log in via modern OIDC (Google, Azure AD) or legacy Enterprise SAML. ### User Story > As an **Instance Admin**, I want to configure my organization's SSO provider via the UI so that my users can log in using their corporate credentials without me having to manually edit configuration files or restart the server. --- ### Technical Requirements #### 1. Database Schema (Instance-Specific) We need a table to store the SSO configuration for the current instance in the `platform` schema - [ ] Create `auth_settings` table: - `provider_type`: `:oidc` or `:saml` - `client_id` / `client_secret`: (Encrypted via `cloak` or similar) - `idp_metadata_url`: (For OIDC discovery or SAML) - `saml_issuer`: The "Entity ID" for the service provider. - `is_enabled`: Boolean to toggle SSO on/off. #### 2. Runtime Configuration Loader Since Elixir/Phoenix libraries (like `ueberauth`) typically expect compile-time config, we need to load settings from the database at the moment the user initiates a login. - [ ] Implement a **Dynamic Config Fetcher**: A module that reads `auth_settings` from the DB and merges them into the `Ueberauth` configuration at runtime. - [ ] **JIT (Just-In-Time) User Provisioning:** When a user successfully authenticates via SSO, if they don't exist in the local `users` table, create them and assign default roles. #### 3. Admin Configuration UI (LiveView) A dedicated settings page for instance administrators. - [ ] **Protocol Toggle:** Choice between "Standard (Email/Pass)", "OpenID Connect", and "SAML". - [ ] **SAML Configuration:** - Fields for **IdP Metadata URL** or **Metadata XML**. - Display the **ACS (Assertion Consumer Service) URL** that the admin must provide to their IdP (e.g., `https://tenant.myapp.com/sso/sp/consume`). - [ ] **OIDC Configuration:** - Fields for `Client ID`, `Client Secret`, and `Discovery URL`. - [ ] **Validation:** A "Test Configuration" flow to ensure the app can successfully communicate with the IdP before locking out password-based login. #### 4. The Login Flow - [ ] Modify the Login Page to show an "Enterprise Login" button if SSO is enabled. - [ ] **SSO Redirect:** Route the user to the configured provider. - [ ] **Callback Handling:** Implement the controller logic to handle the returning JWT (OIDC) or XML Assertion (SAML), verify the signature, and establish the user session. --- ### Task List - [ ] **Migrations:** Create `auth_settings` table. - [ ] **Encryption:** Ensure `client_secret` and SAML private keys are encrypted at rest. - [ ] **SAML Support:** Integrate `ueberauth_saml` for XML-based enterprise auth. - [ ] **OIDC Support:** Integrate `ueberauth_oidcc` for modern JSON-based enterprise auth. - [ ] **UI:** Build the "Authentication" settings tab in the Admin UI. - [ ] **Session Management:** Ensure SSO-initiated sessions follow the same RBAC rules as local users. ### Security Considerations * **SAML Signature Validation:** Must strictly validate the IdP's certificate to prevent assertion spoofing. * **Schema Isolation:** Ensure that even if auth is shared, the `User` record is provisioned into the correct tenant-specific context as defined by the instance's DB connection. * **Fallback Mechanism:** Ensure the initial local admin can still log in via a "backdoor" or password if the SSO configuration is misconfigured (to avoid permanent lockouts). ### Success Criteria 1. An admin can configure Okta/Azure via the UI. 2. A user can log in without a password via their corporate dashboard. 3. The system automatically creates a local record for the user on their first successful login.

mfreeman451 commented

2026-03-28 04:29:32 +00:00

Author

Owner

Copy link

Imported GitHub comment.

Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2542#issuecomment-3809172483
Original created: 2026-01-28T06:02:23Z

ADDENDUM:

Issue: Implement Multi-Mode Authentication (SSO, OIDC, SAML, and Proxy JWT)

Description

We need to support diverse enterprise authentication patterns. While some instances will connect directly to an IdP (OIDC/SAML), others will sit behind an API Gateway (like Kong) that handles authentication upstream and passes a JWT to our application.

Technical Requirements

1. Database Schema Update

Expand the auth_settings table to support "Passive" (Proxy) and "Active" (SAML/OIDC) modes.

mode: Enum (:active vs :passive)
type: Enum (:oidc, :saml, :proxy_jwt)
config: JSONB field to store:
- For OIDC/SAML: Client IDs, Secrets, Metadata URLs.
- For Proxy JWT: Public Key (PEM), Expected Issuer, and Header Name.

2. Logic for "Proxy JWT" (Kong Support)

For instances behind a gateway, the app will not redirect to a login page.

JWT Validation Plug:
- Extract JWT from a configurable header.
- Verify signature using the stored Public Key/JWKS.
- Verify exp (expiration) and iss (issuer) claims.
User Extraction: Map JWT claims (e.g., sub or email) to the local User record.
Internal Auth Bypass: When proxy_jwt is active, the standard login page should be disabled or hidden.

3. Logic for "Active SSO" (OIDC/SAML)

For instances connecting directly to an IdP.

OIDC Flow: Use ueberauth_oidcc to handle the redirect and code exchange.
SAML Flow: Use ueberauth_saml to handle the XML-based redirection and assertion consumption.
Dynamic Config: Load client_id and metadata from the DB at the start of the request.

4. Admin UI (LiveView)

Mode Selection: Admin chooses "Direct SSO" or "Gateway/Proxy Auth."
Proxy Settings:
- Input for Public Key (PEM format).
- Input for Header Name (Default: Authorization).
Direct Settings:
- Input for OIDC/SAML credentials as previously defined.

5. User Provisioning (JIT)

Regardless of the method (SAML or Kong JWT), the system must check if the user exists in the local database schema.
If not, automatically create the user based on the claims provided in the token (Just-In-Time provisioning).

Task List

Migration: Create/Update auth_settings table.
Security: Implement JWT signature verification using JOSE.
Plug: Create AppWeb.Plugs.GatewayAuth to intercept Kong headers.
Strategy: Update AppWeb.AuthController to handle multiple Ueberauth strategies dynamically.
UI: Build the Admin "Auth Settings" tab.

Success Criteria

Scenario A (SAML): User clicks "Login," goes to Okta, comes back, and is logged in.
Scenario B (Kong): Admin pastes Kong's Public Key into the UI. Any request with a valid JWT from Kong is automatically logged in without ever seeing a login screen.
Local Sync: In both scenarios, a User record is created in the database to track permissions and history.

Pro-Tip for the Kong setup:

When Kong is handling auth, it often passes the user's details in a header like X-User-Email or X-User-Id. However, always verify the JWT signature inside your Phoenix app. If you just trust the header X-User-Email without a signature, a clever user could bypass Kong and send that header directly to your app to impersonate anyone.

Imported GitHub comment. Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2542#issuecomment-3809172483 Original created: 2026-01-28T06:02:23Z --- ADDENDUM: ## Issue: Implement Multi-Mode Authentication (SSO, OIDC, SAML, and Proxy JWT) ### Description We need to support diverse enterprise authentication patterns. While some instances will connect directly to an IdP (OIDC/SAML), others will sit behind an API Gateway (like Kong) that handles authentication upstream and passes a JWT to our application. ### Technical Requirements #### 1. Database Schema Update Expand the `auth_settings` table to support "Passive" (Proxy) and "Active" (SAML/OIDC) modes. - [ ] `mode`: Enum (`:active` vs `:passive`) - [ ] `type`: Enum (`:oidc`, `:saml`, `:proxy_jwt`) - [ ] `config`: JSONB field to store: - **For OIDC/SAML:** Client IDs, Secrets, Metadata URLs. - **For Proxy JWT:** Public Key (PEM), Expected Issuer, and Header Name. #### 2. Logic for "Proxy JWT" (Kong Support) For instances behind a gateway, the app will not redirect to a login page. - [ ] **JWT Validation Plug:** - Extract JWT from a configurable header. - Verify signature using the stored Public Key/JWKS. - Verify `exp` (expiration) and `iss` (issuer) claims. - [ ] **User Extraction:** Map JWT claims (e.g., `sub` or `email`) to the local User record. - [ ] **Internal Auth Bypass:** When `proxy_jwt` is active, the standard login page should be disabled or hidden. #### 3. Logic for "Active SSO" (OIDC/SAML) For instances connecting directly to an IdP. - [ ] **OIDC Flow:** Use `ueberauth_oidcc` to handle the redirect and code exchange. - [ ] **SAML Flow:** Use `ueberauth_saml` to handle the XML-based redirection and assertion consumption. - [ ] **Dynamic Config:** Load `client_id` and `metadata` from the DB at the start of the request. #### 4. Admin UI (LiveView) - [ ] **Mode Selection:** Admin chooses "Direct SSO" or "Gateway/Proxy Auth." - [ ] **Proxy Settings:** - Input for **Public Key (PEM format)**. - Input for **Header Name** (Default: `Authorization`). - [ ] **Direct Settings:** - Input for OIDC/SAML credentials as previously defined. #### 5. User Provisioning (JIT) - [ ] Regardless of the method (SAML or Kong JWT), the system must check if the user exists in the local database schema. - [ ] If not, automatically create the user based on the claims provided in the token (Just-In-Time provisioning). --- ### Task List - [ ] **Migration:** Create/Update `auth_settings` table. - [ ] **Security:** Implement JWT signature verification using `JOSE`. - [ ] **Plug:** Create `AppWeb.Plugs.GatewayAuth` to intercept Kong headers. - [ ] **Strategy:** Update `AppWeb.AuthController` to handle multiple Ueberauth strategies dynamically. - [ ] **UI:** Build the Admin "Auth Settings" tab. ### Success Criteria 1. **Scenario A (SAML):** User clicks "Login," goes to Okta, comes back, and is logged in. 2. **Scenario B (Kong):** Admin pastes Kong's Public Key into the UI. Any request with a valid JWT from Kong is automatically logged in without ever seeing a login screen. 3. **Local Sync:** In both scenarios, a `User` record is created in the database to track permissions and history. --- ### Pro-Tip for the Kong setup: When Kong is handling auth, it often passes the user's details in a header like `X-User-Email` or `X-User-Id`. However, **always** verify the **JWT signature** inside your Phoenix app. If you just trust the header `X-User-Email` without a signature, a clever user could bypass Kong and send that header directly to your app to impersonate anyone.

mfreeman451 closed this issue

2026-03-28 04:29:32 +00:00

No Branch/Tag specified

staging

2406-feat-agent-fleet-management-secure-self-update-system

bug/k8s-helm-deployments

chore/k8s-arc-update

rust-fix

2371-analytics-stats-cards-should-abbreviate-numbers

chore/perl-cleanup

2942-featweb-ng-add-logs-tab-to-device-details-page

192-feat-tftp-server

mikemiles-dev/feature/netflow_collection

testing

dependabot/cargo/hostname-0.4.1

dependabot/cargo/redis-1.0.1

dependabot/cargo/bb8-0.9.0

dependabot/cargo/rcgen-0.14.6

dependabot/cargo/hyper-1.8.1

dependabot/cargo/hyper-util-0.1.19

dependabot/cargo/clap-4.5.51

dependabot/cargo/thiserror-2.0.17

dependabot/cargo/time-tz-2.0.0

dependabot/cargo/tonic-build-0.14.2

main

dependabot/npm_and_yarn/docs/mdast-util-to-hast-13.2.1

815-feat-support-win32-for-agentpoller

gh-pages

v1.2.5

v1.2.4

v1.2.3

v1.2.2

v1.2.1

v1.2.0

v1.1.2

v1.1.0

v1.0.92

v1.0.91

v1.0.90

v1.0.89

v1.0.88

v1.0.87

v1.0.86

v1.0.85

v1.0.84

v1.0.83

v1.0.82

v1.0.81

v1.0.78

v1.0.77

v1.0.76

v1.0.70

v1.0.69

v1.0.68

v1.0.67

v1.0.66

v1.0.65

v1.0.64

v1.0.63

v1.0.62

v1.0.61

v1.0.60

v1.0.59

v1.0.58

1.0.57

v1.0.56

v1.0.55

v1.0.54-pre5

v1.0.53

v1.0.53-pre19

v1.0.53-pre18

v1.0.53-pre17

v1.0.53-pre15

1.0.53-pre10

1.0.53-pre9

1.0.53-pre8

1.0.53-pre7

1.0.53-pre6

1.0.53-pre5

1.0.53-pre4

1.0.53-pre3

1.0.53-pre2

1.0.53-pre1

1.0.52

1.0.51

1.0.50

1.0.49

1.0.49-pre5

1.0.49-pre4

1.0.49-pre3

1.0.49-pre2

1.0.48

1.0.48-rc2

1.0.48-rc1

1.0.48-pre8

1.0.48-pre7

1.0.48-pre6

1.0.48-pre5

1.0.48-pre4

1.0.48-pre3

1.0.48-pre2

1.0.48-pre1

1.0.47

1.0.47-pre8

1.0.47-pre7

1.0.47-pre6

1.0.47-pre5

1.0.47-pre4

1.0.47-pre3

1.0.47-pre2

1.0.47-pre1

1.0.46

1.0.46-pre9

1.0.46-pre8

1.0.46-pre7

1.0.46-pre6

1.0.46-pre5

1.0.46-pre4

1.0.46-pre3

1.0.46-pre2

1.0.46-pre1

1.0.45

1.0.44

1.0.44-pre12

1.0.44-pre11

1.0.44-pre10

1.0.44-pre9

1.0.44-pre8

1.0.44-pre7

1.0.44-pre6

1.0.44-pre5

1.0.44-pre4

1.0.44-pre3

1.0.44-pre2

1.0.44-pre1

1.0.43

1.0.42

1.0.41

1.0.41-pre1

1.0.40

1.0.40-pre11

1.0.40-pre10

1.0.40-pre9

1.0.40-pre8

1.0.40-pre7

1.0.40-pre6

1.0.40-pre5

1.0.40-pre4

1.0.40-pre3

1.0.40-pre2

1.0.40-pre1

1.0.39

1.0.38

1.0.37

1.0.36

1.0.36-pre5

1.0.36-pre4

1.0.36-pre3

1.0.36-pre2

1.0.35

1.0.35-pre3

1.0.35-pre2

1.0.35-pre

1.0.34-pre3

1.0.34-pre2

1.0.34-pre1

1.0.33

1.0.33-pre2

1.0.33-pre

1.0.32

1.0.31

1.0.30

1.0.29

1.0.28

1.0.27

1.0.26

1.0.25

1.0.24

1.0.23

1.0.22

1.0.21

1.0.20

1.0.19

1.0.18

1.0.17

1.0.16

1.0.15

1.0.14

1.0.13

1.0.11

1.0.10

1.0.9

1.0.8

1.0.7

1.0.6

1.0.5

1.0.4

1.0.3

1.0.2

1.0.1

1.0.0

Labels

Clear labels

1week

2weeks

Failed compliance check

IP cameras

NATS

NATS JetStream

Possible security concern

Something isn't working

build

checkers

ci-cd

continuous integration-continuous deployments

cleanup

cnpg

cloud-native postgres

Pull requests that update a dependency file

device-management

documentation

Improvements or additions to documentation

duplicate

This issue or pull request already exists

dusk

ebpf

enhancement

New feature or request

Pull requests that update GitHub Actions code

Pull requests that update Go code

good first issue

Good for newcomers

help wanted

Extra attention is needed

invalid

This doesn't seem right

javascript

Pull requests that update Javascript code

Oracle Linux related issues

otel

opentelemetry logs, traces, metrics

plug-in

proton

timeplus proton streaming database

python

question

Further information is requested

Pull requests that update rust code

sdk

security

serviceradar-agent

serviceradar-agent-gateway

This will not be worked on

zen-engine

No labels

1week

2weeks

Failed compliance check

IP cameras

NATS

Possible security concern

serviceradar-agent-gateway

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

carverauto/serviceradar#882

Reference in a new issue

Repository

carverauto/serviceradar

Title

Body

No description provided.

Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?

Rows
Columns