Sign with confidence — multi-tenant, in your own cloud.

Overview

The platform is software-as-a-service for electronic signatures: every organization is its own tenant with strictly separated data. Users upload a PDF, build a flow with one or more participants, place the visible signature fields, and send invitations. Signers open a secure one-time link, draw in the browser (on a phone too, with finger or stylus), and the platform produces the PAdES signature.

• Five signing methods — from server-side self-signing to a qualified QES.
• Workflow — sequential or parallel, with approver roles (approve/reject).
• Visible signatures — freely placed, multiple fields per person, biometric capture (X/Y/pressure/time).
• Multi-tenant — organizations, roles, own signing certificates and identity connection per org.
• Auditable — a complete audit trail and a verification report per signed document.

Roles & access

What each person sees and may do depends on their role. External signers need no account.

The interface

The portal has five views. On every page the ? button at the top (next to the language selector) explains the sections of the current view in context.

Dashboard

• Create a flow — title, upload a PDF, order (sequential/parallel), optional message.
• Participants — email, signing method/environment, role and optionally the email language per person; use 📍 to place the visible fields on the PDF.
• Flow list — running flows with status; click one to open its detail page.

Flow details

• Progress — status bar and how many participants have signed/approved.
• Documents — view, verify (🔎 produces a verification report), download or email the signed PDF.
• Participants — who signs, in what order, with status.
• Send — generates and sends the magic links.
• Audit trail — complete event log (collapsed by default).

Administration & platform console

These two views have their own sections — see Administration and Platform console.

Signing

The page a recipient opens from an invitation link — see Signing.

Signing methods

Each participant is assigned a signing method. Only the signing environments the admin configured appear in the dropdown. Every method produces PAdES via Syncfusion PDF + BouncyCastle (hand-written CMS).

Create a flow

1. Upload a PDF and give the flow a title.
2. Choose the order — Sequential (one after another, order enforced) or Parallel (all at once).
3. Add participants — email, signing method/environment and role (Signer, Approver, Viewer).
4. Place signature fields — via 📍 set one or more fields per person on the PDF (page, position, size). Without placement, signing is invisible.
5. Optional: language & message — email language per recipient, a free message to all.
6. Send — the invitations (magic links) go out; in sequential mode first only to the first signer.

Signing

The recipient opens the invitation link — no account needed. The page works on desktop and mobile browsers.

• Document — scroll through the PDF; your signature fields are marked.
• Sign — tap a field, draw with finger or stylus, “Done”. With multiple fields, “Go to next signature” jumps to the next open field.
• Biometrics — for the server-produced signatures, X/Y/pressure/time are captured, encrypted and embedded as a CMS attribute.
• Approve/Reject — approvers approve or reject with a reason; a rejection ends the flow.

Administration

Your organization’s settings. All sections are collapsible; unused ones start collapsed.

Users

Create users, change the role (Member/Org admin), deactivate. For local accounts you can reset the password (🔑) — not for SSO/LDAP accounts, which authenticate at their identity provider.

Signing environments

A signing environment is a named, saved configuration for one signing method (certificates and credentials, stored encrypted). The key idea: a method only appears in the flow's participant dropdown once you've created an environment for it. You can create several — e.g. two organization certificates — and tell them apart by name.

Single sign-on with OIDC — “let staff log in with their company account”

New to this? SSO means your team signs in with the account they already have — Microsoft 365, Google Workspace, Okta, Keycloak — instead of a separate miPDFsign password. Behind the scenes miPDFsign talks to that system (the identity provider, or IdP) using the standard OpenID Connect protocol. You set this up once per organization: register miPDFsign as an “application” in your IdP, take a few values from it, and give it one address to send people back to.

1. What you need from your IdP (or IT/identity team):

2. The one value you give the IdP — the Redirect URI (callback / reply URL). Give it exactly (real domain, https, no trailing slash):

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

3. Register the app (example: Microsoft Entra ID / Azure AD):

1. Entra admin center → App registrations → New registration.
2. Redirect URI: platform Web, value = the callback URL above.
3. Copy the Application (client) ID → your Client ID.
4. Certificates & secrets → New client secret → copy the Value now → your Client secret.
5. Token configuration → Add groups claim; note the group name/object ID for admins.
6. Authority = https://login.microsoftonline.com/<tenant-id>/v2.0.

Okta, Google and Keycloak follow the same shape.

4. Enter it in miPDFsign (Administration → Single sign-on): turn Enabled on; paste Authority, Client ID, Client secret; leave Scopes = openid profile email; leave Groups claim = groups; set Admin group; Save.

5. How your team logs in: they choose Sign in with SSO for your organization. The first login creates the account automatically (just-in-time) — no local password. The admin/member role is set from the groups claim on every login.

LDAP / Active Directory — “let staff log in with their Windows/AD account”

New to this? If your organization runs an on-prem directory — Microsoft Active Directory or another LDAP server — miPDFsign can check usernames and passwords directly against it. Use this when you have no cloud IdP. In one sentence: miPDFsign connects with a read-only service account, finds the person by the username they typed, then tries to log in as them with their password; if that succeeds, they're in.

What you need from your IT/directory team:

Configure it (Administration → LDAP / Active Directory): Enabled; Host + Port; tick LDAPS or StartTLS; Base DN; Bind DN + password; keep the User filter ((sAMAccountName={0}) for AD); keep the attribute defaults; set the Admin group; Save.

Test before rolling out: “Test directory login” with a real user's username and password runs the full search-then-log-in and shows the resolved email, name and whether they'd be an admin — without creating an account. Fix the config until the test is green.

How your team logs in: directory users enter username, password and the organization (its slug) — required because usernames aren't unique across tenants. The first login provisions the account (just-in-time); the role is derived from the group attribute each time.

Biometric certificate

Captured biometric signature data (X/Y/pressure/time) is hybrid-encrypted to a public certificate; only the holder of the matching private key can later decrypt it — that is what lets a handwriting expert analyse the signature in evidence proceedings. You don't have to set this up:

• Auto-generated by default — if you don't provide your own, miPDFsign Cloud creates a keypair for the organization automatically (CN {OrgName}_miPDFsign_cloud_biometrics). Biometric capture works from day one.
• Download the private key — for the generated certificate, download the private key and store it safely offline; you need it to read biometric data later. Optionally set a password to protect the file (encrypted PKCS#8).
• Use your own — upload your own certificate. This replaces the generated one and removes the private key from the server — from then on only you hold it.
• Regenerate — create a fresh keypair; data already encrypted to the old certificate then needs the old private key.

Branding (Enterprise)

Under Administration → Branding, Enterprise organizations (and trials, for evaluation) set a display name, accent color and logo (PNG/JPEG up to 512 KB): external signers see them on the signing page, and the display name brands the flow emails. Standard plans keep stored values, but they are neither rendered nor editable.

Timestamp · Plugins · Audit trail

• Timestamp (TSA) — optional own RFC-3161 service used by all signatures.
• Plugins — outbound delivery (e.g. webhook) that pushes the signed document on completion.
• Audit trail — organization-wide event log.

Platform console

The cross-tenant operator console (/platform, platform admins only). Everything in one place — no separate tooling. Four tabs:

Authentication & API

Two schemes, detected automatically by credential shape:

• JWT (portal) — POST /api/auth/login with email/username + password and optionally the organization slug (required for directory login). Local passwords are PBKDF2-HMAC-SHA256.
• API key (machine) — the mpk_… key from signup, sent as X-Api-Key or Authorization: Bearer mpk_…. Keys are stored hashed only.

The full OpenAPI reference for integrators is at /api/docs (JSON at /api/openapi/v1.json) with both security schemes.

# Create a trial → returns an API key
curl -X POST https://YOUR-DOMAIN/api/trial/signup \
  -H "Content-Type: application/json" \
  -d '{"organizationName":"Acme","adminEmail":"a@acme.com","password":"…"}'

# Upload a document (with the API key)
curl -X POST https://YOUR-DOMAIN/api/documents \
  -H "X-Api-Key: mpk_…" -F "file=@contract.pdf;type=application/pdf"

Security & privacy

• Tenant isolation — every data row carries an org ID; EF Core query filters enforce isolation at the database layer (no cross-tenant reads by construction).
• Magic links — 256-bit CSPRNG tokens; only the SHA-256 hash is stored. A link cannot be reconstructed from the hash.
• Secrets encrypted — certificate passwords, client secrets and biometric data are Data-Protection-encrypted; the key ring lives durably in Redis (survives restarts).
• Two-factor authentication — every password account can enable TOTP 2FA on the 🔒 Security page (QR enrolment, 8 one-time recovery codes). Login then requires a 6-digit code after the password; SSO/LDAP/Google accounts carry their identity provider's MFA.
• Rate limiting — login and trial signup are throttled per IP (429 with Retry-After).
• Hardening — only the reverse proxy is reachable from outside; HSTS + security headers; email with SPF/DKIM/DMARC (p=quarantine).

Deployment

Three paths — from a local start to a provider deployment. State lives externally in PostgreSQL / Redis / S3-compatible object storage; the API and Worker tiers are stateless.

Local (development)

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

Portable (own server / VPS)

A self-contained stack that pulls the images from the registry and brings its own Caddy with automatic Let's Encrypt certificate — env-driven by the 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

The web image calls the same origin it is served from — one image fits any domain; staging and prod differ only in the env file.

Kubernetes

A Helm chart (deploy/helm/mipdfsign) with Deployments for API/Worker/Web, Services, Ingress and HPA (horizontal autoscaling). PostgreSQL/Redis/S3 as external services.