# 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 ```bash cp .env.example .env npm install npm run start:api npm run start:web ``` Die API laeuft standardmaessig auf `http://localhost:3000`, das Frontend auf `http://localhost:4200`. ## Docker Compose ```bash 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: - NestJS API / IdP auf Port `3000` - Nginx Web-UI auf Port `8080` Build und Push: ```bash docker build -t registry.example.com/ldap-portal/idp:latest . docker push registry.example.com/ldap-portal/idp:latest ``` Start: ```bash docker run -d --name ldap-portal-idp \ --env-file .env \ -e API_BASE_URL=https://id.example.com \ -p 3000:3000 \ -p 8080:8080 \ registry.example.com/ldap-portal/idp:latest ``` `API_BASE_URL` wird beim Containerstart in `/config.js` geschrieben und vom Angular-Frontend gelesen. Setze es auf die aus Browser-Sicht erreichbare API-/IdP-URL. ## 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.