Rechtssicher signieren — mandantenfähig, in der eigenen Cloud.

Überblick

Die Plattform ist ein Software-as-a-Service für elektronische Signaturen: Jede Organisation ist ein eigener Mandant mit strikt getrennten Daten. Nutzer laden ein PDF hoch, legen einen Vorgang mit einem oder mehreren Beteiligten an, platzieren die sichtbaren Signaturfelder und versenden Einladungen. Unterzeichner öffnen einen sicheren Einmal-Link, zeichnen im Browser (auch am Handy, mit Finger oder Stift) und die Plattform erzeugt die PAdES-Signatur.

• Fünf Signaturarten — vom serverseitigen Selbstsignieren bis zur qualifizierten QES.
• Workflow — sequenziell oder parallel, mit Freigeber-Rollen (genehmigen/ablehnen).
• Sichtbare Signaturen — beliebig platzierbar, mehrere Felder je Person, biometrische Erfassung (X/Y/Druck/Zeit).
• Mandantenfähig — Organisationen, Rollen, eigene Signaturzertifikate und Identitätsanbindung je Org.
• Nachvollziehbar — lückenloser Audit-Trail, Prüfbericht je signiertem Dokument.

Rollen & Zugang

Wer was sieht und darf, hängt an der Rolle. Externe Unterzeichner brauchen keinen Account.

Die Oberfläche

Das Portal hat fünf Ansichten. Auf jeder Seite erklärt der ?-Button oben (neben der Sprachauswahl) die Abschnitte der aktuellen Ansicht kontextbezogen.

Dashboard

• Vorgang anlegen — Titel, PDF hochladen, Ablauf (sequenziell/parallel), optionale Nachricht.
• Teilnehmer — E-Mail, Signaturart/-umgebung, Rolle und optional die E-Mail-Sprache je Person; über 📍 die sichtbaren Felder im PDF platzieren.
• Vorgangsliste — laufende Vorgänge mit Status, Klick öffnet die Detailseite.

Vorgangs-Details

• Fortschritt — Statusbalken und wie viele Beteiligte schon signiert/freigegeben haben.
• Dokumente — signiertes PDF ansehen, prüfen (🔎 erzeugt einen Prüfbericht), herunterladen oder per E-Mail senden.
• Teilnehmer — wer signiert, in welcher Reihenfolge, mit Status.
• Senden — erzeugt und verschickt die Magic-Links.
• Audit-Trail — lückenloses Protokoll (standardmäßig eingeklappt).

Administration & Plattform-Konsole

Diese beiden Ansichten haben eigene Abschnitte — siehe Administration und Plattform-Konsole.

Unterzeichnen

Die Seite, die ein Empfänger per Einladungslink öffnet — siehe Unterzeichnen.

Signaturarten

Jeder Teilnehmer bekommt eine Signaturart zugewiesen. Verfügbar sind im Dropdown nur die vom Admin eingerichteten Signaturumgebungen. Alle Verfahren erzeugen PAdES über Syncfusion PDF + BouncyCastle (handgeschriebenes CMS).

Vorgang anlegen

1. PDF hochladen und dem Vorgang einen Titel geben.
2. Ablauf wählen — Sequenziell (nacheinander, Reihenfolge erzwungen) oder Parallel (alle gleichzeitig).
3. Teilnehmer hinzufügen — E-Mail, Signaturart/-umgebung und Rolle (Unterzeichner, Freigeber, Betrachter).
4. Signaturfelder platzieren — über 📍 pro Person ein oder mehrere Felder im PDF setzen (Seite, Position, Größe). Ohne Platzierung wird unsichtbar signiert.
5. Optional: Sprache & Nachricht — E-Mail-Sprache je Empfänger, freie Nachricht an alle.
6. Senden — die Einladungen (Magic-Links) gehen raus; im Sequenzmodus zunächst nur an den Ersten.

Unterzeichnen

Der Empfänger öffnet den Einladungslink — kein Konto nötig. Die Seite funktioniert am Desktop wie am Handy-Browser.

• Dokument — das PDF durchscrollen; die eigenen Signaturfelder sind markiert.
• Signieren — Feld antippen, mit Finger oder Stift zeichnen, „Fertig". Bei mehreren Feldern führt „Zur nächsten Signatur" zum nächsten offenen Feld.
• Biometrie — bei den serverseitig erzeugten Signaturen werden X/Y/Druck/Zeit erfasst, verschlüsselt und als CMS-Attribut eingebettet.
• Freigeben/Ablehnen — Freigeber genehmigen oder lehnen mit Begründung ab; Ablehnung beendet den Vorgang.

Administration

Die Einstellungen der eigenen Organisation. Alle Abschnitte sind ein-/ausklappbar; ungenutzte starten eingeklappt.

Benutzer

Benutzer anlegen, Rolle (Mitglied/Org-Admin) ändern, deaktivieren. Bei lokalen Konten lässt sich das Passwort zurücksetzen (🔑) — bei SSO/LDAP-Konten nicht, da diese am Identitätsanbieter authentifizieren.

Signaturumgebungen

Eine Signaturumgebung ist eine benannte, gespeicherte Konfiguration für genau eine Signaturart (Zertifikate und Zugangsdaten, verschlüsselt). Der zentrale Punkt: Eine Methode erscheint im Teilnehmer-Dropdown erst, wenn du dafür eine Umgebung angelegt hast. Du kannst mehrere anlegen — z.B. zwei Organisationszertifikate — und unterscheidest sie über den Namen.

Single Sign-on mit OIDC — „Mitarbeiter mit dem Firmenkonto anmelden lassen“

Noch nie damit zu tun gehabt? SSO bedeutet, dass sich dein Team mit dem bereits vorhandenen Konto anmeldet — Microsoft 365, Google Workspace, Okta, Keycloak — statt mit einem eigenen miPDFsign-Passwort. Im Hintergrund spricht miPDFsign mit diesem System (dem Identitätsanbieter, kurz IdP) über das Standardprotokoll OpenID Connect. Einmal pro Organisation einrichten: miPDFsign als „Anwendung“ im IdP registrieren, ein paar Werte übernehmen und dem IdP eine Rücksprung-Adresse nennen.

1. Was du vom IdP (bzw. der IT-/Identity-Abteilung) brauchst:

2. Der eine Wert, den du dem IdP gibst — die Redirect-URI (Callback / Reply-URL). Exakt angeben (echte Domain, https, kein Schrägstrich am Ende):

https://DEINE-DOMAIN/api/auth/oidc/callback

3. App registrieren (Beispiel: Microsoft Entra ID / Azure AD):

1. Entra Admin Center → App-Registrierungen → Neue Registrierung.
2. Redirect-URI: Plattform Web, Wert = obige Callback-URL.
3. Anwendungs-(Client-)ID kopieren → deine Client-ID.
4. Zertifikate & Geheimnisse → Neues Clientgeheimnis → den Wert sofort kopieren → dein Client-Secret.
5. Tokenkonfiguration → Gruppenanspruch hinzufügen; Name/Objekt-ID der Admin-Gruppe notieren.
6. Authority = https://login.microsoftonline.com/<tenant-id>/v2.0.

Okta, Google und Keycloak folgen demselben Muster.

4. In miPDFsign eintragen (Administration → Single Sign-on): Aktiviert einschalten; Authority, Client-ID, Client-Secret einfügen; Scopes = openid profile email belassen; Groups-Claim = groups belassen; Admin-Gruppe setzen; Speichern.

5. Wie sich dein Team anmeldet: Mit SSO anmelden für deine Organisation wählen. Der erste Login legt das Konto automatisch an (Just-in-time) — kein lokales Passwort. Die Rolle wird bei jedem Login aus dem Groups-Claim gesetzt.

LDAP / Active Directory — „Mitarbeiter mit dem Windows-/AD-Konto anmelden lassen“

Noch nie damit zu tun gehabt? Betreibt deine Organisation ein lokales Verzeichnis — Microsoft Active Directory oder einen anderen LDAP-Server — kann miPDFsign Benutzernamen und Passwörter direkt dagegen prüfen. Sinnvoll ohne Cloud-IdP. In einem Satz: miPDFsign verbindet sich mit einem schreibgeschützten Dienstkonto, sucht die Person anhand des eingegebenen Benutzernamens und meldet sich dann als diese Person mit ihrem Passwort an; klappt das, ist sie drin.

Was du von der IT-/Verzeichnis-Abteilung brauchst:

Konfigurieren (Administration → LDAP / Active Directory): Aktiviert; Host + Port; LDAPS oder StartTLS ankreuzen; Basis-DN; Bind-DN + Passwort; Nutzer-Filter belassen ((sAMAccountName={0}) für AD); Attribut-Standards belassen; Admin-Gruppe setzen; Speichern.

Vor dem Ausrollen testen: „Verzeichnis-Login testen“ mit Benutzername und Passwort eines echten Nutzers führt die komplette Suche-dann-Anmeldung aus und zeigt E-Mail, Name und ob der Nutzer Admin wäre — ohne ein Konto anzulegen. Konfiguration anpassen, bis der Test grün ist.

Wie sich dein Team anmeldet: Verzeichnis-Nutzer geben Benutzername, Passwort und die Organisation (deren Slug) ein — nötig, weil Benutzernamen über Mandanten nicht eindeutig sind. Der erste Login legt das Konto an (Just-in-time); die Rolle wird jedes Mal aus dem Gruppen-Attribut abgeleitet.

Biometrie-Zertifikat

Erfasste biometrische Signaturdaten (X/Y/Druck/Zeit) werden hybrid mit einem öffentlichen Zertifikat verschlüsselt; nur wer den passenden privaten Schlüssel hat, kann sie später entschlüsseln — genau das ermöglicht die Analyse durch einen Schriftsachverständigen im Beweisverfahren. Du musst dafür nichts einrichten:

• Standardmäßig automatisch erzeugt — legst du kein eigenes an, erstellt miPDFsign Cloud automatisch ein Schlüsselpaar (CN {Orgname}_miPDFsign_cloud_biometrics). Biometrie funktioniert ab dem ersten Tag.
• Privaten Schlüssel herunterladen — beim erzeugten Zertifikat lädst du den privaten Schlüssel herunter und verwahrst ihn sicher offline; du brauchst ihn, um Biometriedaten später zu lesen. Optional vergibst du ein Passwort, das die Datei schützt (verschlüsseltes PKCS#8).
• Eigenes verwenden — lade dein eigenes Zertifikat hoch. Das ersetzt das erzeugte und löscht den privaten Schlüssel vom Server — ab dann hast nur du ihn.
• Neu erzeugen — ein frisches Schlüsselpaar anlegen; bereits mit dem alten Zertifikat verschlüsselte Daten brauchen dann den alten privaten Schlüssel.

Branding (Enterprise)

Unter Administration → Branding hinterlegen Enterprise-Organisationen (und Testphasen, zum Ausprobieren) Anzeigename, Akzentfarbe und Logo (PNG/JPEG bis 512 KB): Externe Unterzeichner sehen sie auf der Signierseite, der Anzeigename erscheint zusätzlich in den E-Mails zum Vorgang. Standard-Tarife behalten gespeicherte Werte, gerendert oder editierbar sind sie dort nicht.

Zeitstempel · Plugins · Audit-Trail

• Zeitstempel (TSA) — optionaler eigener RFC-3161-Dienst, den alle Signaturen nutzen.
• Plugins — ausgehende Zustellung (z.B. Webhook), die bei Abschluss das signierte Dokument liefert.
• Audit-Trail — org-weites Ereignisprotokoll.

Plattform-Konsole

Die mandantenübergreifende Betreiber-Konsole (/platform, nur für Plattform-Admins). Alles in einer Hand — kein separates Tooling nötig. Vier Registerkarten:

Anmeldung & API

Zwei Wege, nach der Anmeldeform automatisch erkannt:

• JWT (Portal) — POST /api/auth/login mit E-Mail/Benutzername + Passwort und optional dem Organisations-Slug (nötig für Verzeichnis-Login). Lokale Passwörter sind PBKDF2-HMAC-SHA256.
• API-Key (Maschine) — der mpk_…-Schlüssel aus der Registrierung, gesendet als X-Api-Key oder Authorization: Bearer mpk_…. Schlüssel werden nur gehasht gespeichert.

Die vollständige OpenAPI-Referenz für Integratoren liegt unter /api/docs (JSON unter /api/openapi/v1.json) mit beiden Sicherheits-Schemata.

# Trial anlegen → liefert einen API-Key
curl -X POST https://DEINE-DOMAIN/api/trial/signup \
  -H "Content-Type: application/json" \
  -d '{"organizationName":"Acme","adminEmail":"a@acme.com","password":"…"}'

# Dokument hochladen (mit API-Key)
curl -X POST https://DEINE-DOMAIN/api/documents \
  -H "X-Api-Key: mpk_…" -F "file=@vertrag.pdf;type=application/pdf"

Sicherheit & Datenschutz

• Mandantentrennung — jede Datenzeile trägt eine Org-ID; EF-Core-Query-Filter erzwingen die Isolation datenbankseitig (kein mandantenübergreifender Lesezugriff by design).
• Magic-Links — 256-bit-CSPRNG-Token; gespeichert wird nur der SHA-256-Hash. Ein Link ist nicht aus dem Hash rekonstruierbar.
• Secrets verschlüsselt — Zertifikatspasswörter, Client-Secrets und Biometriedaten liegen Data-Protection-verschlüsselt; der Schlüsselring liegt persistent in Redis (überlebt Neustarts).
• Zwei-Faktor-Authentifizierung — jedes Passwort-Konto kann auf der 🔒 Sicherheit-Seite TOTP-2FA aktivieren (QR-Enrolment, 8 einmalige Wiederherstellungscodes). Der Login verlangt dann nach dem Passwort einen 6-stelligen Code; SSO/LDAP/Google-Konten bringen die MFA ihres Identity-Providers mit.
• Rate-Limiting — Login und Trial-Registrierung sind pro IP begrenzt (429 mit Retry-After).
• Härtung — nur der Reverse-Proxy ist von außen erreichbar; HSTS + Security-Header; E-Mail mit SPF/DKIM/DMARC (p=quarantine).

Deployment

Drei Wege — vom lokalen Start bis zum Anbieter-Deployment. Zustand liegt extern in PostgreSQL / Redis / S3-kompatiblem Objektspeicher; die API- und Worker-Tiers sind zustandslos.

Lokal (Entwicklung)

docker compose up -d --build
# API :8090 · Web :3100 · MinIO :9001 · Mailpit :8025 · Jaeger :16686

Portabel (eigener Server / VPS)

Ein selbstständiger Stack, der die Images aus der Registry zieht und einen eigenen Caddy mit automatischem Let's-Encrypt-Zertifikat mitbringt — env-gesteuert über die Domain:

docker compose --env-file .env.production \
  -f docker-compose.deploy.yml pull
docker compose --env-file .env.production \
  -f docker-compose.deploy.yml up -d

Das Web-Image ruft dieselbe Origin auf, von der es ausgeliefert wird — ein Image passt für jede Domain, Staging und Prod unterscheiden sich nur in der Env-Datei.

Kubernetes

Ein Helm-Chart (deploy/helm/mipdfsign) mit Deployments für API/Worker/Web, Services, Ingress und HPA (horizontale Autoskalierung). PostgreSQL/Redis/S3 als externe Dienste.