LDAP Portal
Self-Service-Portal fuer LLDAP mit NestJS API und Angular Frontend.
Funktionen
- Registrierung mit E-Mail-Verifikation
- Login gegen LDAP/LLDAP
- Passwortaenderung nach erfolgreichem LDAP-Login
- Passwort-Reset ueber eigene Tokens und SMTP
- Profilbearbeitung, E-Mail-Aenderung mit Verifikation und Account-Loeschanfrage
- Admin-Bereiche fuer Registrierungen, Nutzer, Gruppen und Audit
- Audit-Events fuer sicherheitsrelevante Aktionen in MySQL
- OpenID Connect Provider fuer Web-SSO
- Docker-Compose Setup fuer API und Web mit externer MySQL- und LLDAP-Anbindung
Lokale Entwicklung
cp .env.example .env
npm install
npm run start:api
npm run start:web
In der lokalen Entwicklung laeuft die API standardmaessig auf http://localhost:3000, das Frontend auf http://localhost:4200.
Docker Compose
cp .env.example .env
docker compose up --build
Passe vor dem Start mindestens DATABASE_URL, JWT_SECRET, TOKEN_SECRET, LLDAP_* und SMTP_* an.
Fuer OIDC muessen zusaetzlich OIDC_ISSUER, OIDC_COOKIE_SECRET, OIDC_ADMIN_GROUP und OIDC_ADMIN_GROUP_UUID gesetzt werden.
Single Container Image
Das Root-Dockerfile baut API und Angular in ein einzelnes Image. Der Container startet:
- Nginx Web-UI und Reverse Proxy auf Port
8080 - NestJS API / IdP nur intern auf Port
3000
Build und Push:
docker build -t registry.example.com/ldap-portal/idp:latest .
docker push registry.example.com/ldap-portal/idp:latest
Start:
docker run -d --name ldap-portal-idp \
--env-file .env \
-p 8080:8080 \
registry.example.com/ldap-portal/idp:latest
Standardmaessig bleibt API_BASE_URL leer. Das Frontend nutzt dadurch relative URLs und Nginx routet API-/OIDC-Pfade intern zur NestJS-API. Setze API_BASE_URL nur, wenn das Frontend bewusst eine andere API-Origin verwenden soll.
Externe Dienste
Die Anwendung bringt keine Datenbank und keinen LLDAP-Server mehr per Compose mit. Erwartet werden:
- eine externe MySQL-Datenbank, z. B.
mysql://ldap_portal:secret@mysql.example.com:3306/ldap_portal - ein externer LLDAP-HTTP-Endpunkt fuer GraphQL, z. B.
https://lldap.example.com - ein externer LDAP-Endpunkt fuer Bind/Login, z. B.
ldap://lldap.example.com:3890
Setze DATABASE_SSL=true, wenn der MySQL-Server TLS verlangt. In NODE_ENV=production sollte synchronize nicht genutzt werden; fuer produktive Deployments sollten TypeORM-Migrationen ergaenzt werden.
LLDAP-Hinweis
Die API nutzt LDAP-Bind fuer die Passwortpruefung und GraphQL fuer administrative User-Operationen. Falls sich die GraphQL-Mutationsnamen zwischen LLDAP-Versionen unterscheiden, muessen die Queries in apps/api/src/lldap/lldap.service.ts an die Zielversion angepasst werden.
OpenID Connect
Die API stellt einen OIDC Provider bereit. Die wichtigsten Endpunkte:
- Discovery:
/.well-known/openid-configuration - Authorization:
/oidc/auth - Token:
/oidc/token - UserInfo:
/oidc/me - JWKS:
/oidc/jwks - Logout:
/oidc/session/end - Revocation:
/oidc/token/revocation - Introspection:
/oidc/token/introspection
OIDC-Clients werden im Frontend unter /admin/oidc-clients verwaltet. Zugriff erhaelt nur ein eingeloggter Nutzer, der in der LLDAP-Gruppe client_manager ist. Standardmaessig wird zusaetzlich die Gruppen-UUID 89aa3d8d-fcbd-3ec9-b99d-901a0cfc405e akzeptiert. Client Secrets werden nur direkt nach Erstellung angezeigt.
V1 unterstuetzt Authorization Code Flow mit verpflichtendem PKCE. Dynamic Client Registration und SAML sind nicht aktiviert.
Admin-Rollen
Admin-Berechtigungen werden ueber LLDAP-Gruppen gesteuert:
client_manager: OIDC-Clients verwalten.registration_manager: Registrierungen freigeben oder ablehnen.user_manager: Nutzer anzeigen, bearbeiten, loeschen und Gruppenmitgliedschaften aendern.group_manager: Gruppen anzeigen, erstellen, bearbeiten und loeschen.audit_viewer: Audit-Events anzeigen.
Die Registrierung laeuft in zwei Schritten: Nutzer bestaetigen zuerst ihre E-Mail-Adresse, danach muss ein registration_manager die Registrierung freigeben. Erst bei der Freigabe wird der LLDAP-User erstellt.