Vier Produkte von CodeB.

Was es ersetzt

Die Microsoft-Passwort-Provider-Kachel. CodeB liefert einen integrierten Credential Provider Filter mit aus; sobald die Richtlinie angewendet ist, verschwindet die Passwort-Kachel vollständig.

Herkunft

CP V2 ist kein Produkt der Version 1.0. Aloaha hat Aloaha Smartlogin mehr als zwei Jahrzehnte entwickelt und betreut — einer der am längsten laufenden Windows-Credential-Provider am Markt. Der Credential Provider V2 ist dessen vollständige Neuentwicklung in modernem Managed Code: dieselbe operative Erfahrung, moderne Architektur, ein Plugin-Modell, das neue Token-Typen einfach ergänzen lässt. Sie erwerben zwanzig Jahre Erfahrung mit Sonderfällen in einer aktuellen Codebasis.

FIPS 140-2 erzwingbar — und einzigartig

Weil der Credential Provider V2 in 100 % Managed .NET Code geschrieben ist, beachtet er die Standard-Group-Policy-Einstellung „Systemkryptografie: Konformität mit FIPS-Algorithmus für Verschlüsselung, Hashing und Signatur erzwingen“. Schalten Sie sie ein, und Windows selbst erzwingt FIPS 140-2 gegen jeden Krypto-Aufruf, den CodeB tätigt — keine zusätzliche Laufzeit, keine parallele Krypto-Bibliothek, kein „vertrauen Sie uns“. Jeder andere uns bekannte Windows-Credential-Provider ist in nativem Code geschrieben und kann auf diese Weise nicht erzwungen werden. Wenn Sie einen FIPS-konformen Anmelde-Pfad benötigen, ist CodeB der einzige Credential Provider, der ihn per einem einzigen GPO-Schalter liefert.

Zwei Editionen, ein Credential Provider

Wählen Sie diejenige, die am besten zu Ihrem Bereitstellungs-Modell passt. Beide Editionen setzen auf demselben Credential Provider auf — der Unterschied liegt darin, wie die unterstützenden Helfer paketiert sind.

Tipp für die Produktion: Das System-Tray-Symbol lässt sich vor Endanwendern verbergen, indem der Registry-Wert HKLM\SOFTWARE\WOW6432Node\CodeB\Config\HideSystray gesetzt wird. Der Helfer läuft weiter — einschließlich Aktionen beim Karten-Entfernen — aber normale Anwender sehen ihn nicht und können ihn nicht versehentlich verstellen.

Smartcard-Middleware-Linie. Der Interoperabilitäts-Kern des CP V2 geht zurück auf Arbeit, die mit dem WIPO Award for Innovative Enterprises bei den Malta Innovation Awards am 23. Februar 2012 ausgezeichnet wurde — unterzeichnet vom damaligen WIPO-Generaldirektor Francis Gurry. Zwei Jahrzehnte „welche Karten funktionieren im Feld?“, verdichtet zum heutigen Credential Provider.

Produkt-Updates-Kanal: CodeB Credential Provider auf WhatsApp — reiner Broadcast-Kanal für Release-Notes und Sicherheits-Hinweise. Kein Support-Kanal.

Admin-Werkzeuge für unbeaufsichtigte Rollouts

CodeB Admin CLI (CodeBAdminCLI.exe) ist ein separates Kommandozeilen-Werkzeug für Systemadministratoren. Es führt dieselben Enrollment-Aktionen aus wie die GUI-Helfer — eine NFC-Karte einem AD-Benutzer zuordnen, verschlüsselte Anmeldedaten speichern, lokale Soft-Tokens anlegen, Zuweisungen prüfen, eine Karte sperren — aber unbeaufsichtigt, aus jedem Batch-Skript, jeder PowerShell-Pipeline oder jedem SCCM-Task. 500 Karten von Hand auszurollen ist eine Woche; aus einer CSV in einer Schleife ein Nachmittag.

Verstandene Schalter

/add2fa	Eine Kartenseriennummer als zweiten Faktor für einen AD-Benutzer zuweisen. Entspricht LinkNFC2AD.exe in Skriptform.
/add2ad	Verschlüsselte Anmeldedaten in AD speichern („Store to AD“ aktiviert). Ersetzt den manuellen Ablauf von LinkNFCCard.exe.
/add2fs	Ein verschlüsseltes Soft-Token lokal anlegen statt in AD zu speichern.
/list2facards	Alle Kartenseriennummern auflisten, die einem bestimmten Benutzer zugewiesen sind.
/list2fa	Umgekehrte Suche — bei gegebener Kartenseriennummer den zugewiesenen Benutzer ermitteln.
/deletecard	Den Karten-Verweis sowohl aus den 2FA-Datensätzen als auch aus den Credential-Tokens entfernen.
/changepw	Passwort eines bestimmten AD-Benutzers ändern und das verschlüsselte Soft-Token in AD im selben Schritt aktualisieren. Für skriptgesteuerte Passwort-Rotation ohne die kartenbasierte Anmeldung zu brechen.

Parameter

/user	Verwalteter Benutzername.
/domain	Anmelde-Domäne, zu der der Benutzer gehört.
/password	Aktuelles Passwort des Benutzers — erforderlich mit /add2ad (zum Speichern der Anmeldedaten) oder mit /changepw (als das zu ersetzende alte Passwort).
/newpassword	Das neue Passwort des Benutzers — erforderlich mit /changepw.
/cardserial	Eindeutige Kennung (UID) der NFC-Karte.
/pin	PIN, die der Karte zur Anmelde-Verifikation zugewiesen wird.
/action	1 = Bildschirm bei Karten-Entfernung sperren, 2 = Benutzer abmelden.

Beispiel-Aufrufe

:: Eine Kartenseriennummer als zweiten Faktor zuweisen
CodeBAdminCLI.exe /add2fa /user stefan /domain CodeB /serial AAFFBBCC

:: Verschlüsselte Anmeldedaten in AD speichern
CodeBAdminCLI.exe /add2ad /user stefan /domain CodeB /password letmein /serial AAFFBBCC /pin 1234

:: Oder die verschlüsselten Anmeldedaten lokal als Soft-Token speichern
CodeBAdminCLI.exe /add2fs /user stefan /domain CodeB /password letmein /serial AAFFBBCC /pin 1234

:: Alle einem Benutzer zugewiesenen Karten auflisten
CodeBAdminCLI.exe /list2facards /user stefan /domain CodeB

:: Umgekehrte Suche: Wem gehört diese Karte?
CodeBAdminCLI.exe /list2fa /serial AAFFBBFF

:: Eine Karte sperren (entfernt 2FA + Credential-Token)
CodeBAdminCLI.exe /deletecard /serial AAFFBBFF /user stefan

:: AD-Passwort rotieren UND das gespeicherte Soft-Token in einem Aufruf aktualisieren
CodeBAdminCLI.exe /changepw /user testuser /domain codeb /password oldalibaba /newpassword newalibaba

Admin-Tipp: Die CLI schreibt in AD-Attribute und in den Credential-Speicher. Wenn Sie die passenden AD-Berechtigungen an das aufrufende Konto delegieren, sind keine lokalen Admin-Rechte notwendig — nützlich für SCCM-Tasks und unbeaufsichtigte Skripte.

Unterstützte Tokens

Sortiert nach Häufigkeit im Einsatz.

• NFC-Kontaktloskarten — die beliebteste Variante. MIFARE Classic, MIFARE DESFIRE EV1/EV2/EV3 und eine breite Auswahl kontaktloser Karten. Einsetzbar als zweiter Faktor oder als vollständiger Passwort-Ersatz.
• TOTP nach RFC 6238 — 30-Sekunden-Fenster, SHA-1 / SHA-256. Das zweithäufigste Token. Einsetzbar als zweiter Faktor oder als vollständiger Passwort-Ersatz.
• X.509 PKI-Smartcards — Gesundheitswesen, Verteidigung und unternehmensseitig ausgestellte Karten. Software-Zertifikate ebenfalls unterstützt. Seltener im Einsatz; eingesetzt, wo eine bestehende PKI-Infrastruktur bereits vorhanden ist.
• USB-Memory-Stick — eine schnelle Möglichkeit, das Produkt an einem Arbeitsplatz zu evaluieren, ohne neue Hardware zu beschaffen. Für Proof-of-Concept geeignet; für den produktiven Einsatz empfehlen wir NFC, TOTP oder PKI.

Wo es läuft

Betriebssysteme	Windows 8, 8.1, 10, 11 · Windows Server 2012 R2 → 2025 (x86 + x64)
Konto-Modell	Lokal · Active Directory · Microsoft Entra ID · Hybrid
Verteilung	Kommandozeilen-Installer · ausrollbar per Group Policy oder beliebigem Registry-gesteuerten Konfigurationswerkzeug · MSI auf Anfrage
Architektur	Aufbauend auf ICredentialProviderCredential2 mit integriertem Credential Provider Filter; eigene Plugin-Bibliothek unterstützt.
FIPS 140-2	Per Windows Group Policy erzwingbar (Managed-Code-Architektur beachtet „FIPS-konforme Algorithmen verwenden“). Native-Code-Mitbewerber lassen sich auf diese Weise nicht erzwingen.
Souveränität	Keine Cloud erforderlich · EU-betrieben. Ausschließlich On-Premises · keine SaaS-Steuerebene · keine Cloud- oder Internetverbindung zum Betrieb · Air-Gap-fähig · betrieben von einer EU-Gesellschaft (Aloaha Limited, Malta) und konzipiert für Organisationen, die eine europäisch betriebene, selbst gehostete Identitäts-Infrastruktur ohne Abhängigkeit von US-Cloud-Plattformen suchen

Office-Author-Tagging auf Sammelkonten Neu

In Fertigung, Laboren, Klinik und anderen Umgebungen mit hohem Anwender-Durchsatz arbeiten legitim mehrere Personen unter demselben Windows-Konto — ein Sammelkonto. Das hält den Betrieb am Laufen, bricht aber die Zuordnung innerhalb von Office: Jede Änderung, jeder Kommentar und jede aufgezeichnete Anpassung landet unter demselben geteilten Anwender. CP V2 schließt diese Lücke: Bei Anmeldung oder Entsperren hängt der Credential Provider die eindeutige NFC-Karten-ID in Klammern an den Office-Author-Namen.

username (EA35CF34)

Ab diesem Moment trägt jede Änderung, jeder Kommentar, jede Track-Change und jede Metadaten-Anpassung in Word, Excel oder PowerPoint genau die Karten-ID, die an der Workstation verwendet wurde — und dieselbe Karten-ID steht im Windows-Ereignisprotokoll. Audit-Teams korrelieren beides, und eine Handlung in einem Office-Dokument wird einer konkreten Person zuordenbar, auch wenn das Windows-Konto darunter geteilt ist.

• Compliance-bereit. Unterstützt Identity-Tracking nach ISO/IEC 27001 (A.9 Access Control) und NIS2-Zuordnungspflichten für essenzielle/wichtige Einrichtungen.
• Audit-sicher. Jede Handlung in Office-Dokumenten verweist auf ein eindeutiges Karten-Token; dasselbe Token erscheint im Windows-Ereignisprotokoll — durchgängige Korrelation.
• Null Aufwand für Anwender. Das Author-Profil wird bei Anmeldung und Entsperren automatisch aktualisiert. Operatoren machen nichts anders.
• Gebaut für Shared-PC-Umgebungen. Hält den Betrieb effizient, ohne Zuordnung auf Sammelkonten zu opfern.

Voraussetzungen: MIFARE- oder DESFIRE-NFC-Karten (via LinkNFCCard mit der Identität verknüpft), CodeB-Systemtray läuft an der Workstation, CP V2 mit aktuellem Update. Author-Tagging für USB, Zertifikate, TOTP und OIDC ist auf der Roadmap.

Was es ist

Ein WebRTC-Videokonferenzsystem auf Aloaha-betriebener Infrastruktur in der EU. Räume werden bei Bedarf erzeugt, per URL betreten und nach Beenden des Gesprächs abgebaut. Der gemeinsame Button Im Browser anrufen im Footer jeder Seite dieser Site ist derselbe Dienst — ein Klick öffnet einen Raum und läutet in unserem Büro.

Warum es das gibt

Dieselben regulierten Estates, die CodeB am Anmelde-Bildschirm brauchen, dürfen typischerweise keine Consumer-Video-Apps installieren. Leitstellen, Schwesternzimmer, Fertigungszellen und air-gapped Büros brauchen einen Ad-hoc-Weg, eine externe Fachkraft auf den Bildschirm zu holen, ohne für sie einen Microsoft-365-Tenant zu betreiben. Ein Browser-Tab und eine URL sind der kleinstmögliche Fußabdruck.

Grundlagen des Meetings

• Browser-natives HD-Video und -Audio. 1280×720 nativ, pro Track Echounterdrückung, Rauschunterdrückung und AGC ab Werk. Reines WebRTC in jedem modernen Chromium-Browser, Firefox oder Safari. Keine Installation, keine Erweiterung, keine Admin-Rechte.
• Mesh-Topologie. Bis zu rund sechs Teilnehmer pro Anruf, Vollmesh. Jeder Browser sendet direkt an jeden anderen — kein Medienserver im Datenpfad. Für ein 30-Personen-All-hands ungeeignet; für ein hoheitliches Kleinteam-Meeting, das der Server nicht entschlüsseln kann, perfekt.
• Bildschirmfreigabe. Voller Desktop, einzelnes Fenster oder einzelner Browser-Tab. Setzt den Sharer automatisch ins Rampenlicht und kehrt nach Beenden zur Kamera zurück.
• Spotlight, PiP und Document PiP. Klick zum Vergrößern eines beliebigen Tiles. Standard-Picture-in-Picture für ein einzelnes Video; auf Chrome 116+ macht Document PiP die gesamte Meeting-Oberfläche — Grid, Chat, Bedienelemente — zu einem schwebenden, anpassbaren Fenster.
• Vorder-/Rückkamera-Wechsel auf Mobile. Ein Tipp wechselt zwischen Selfie- und Rückkamera auf iOS und Android. Andere Teilnehmer sehen die Änderung nahtlos.
• Wegwerf-Räume. Einladung per URL. Keine Konten anlegen, kein Verzeichnis pflegen, standardmäßig kein Chat-Verlauf gespeichert.

Echtzeit-Zusammenarbeit

Jede Kollaborationsfunktion läuft über dieselben WebRTC-Datenkanäle wie die Medien — Ende-zu-Ende verschlüsselt, nie über einen Server geleitet.

• Meeting-Chat. Markdown-sicherer Text, farbige Marker pro Autor, Ungelesen-Badge. Seitenpanel am Desktop, Vollbild am Handy. Verschlüsselt neben Audio und Video.
• P2P-Dateitransfer bis 1 GB. Datei in den Chat ziehen; in Chunks über den Datenkanal mit Live-Fortschrittsbalken. Die Datei berührt nie einen Server; der Empfänger lädt sie direkt vom Browser des Senders.
• Remote-Pointer. Bewegen Sie den Cursor über ein Tile und alle anderen sehen einen beschrifteten Pfeil am gleichen Punkt. Klick löst einen Ripple aus. Touch unterstützt. Tile-lokal; keine Input-Injektion.
• Klebezettel auf der Bildschirmfreigabe. Doppelklick im Sticky-Modus setzt einen farbigen Zettel an dieser Stelle. Editierbar, mit Autor und Zeitstempel versehen, über alle Peers synchronisiert.
• Gemeinsames Whiteboard. Vollbild-Canvas-Overlay, auf dem alle malen können — Stift, Radierer, fünf Farben, Rückgängig, Löschen. Striche über denselben Datenkanal synchronisiert; kein zusätzlicher Server-Endpunkt.
• Reaktionen und Handzeichen. Sechs Emoji-Reaktionen steigen über dem Tile des Senders auf und verschwinden. Handzeichen setzt ein wedelndes Badge mit Auto-Ankündigung im Chat.
• Breakout-Räume. Der Host teilt den Raum in zwei bis vier Gruppen für zwei bis dreißig Minuten auf. Jeder Peer verbindet sich zu seinem Sub-Raum; per Klick zwischen Gruppen wechseln oder zum Hauptraum zurück. Spätankunften wählen aus einer Live-Liste.

Datenschutz und On-Premises-Haltung

• Ende-zu-Ende DTLS-SRTP-Medien. Medienschlüssel werden Peer-to-Peer beim Anrufaufbau ausgehandelt. Der Server kann nicht entschlüsseln; selbst ein TURN-Relay sieht nur Chiffretext.
• Sperrbare Räume mit Anklopfen. Raum sperren, neue Joiner landen in einer Warteschlange. Bestehende Teilnehmer lassen herein oder lehnen ab. Fremde erreichen den Anruf nie ohne explizite Zustimmung.
• Forensisch tragfähige signierte Aufzeichnungen. Jede Aufzeichnung kommt mit einer Sidecar-JSON: SHA-256 der Datei, ECDSA-P256-Signatur, Teilnehmerliste, Sprecher-Wechsel-Timeline. Manipulationsfest; vor Gericht verwertbar.
• Aufzeichnung pro Teilnehmer einwilligungspflichtig. Bei Klick auf Aufzeichnen bekommt jeder andere Peer eine Erlauben-/Ablehnen-Aufforderung. Die Aufnahme startet erst, wenn alle zustimmen. Jede Entscheidung wandert ins ECDSA-signierte Sidecar — kryptografischer Beweis, wer wann zugestimmt hat.
• Lokale Aufzeichnung, keine Cloud. Die Aufzeichnung ist ein Komposit-Canvas aller Tiles plus AudioContext-gemischter Ton, direkt als WebM (VP9 + Opus) auf den Rechner des Aufzeichners geschrieben. Nichts wird irgendwohin hochgeladen.
• Verified-by-CodeB-Badge. Teilnehmer, die von einer Arbeitsstation mit Credential Provider V2 beitreten, zeigen ein bernsteinfarbenes Schild neben ihrem Namen im Meeting. Sichtbare Identitätsbestätigung — internes Personal ist von externen Gästen unterscheidbar, ohne das Meeting zu schließen.
• Zeitlich begrenzte TURN-Credentials. Wenn das Relay zum Einsatz kommt, werden Credentials pro Session erzeugt und laufen automatisch nach einer Stunde ab. Im Quelltext steht kein statisches Passwort, das ein Angreifer abgreifen könnte.
• Null Analytics, null Telemetrie. Keine Nutzungs-Pings, keine Drittanbieter-Analyse, kein Error-Reporting-SaaS. Das IIS-Zugriffslog ist das einzige Protokoll, wer verbunden war, und es bleibt auf Ihrem Server.

Politur und Zuverlässigkeit

• Bandbreitenadaptive Leiter. Ausgehendes Video stuft sich pro Empfänger durch 720p → 480p → 360p → Audio-Only herunter, wie es die Verbindung erlaubt. Jeder Peer bekommt die beste Stufe, die seine Leitung trägt — die langsamste Person zieht nicht alle anderen mit nach unten.
• Route- und Qualitätsbadge. Jedes Remote-Tile trägt einen kleinen Chip — LAN · 1080p, P2P · 720p oder Relayed · 480p — damit Sie auf einen Blick sehen, ob die Verbindung wirklich Peer-to-Peer ist (oder eben nicht).
• Verbindungsqualität pro Tile. Signalbalken pro Teilnehmer zeigen Round-Trip-Time, Paketverlust und Bitrate. Farbcodiert, damit Sie einen strauchelnden Peer sofort sehen.
• Auto-Reconnect. Wenn das Netz wackelt, erholt sich der Anruf selbst mit einem kurzen Verbinde…-Banner. Peer-Verbindungen werden neu aufgebaut; das Meeting läuft weiter, ohne dass jemand neu beitreten muss.
• Audio-Aufzug-Bremse. Plötzliche Pegelspitzen auf einem Remote-Stream werden automatisch gemildert; das Tile des Sprechers bekommt ein dezentes Warnbadge, damit niemandem die Ohren wegfliegen.
• Lautstärkeregler pro Tile. Hover über ein Remote-Tile zeigt einen kleinen vertikalen Slider oben rechts. Unabhängige Lautstärke pro Teilnehmer, 0–200 %. Lokal in Ihrem Tab, ändert nichts für andere.
• Hintergrund-Unschärfe. On-Device-Segmentierung: Sie bleiben scharf, Ihr Hintergrund wird weich. Läuft komplett im Browser; kein Bild verlässt Ihren Rechner zur Verarbeitung.
• Idle-Kamera-Abdunkelung. Verliert Ihr Tab den Fokus, dreht das ausgehende Video die Bitrate runter; es kommt sofort in voller Qualität zurück, sobald Sie wieder reinklicken. Spart allen Bandbreite ohne manuelles Stummschalten.
• Geräte und Name während des Anrufs ändern. Mikrofon, Kamera oder Anzeigename ohne Abbruch wechseln. Peers sehen eine Systemnachricht und das aktualisierte Tile-Label.
• Tastatur-Kürzel. M stumm · V Kamera · S teilen · C Chat · E Spotlight · H Hand · P PiP · Leertaste Push-to-talk.
• QR-Code-Beitritt. Die Landeseite erzeugt live einen QR-Code für die Raum-URL, während Sie tippen — im Browser, ohne Drittanbieter, voll offline-tauglich.
• Persistente Einstellungen, lokal. Name, Gerätewahl, Spiegelung, Push-to-talk, Auto-Spotlight, Pointer, Blur, Stumm-beitreten, Kamera-aus-beitreten — alle über Sessions hinweg gemerkt. Lokal gespeichert; nie an einen Server geschickt.

Click-to-Call und PSTN-Bridge

Ein selbst-gehostetes WebRTC ↔ SIP-Gateway macht aus einem Meeting-Raum ein anrufbares Ziel — oder aus einer Telefonnummer einen Meeting-Teilnehmer. Telefone sind erstklassige Teilnehmer, nicht angeflanschte Beigaben.

• Ein-Klick-Anruf von jeder Webseite. Den codebCallUs()-Launcher auf Kontaktformular, Support-Seite oder E-Mail-Signatur setzen. Der Besucher landet in einem frischen Meeting-Raum, die Bridge ruft das Telefon Ihres Teams an, und Besucher und Telefon teilen einen privaten Raum. Keine Installationen, keine Plug-ins, keine Drittanbieter-Weiterleitung.
• Unerratbare Alias-Wählnummern. Jedes anrufbare Ziel hat einen unerratbaren 64-Bit-Alias wie n_dbbe66524a5cd792. Öffentliche URLs und Embeds referenzieren den Alias, nie die echte Nummer — sie taucht weder im Seiten-Quelltext noch in Signaturen noch in Druckmaterial auf.
• Bring-your-own SIP-Trunk. Funktioniert mit jeder standardkonformen SIP-TK-Anlage oder jedem Trunk-Anbieter — FreePBX, Asterisk, FRITZ!Box, Yeastar, gehostete ITSPs und viele weitere. Credentials liegen in der lokalen Bridge-Konfiguration; nichts läuft über einen Drittanbieter-Vermittler. Ihre Verbindungsdaten gehören Ihrem Trunk-Anbieter.
• Multi-Trunk mit Priorität und Failover. Mehrere Trunks definieren, jeder mit einer Priorität. Ein Wählvorgang nutzt den Trunk mit der höchsten Priorität, der freie Kapazität hat; ist er belegt oder nicht erreichbar, schaltet die Bridge transparent auf den nächsten um. Per-Trunk-Kapazitätslimits erlauben es, einzeilige Residential-Trunks mit hochdichten SIP-Anbietern zu mischen.
• Routing-Regeln pro Nummer. Regeln wie „Nebenstelle 610 immer über die Büro-TK“ oder „alles in +356 über den Malta-Trunk“. Wildcards und E.164-Präfixe werden beide unterstützt — nützlich, wenn Ziele aus Compliance- oder Kostengründen unterschiedliche Carrier-Wege brauchen.
• Wählpräfix pro Trunk. Jeder Trunk hat ein optionales Wählpräfix (z. B. *31# bei europäischen Carriern), das automatisch vor E.164-Ziele gesetzt wird. Für Per-Call-Rufnummern-Unterdrückung, Premium-Route-Opt-out-Codes oder jedes carrier-spezifische Dial-Signal. Interne Nebenstellen bekommen nie ein Präfix.
• Ausgehende Rufnummer pro Trunk (PAI / RPID). Jeder Trunk sendet einen konfigurierbaren P-Asserted-Identity- oder Remote-Party-ID-Header bei ausgehenden Anrufen — so verlassen Anrufe die Bridge mit der korrekten Präsentations-Nummer für den Carrier. Carrier, die den From-Header stripen, sehen trotzdem die richtige ID.
• Strikte Nummern-Whitelist. Die Bridge wählt nur Nummern, die der Betreiber explizit aufgelistet hat. Wer eine Wähl-URL findet, kann sie nicht auf ein Premium-Ziel umleiten — die Whitelist ist das Tor, der Alias nur eine Abkürzung zu einer Zeile darin.
• Geographische Präfix-Beschränkung. Betreiber-konfigurierbare E.164-Präfix-Allowlist. Ein Deployment, das nur europäische Ziele wählt (oder jede Teilmenge), ist eine Konfigurationszeile. Plus eine Blocklist für Premium-Ranges, die immer gewinnt — auch wenn ein Whitelist-Eintrag versehentlich eine enthält.
• Pro-Anruf-Betrugsdeckel. Harte Limits auf gleichzeitige ausgehende Anrufe, maximale Anrufdauer, tägliche Anrufzahl pro Raum und pro Requester-IP. Selbst wenn die Whitelist durchbrochen wäre, könnte ein Angreifer keine unbegrenzte Carrier-Rechnung verursachen, bevor der Deckel zuschlägt.
• Mid-Call-Telefon-zu-Meeting-Knopf. Während ein Meeting läuft, kann jeder im Raum auf Telefon wählen drücken, eine Nummer eintippen, und die Bridge holt diese Nummer als Teilnehmer in den Raum. Kein Tool-Wechsel, kein Neubeitritt. Das Äquivalent zu Zoom Phone oder Teams Phone — eingebaut, ohne Zusatzlizenz.
• Text-to-Speech-Auto-Reply mit länderabhängiger Sprache. Beantworten Sie bestimmte eingehende Anrufe mit einer vorgefertigten Nachricht, statt das Softphone klingeln zu lassen. Match per ISO-2-Land, Landname oder rohem E.164-Präfix — Deutsch für +49, „I do not speak Mandarin“ für +86, Englisch für alle anderen. Nutzt die Windows-SAPI-Engine, beim Start auf G.711 vorgerendert, damit der erste passende Anruf in Millisekunden antwortet — ohne TTS-Latenz. Kein API-Key, kein externer Dienst, keine Daten verlassen den Host.

CodeB Phone — das Tischtelefon im Browser (PWA)

Jenseits der Ad-hoc-Meeting-Räume betreibt derselbe Stack CodeB Phone — eine registrierte Identität, die bei eingehenden Anrufen von Teammitgliedern und vom PSTN-Trunk klingelt und sich über den eingebauten OIDC-IdP anmeldet. Installierbar als Progressive Web App auf Windows, macOS, Chromebook und Android. Offen lassen, den ganzen Tag Anrufe annehmen.

• Als Desktop-App installierbar. Progressive Web App auf Windows, macOS, Chromebook und Android. Eigenständiges Fenster, Dock-/Taskleisten-Icon, startet mit dem OS. Tab-Discard kann es nicht beenden; und es belegt keinen Tab-Slot. Kein MSI, kein Provisioning-Portal — jeder Mitarbeiter hat in fünf Minuten ein Tischtelefon.
• Selbst-aktualisierend. Erscheint ein neuer Build, bemerkt das offene Phone das innerhalb von Minuten und zeigt einen kleinen „Update verfügbar — neu laden“-Chip. Ein Klick rollt vorwärts — ohne Cache-Leeren, ohne Admin. Mid-Call-Updates werden bis zur Bereitschaft aufgeschoben.
• Eingehende Anrufe läuten in Ihrem Tab. Als Benutzer registrieren (anna, sales, empfang…), und die SIP-Bridge leitet eingehende PSTN- und Teamanrufe an Ihren Tab — mit gewohntem Klingelton, OS-Benachrichtigung und Annehmen/Ablehnen. Annehmen — und der Meeting-Raum öffnet sich mit dem Anrufer schon drin.
• Browser-zu-Browser-Direktanrufe. Einen Namen ins Call-Widget tippen und das Telefon dieses Kollegen klingelt Peer-to-Peer — kein SIP-Trunk, keine Carrier-Minute. Stattdessen eine Nummer eintippen, und die Bridge wählt über Ihre Trunks. Ein Bedienelement, zwei Backends, kein Moduswechsel. Null-Kosten-Inhouse-Telefonie.
• Auto-Erholung nach Trunk-Verlust. Wenn eine TK-Anlage oder ein SIP-Trunk neu startet oder vom Netz fällt, baut die Bridge die abgehangene Registrierung ab und registriert sich innerhalb von etwa einer Minute neu. Eingehende Anrufe laufen wieder, ohne den Dienst neu zu starten.
• Operator-Sichtbarkeit. Eingebaute Admin-Views zeigen aktuelle Ein- und Ausgangsanrufe, wer wohin geroutet wurde, und den Live-Trunk-REGISTER-Status — nützlich, wenn ein Anrufer sagt „Ich habe geklingelt und keiner ist drangegangen“. Alles on-prem, kein externes Dashboard nötig.

ONVIF-Kameras als anrufbare Ziele

Eine ONVIF-IP-Kamera bei der Bridge anmelden, und sie erscheint im Call-Widget unter einem freundlichen Namen. Anrufen — und die Kamera streamt das Livebild in Ihren Browser; Talkback-Taste schickt Ihr Mikrofon an den eingebauten Kamera-Lautsprecher. Für Türstationen, Empfangskameras, Lager-Sprechanlagen, Stallkameras, Remote-Site-Monitoring. Live-Demo testen: CodeB Phone öffnen, beliebigen Namen registrieren, dann camera wählen — das ist der öffentliche Test-Alias, der auf eine echte ONVIF-Kamera zeigt.

• Kamera per Name anrufen. Jede Kamera bekommt in der Bridge-Konfiguration einen kurzen Alias (kamera, empfang, laderampe). Diesen Namen ins Call-Widget tippen — und live H.264-Video öffnet sich in einem eigenen Viewer-Fenster, ohne Zusatz-App, ohne Plug-in. Kameranamen sind systemweit reserviert; niemand kann eine Softphone-Identität registrieren, die eine Kamera-Route überschattet.
• Zweiwege-Audio per ONVIF-Backchannel. Auf Kameras mit Backchannel-Profil (die meisten Reolink, Hikvision, Dahua, Axis-Innengeräte mit Lautsprecher) routet ein Talkback-Klick Ihr Mikrofon über den Kamera-Lautsprecher. Push-to-talk durch eine Türstation, einen bellenden Hund beruhigen, einem Liefer-fahrer Anweisungen geben — ohne den Browser zu verlassen.
• Kamera-Credentials verlassen den Server nie. Die Bridge hält die HTTP-Credentials der Kamera in ihrer lokalen Config und signiert ausgehende Aufrufe selbst. Der Browser sieht nur einen freundlichen Namen und eine SDP-Antwort — nie eine RTSP-URL, nie ein Passwort, nie einen Hostnamen.
• Direkte Medien, Server bleibt raus. Der Signalling-Endpunkt vermittelt nur den SDP-Austausch; sobald der Anruf läuft, fließt WebRTC-Medien direkt zwischen Browser und On-Premises-Kamera-Relay. Kein Transkodierdienst, kein Drittanbieter-Relay, keine Per-Minuten-Medien-Rechnung. Die Server-CPU bleibt im Leerlauf, auch mit mehreren Kameras live.
• Standardkonforme Kameras. RTSP und ONVIF — dieselben Protokolle, die jede Prosumer-IP-Kamera schon spricht. Kein Hersteller-SDK, kein Cloud-Konto, kein Firmware-Lock-in. Getestet mit Reolink und Hikvision; jede Kamera mit Main/Sub-RTSP-Profil, H.264-Video und (optional) AAC- oder G.711-Audio passt.

Eingebautes OpenID-Connect-Single-Sign-On

CodeB Conference wird mit einem vollständigen OpenID-Connect-Identity-Provider ausgeliefert — derselbe Baustein, der separat als CodeB Single Sign-On dokumentiert ist. Einmal auf der Landeseite anmelden — und Sie tragen eine authentifizierte Identität in jeden Meeting-Raum, jedes Einbett-Skript der Call-us-Schaltfläche und jede PWA-Softphone-Session, ohne zweiten Login-Dialog. Der IdP föderiert außerdem jede andere Anwendung, die Sie betreiben, sodass der Credential-Store einzigartig bleibt.

• OIDC-IdP ausgeliefert, nicht aufgesetzt. Dieselbe Installation, die das Conference-Signalling betreibt, exponiert auch /.well-known/openid-configuration — Standard OpenID Connect Core 1.0, Authorization Code Flow mit PKCE (S256), RS256-signierte JWTs. Jede OIDC-konforme Relying Party funktioniert dagegen; keine separate IdP-Beschaffung, kein SAML-Proxy, kein Keycloak daneben.
• Verified-in-Call-Badge. Authentifizierte Teilnehmer bekommen das bernsteinfarbene CodeB-Schild neben ihrem Namen in jedem Meeting-Tile — sichtbare Bestätigung, dass die Person die ist, die sie zu sein behauptet, und nicht ein Gast, der zufällig einen bekannten Anzeigenamen eingetippt hat. Vorgetäuschte Identitäten können nicht als bekannte Mitarbeiter durchgehen, ohne dass das Meeting nur für Mitglieder geöffnet sein muss.
• Ein Credential-Store über Sprache, Video und föderierte Apps. Die Anmeldung nutzt den SIP-HA1-Passwort-Hash, den Ihre Softphones bereits verwenden. Das Klartext-Passwort erreicht den Server nie — der Browser hasht es vor dem Senden. Ein Benutzer-Datensatz steuert das Telefon, den Videoraum und jede föderierte Relying Party.
• Nextcloud, WordPress und jede OIDC-App föderieren. Zeigen Sie Ihre Nextcloud- oder WordPress-Installation auf die Discovery-URL, und die Anwender melden sich dort mit derselben CodeB-Kennung an, mit der sie sich am Telefon anmelden. Dokumentierte Setup-Anleitungen für beide; jede andere OIDC-konforme Relying Party funktioniert ab Werk.
• Cookie-frei, RSA-Schlüssel pro Mandant. Kein Session-Cookie auf der Installation. Tokens liegen pro Tab in sessionStorage und verschwinden, sobald der Tab schließt. Jeder Mandant bekommt seinen eigenen 2048-Bit-RSA-Signaturschlüssel; Tokens für Mandant A verifizieren nie gegen Mandant B.

Vollständige Endpunkt-Referenz und Token-Form auf der CodeB-Single-Sign-On-Produktseite weiter unten oder auf der OIDC-Feature-Seite auf phone.codeb.io.

EU-Wallet-Anmeldung — OID4VP 1.0 Verifier, ausgeliefert Verifiziert 2026-06-08

Ein eingebauter OpenID for Verifiable Presentations (OID4VP) 1.0-Verifier akzeptiert EU Digital Identity Wallet-Präsentationen (EUDIW / eIDAS 2.0) als hochwertigen Anmeldefaktor für CodeB Conference. Besucher beweisen ihre Identität, indem sie genau die Attribute teilen, die Sie anfragen — kein Passwort, kein zweites Konto, kein Drittanbieter-Verifier dazwischen. Der Verifier ist HAIP-1.0-konform (High Assurance Interoperability Profile) und nutzt die Standards, die auch die EU-Referenz-Wallet anpeilt — jede konforme Wallet auf dem Smartphone funktioniert ohne wallet-spezifische Integration. Ende-zu-Ende-Roundtrip-Test gegen eine spec-konforme Mock-Wallet am 2026-06-08 bestanden, HTTP 200 mit verifizierten PID-Claims und signierter SSO-Assertion.

• OID4VP 1.0 + HAIP 1.0 konform. Nativer OID4VP-1.0-Verifier nach dem High Assurance Interoperability Profile. Authorization Request als ES256-signierter JAR (typ=oauth-authz-req+jwt) mit Client-ID-Schema x509_san_dns und x5c-Kette gemäß HAIP 1.0. Keine wallet-spezifische Integration — jede konforme Wallet funktioniert.
• DCQL, kein PEX-Legacy. Credential-Anfragen in der nativen OID4VP-1.0-DCQL-Syntax (Digital Credentials Query Language), nicht im älteren Presentation-Exchange-Format. Klarere Queries, keine Legacy-Übersetzungsschicht, schnellere Integration mit modernen Wallets.
• JWE ECDH-ES + A128GCM Response-Verschlüsselung. Verifier-Responses laufen über JWE Compact Serialization mit alg=ECDH-ES und enc=A128GCM, NIST SP 800-56A Concat KDF, RFC 7518 §4.6 / §5.1 konform. Offengelegte Claims werden auf den ephemeren P-256-Key des Verifiers verschlüsselt — kein Klartext auf der Leitung.
• SD-JWT VC mit KB-JWT-Holder-Bindung. Selektive-Offenlegung-JWT Verifiable Credentials (Format vc+sd-jwt) mit SHA-256 _sd-Disclosure-Hashes, Holder-gebunden über ein KB-JWT, das Nonce, Audience und sd_hash des Verifiers neu signiert. Replay-resistent per Konstruktion.
• PID-Claims selektiv offengelegt. Der Testlauf hat given_name, family_name, birth_date und age_over_18 aus einem urn:eu.europa.ec.eudi:pid:1-Credential gezogen — fragen Sie nur das ab, was das Meeting wirklich braucht. DSGVO-Datenminimierung per Konstruktion.
• Verified-Claim-SSO-Relais. Bei erfolgreicher Präsentation prägt der Verifier eine signierte SSO-Assertion mit amr=["vc"] und acr="urn:codeb:acr:eudi-wallet". Jede Relying Party, die dem OIDC-IdP des Mandanten vertraut, erbt die verifizierte Identität über das gewöhnliche UserInfo — eine Wallet-Präsentation, jede föderierte App profitiert.
• Verified-in-Call-Badge erweitert. Wo Credential Provider V2 das bernsteinfarbene CodeB-Schild für Arbeitsstations-Nutzer setzt, bekommen Wallet-attestierte Teilnehmer ein zweites Schild mit dem Aussteller ihres Credentials.
• Selbst gehostet, EU-souverän, NIS2-/DORA-konform. Der Verifier läuft neben dem OIDC-IdP auf Ihrem IIS-Host. Die Wallet spricht direkt mit Ihrer Domäne — nicht mit einem SaaS-Verifier, nicht mit einem Hyperscaler. Sessions werden atomar unter App_Data/<mandant>/vp-sessions/ persistiert.
• Heute einsatzbereite Anwendungsfälle. Pilotinstallationen, Identity-Proofing-Demos, Member-Organisation-Logins, beschränkte Meeting-Räume (nur verifizierte Ärztinnen, nur Volljährige, nur EU-Ansässige). Produktives High-Assurance-Identity-Proofing folgt in Iteration 2 mit LoTL-Trust-Chain und Per-Issuer-JWKS-Verifikation — transparent, was heute ausgeliefert ist und was als Nächstes kommt.

Vollständiges Proof-of-Work-Transkript und Crypto-Stack auf der CodeB-EU-Wallet-Sign-In-Seite auf phone.codeb.io; die Plattform-API-Referenz dokumentiert die Integrationsoberfläche.

CodeB Voice AI — eingehender Empfang, ausgehende Kampagnen, REST-API

CodeB Voice AI liefert einen sprachbasierten virtuellen Assistenten, der eine eingehende Telefonnummer in Ihrem Namen beantwortet und ausgehende Anrufe nach Zeitplan platziert. Austauschbare AI-Voice-Engine, on-prem oder Cloud pro Deployment, Personas pro vnum, REST-API mit Webhooks für jedes Call-Lifecycle-Event, und derselbe Launcher hinter dem Browser-Button Produkte mit KI-Assistenten besprechen oben auf dieser Seite — ein Stack, drei Oberflächen.

• Sprach-KI beantwortet das Telefon. Eine DID auf CodeB zeigen, einen Real-time-Voice-Modus wählen, einen System-Prompt einfügen — und der nächste eingehende Anruf wird von einer Sprach-KI beantwortet, die jede Sprache spricht, dem Skript folgt, Nachrichten aufnimmt, bei Bedarf zu Personal weiterleitet und Ihnen das Transkript per E-Mail schickt. Modell-Backend pro Deployment austauschbar, läuft über Ihren bestehenden Trunk — kein Per-Minuten-SaaS-Aufschlag.
• Personas pro Nummer. Ein Empfang kann hinter drei DIDs als drei verschiedene Personas laufen — Empfang, Restaurant, Spa — jede mit eigenem Prompt, eigener Wissensbasis und eigenem Eskalationspfad. Kleine Teams verlieren keine After-Hours-Anrufe mehr, ohne ein Call-Center einzurichten.
• Virtueller Assistent im Browser. Dasselbe Backend nimmt ab, wenn ein Besucher auf Produkte mit KI-Assistenten besprechen klickt — reines WebRTC-Audio, ohne Installation, ohne Termin, klingelt am Assistenten-Alias statt an einem Tischtelefon. Gleiche Prompts, gleiche Transkript-Pipeline, gleiche Datenresidenz.
• Ausgehende Kampagnen. Eine Liste von Nummern hinterlegen, CodeB Voice AI wählt sie nach Zeitplan ab — Wiederholung bei Nichtannahme, Live-Monitor, Drosselung pro vnum. Für Termin-Erinnerungen, Zahlungs-Nachfassen, Kunden-Research-Rückrufe. Dieselbe Voice-AI-Engine, dieselben Trunks, dieselbe Transkript-Pipeline.
• REST-API + Webhooks. Öffentliche REST-Endpunkte zum Starten, Überwachen und Beenden von Voice-AI-Anrufen, plus Webhooks bei jedem Lifecycle-Event — call.started, call.answered, call.transferred, call.ended. Direkt anbindbar an CRM, Ticketsystem oder Ops-Dashboard, ohne Polling.
• Signierte Transkripte. Jeder Anruf — Empfang, ausgehend oder Browser-Assistent — erzeugt ein ECDSA-signiertes Transkript-JSON mit Sprecher-Wechseln und Zeitstempeln. Prüffest, nicht-abstreitbar, bei Anrufende automatisch an den Operator gemailt.

Mandantenfähigkeit

• Mandant = Anfrage-Domäne. Ein Request an phone.acme.com wandert an den Acme-Mandanten; phone.contoso.com an Contoso. Signalling-Endpunkt, SIP-Bridge und CDR-Writer hängen alle am Host-Header. Keine geteilte Benutzertabelle, keine mandantenübergreifenden Kollisionen.
• Alles pro Mandant. SIP-Credentials, Trunks, Betrugsdeckel, Auto-Reply-Regeln, CDR-Dateien und registrierte Softphones — alles am Mandanten-Schlüssel verankert. Speicherpfade sind mandanten-präfix; ein Bug in einem Mandanten kann nicht in die Daten eines anderen greifen.
• Drop-in-Mandanten, ohne Downtime. Einen neuen Kunden aufsetzen, heißt einen Hostnamen hinzufügen — DNS-A-Record + IIS-Host-Binding + Mandanten-Config-Block. Keine Schema-Migration, kein Neustart anderer Mandanten. Die Instanz bedient die anderen weiter, während der neue aufwärmt.

Architektur — was wo läuft

IIS-Signalling	Ein kleiner WebSocket-Endpunkt auf der IIS-Seite vermittelt Raumbeitritte, SDP-Angebote/-Antworten und ICE-Kandidaten. Der Server bleibt aus dem Medienpfad heraus — er hilft nur, dass sich Peers finden.
CodeB TURN (optional)	Ein On-Premises-STUN+TURN-Relay für Nutzer hinter strengen Firmen-Firewalls oder symmetrischem NAT. Einzeldatei-Installation, läuft als Windows-Dienst. Kein Docker, keine Linux-Abhängigkeit. Bleibt im Netz; air-gap-fähig.
CodeB SIP-Bridge (optional)	Ein Windows-Dienst, der sich als SIP-Nebenstelle an Ihrer TK-Anlage oder Ihren Trunks registriert, zwischen WebRTC-Browsern und dem Carrier-Audio-Pfad brückt und sich durch Neustarts und Netzwerk-Drops am Leben hält. Nur nötig, wenn Sie mit Telefonen sprechen wollen.
CodeB Camera-Relay (optional)	Ein kleiner RTSP → WebRTC-Übersetzer, der auf demselben Host wie die Bridge läuft und sich über LAN mit Ihren IP-Kameras verbindet. Nur nötig, wenn Sie Kameras von der Phone-Oberfläche aus anrufen wollen.
Nur Browser — keine Client-Installation	Jeder Teilnehmer kommt über eine normale HTTPS-Seite. Kamera, Mikrofon, Bildschirmfreigabe, Dateitransfer, Aufzeichnung — alles im User-Agent. Optionale Installation für die Always-on-Phone-Oberfläche; alles andere ist nur eine URL.
Gehostet auf phone.codeb.io	Sie nutzen die öffentliche Instanz unter phone.codeb.io. Aloaha betreibt und wartet Signalling-, TURN- und SIP-Bridge-Server; Sie binden den Launcher ein, und wir lösen Ihren Büro-Alias auf das richtige Ziel auf.
Selbst gehostet	Für Estates, die Medien nicht über einen Drittdienst routen dürfen, lässt sich der vollständige Server-Stack — Signalling, STUN/TURN, SIP-Bridge, Kamera-Relay, OIDC-IdP — auf eigenen Windows-Hosts mit IIS ausrollen. Keine ausgehende Abhängigkeit; geeignet für air-gapped Pilotinstallationen.
Lizenzierung	Gehostet: pro Sitz oder pro Raum als SKU auf Anfrage. Selbst-gehostet: Site-Lizenz, bepreist nach Installationsumfang. KI-Empfang und ONVIF-Kamera-Relay als Add-ons lizenziert.

Jetzt ausprobieren: scrollen Sie zum Footer dieser Seite und klicken Sie auf Im Browser anrufen. Das ist CodeB Conference und es klingelt in unserem Büro.

Wie es sich von CodeB Web SSO unterscheidet

CodeB Web SSO ist eine Browser-Erweiterung auf der Arbeitsstation, die Benutzernamen, Passwörter und TOTP-Codes in Web-App-Anmeldeformulare einfügt. Sie versteckt den Credential-Tanz vor dem Anwender — jede Anwendung behält aber ihr eigenes Credential. CodeB Single Sign-On ist die Identity-Schicht darunter: ein OIDC-IdP, auf den andere Anwendungen zeigen, sodass das Credential an einer Stelle lebt und jede Relying Party ein signiertes Token statt einer Passwort-Kopie erhält. Die beiden Produkte ergänzen sich, sie ersetzen sich nicht.

Was Sie bekommen

• Standardbasiert. OpenID Connect Core 1.0, Authorization Code Flow mit PKCE (S256), RS256-signierte JWTs. Discovery nach RFC 8414, JWKS nach RFC 7517. Jede OIDC-konforme Relying Party funktioniert.
• Cookie-frei nach Design. Kein Session-Cookie. Kein Tracking-Cookie. Das Login-Formular erzeugt den Autorisierungs-Code direkt, Tokens liegen pro Tab in sessionStorage und sind weg, sobald der Tab geschlossen wird.
• Ein Credential-Store. Die Anmeldung nutzt denselben HA1-Passwort-Hash, den Ihre SIP-Softphones bereits verwenden. Das Klartext-Passwort erreicht den Server nie — der Browser hasht es vor dem Senden. Ein Benutzer-Datensatz steuert sowohl Sprache als auch Identität.
• RSA-Schlüssel pro Mandant. Jeder Mandant bekommt einen eigenen 2048-Bit-RSA-Signaturschlüssel, bei erstem Bedarf erzeugt. Tokens für Mandant A verifizieren nie gegen Mandant B.
• Rollen, server-seitig erzwungen. Vier Rollen ab Werk: admin, user, siponly und guest. Die Rolle wandert im JWT als eigener Claim und als Standard-groups-Eintrag. Admin-Seiten prüfen role === "admin" serverseitig bei jedem Request — client-seitige Prüfungen sind nur UI.
• Mandantenfähig ab Tag eins. Mandanten-Identität ist die Anfragedomäne. Ein neuer Mandant entsteht durch Hinzufügen eines Hostnamens — der erste Request am OIDC-Endpunkt erzeugt den RSA-Schlüssel. Keine Schema-Migration, kein Neustart, keine Downtime für die anderen Mandanten.

Die Endpunkte

Discovery	/.well-known/openid-configuration — RFC-8414-Metadaten. Listet jeden anderen Endpunkt.
JWKS	/.well-known/jwks.json — RFC-7517-Key-Set. Jede RP kann Token-Signaturen verifizieren.
Authorization	/oidc.ashx?action=authorize — leitet zum Login-Formular, dann mit Auth-Code zurück zur RP.
Token	/oidc.ashx?action=token — tauscht den Auth-Code (mit PKCE-Verifier) gegen Access-Token, ID-Token und Refresh-Token.
UserInfo	/oidc.ashx?action=userinfo — liefert sub, role und Profil-Claims des angemeldeten Nutzers.
End Session	/oidc.ashx?action=end_session — RP-initiierter Logout. Räumt Tokens client-seitig auf, leitet auf post_logout_redirect_uri.
Token-Laufzeiten	Access- & ID-Token 1 Stunde · Refresh-Token 7 Tage · Auth-Codes 60 Sekunden, einmalig verwendbar.
Signaturalgorithmus	RS256 (2048-Bit RSA), ein Schlüssel pro Mandant, rotierbar durch Löschen der Schlüsseldatei.
Audit-Log	JSONL unter App_Data/<tenant>/logs/codeb-oidc-YYYY-MM-DD.log, parallel ins Windows-Event-Log unter Quelle CodeBOIDC.
Lizenzierung	In CodeB Conference enthalten. Eigenständige IdP-Lizenz für Sites verfügbar, die nur den OIDC-Server ohne den Video-Stack brauchen.

Die Integration benötigt drei Zeilen Relying-Party-Konfiguration — Issuer-URL, Client-ID und Redirect-URI. Den Rest füllt das Discovery-Dokument aus. Die vollständige OIDC-Feature-Seite zeigt Integrationswalk-through und Claim-Form.

Was es tatsächlich tut

Web SSO wird als Browser-Erweiterung über die offiziellen Microsoft Edge Add-ons und den Chrome Web Store ausgeliefert, gepaart mit einem kleinen nativen Helfer. Wenn ein Anwender eine konfigurierte Seite aufruft, übergibt der Helfer die Anmeldedaten über einen sicheren Kanal an die Erweiterung, und die Erweiterung trägt sie für den Anwender in das Anmeldeformular ein. Die Anmeldedaten werden nie von der Seite gelesen, nie in seitenseitigem JavaScript serialisiert und nie in die Zwischenablage kopiert.

Für Security-Teams

• Keine im Browser gespeicherten Anmeldedaten. Anmeldedaten leben im nativen Helfer auf Betriebssystem-Ebene — nicht im Browser-Profil-Speicher, nicht im Erweiterungs-Speicher, nicht über Browser hinweg synchronisiert. Ein entwendetes Browser-Profil oder ein kompromittierter Sync-Schlüssel gibt nichts preis.
• Keine Zwischenablage, keine Persistenz. Web SSO trägt Anmeldedaten direkt in Formularfelder über den prozess-isolierten Native-Messaging-Kanal von Chrome und Edge ein. Sie werden nicht in die Zwischenablage kopiert und nicht im Erweiterungs-Speicher zwischen Anmeldungen aufbewahrt.
• Über offizielle Browser-Stores verteilt. Signiert und geprüft durch Microsoft und Google — dieselbe Lieferkette, die Ihre bestehende Browser-Erweiterungs-Richtlinie bereits abdeckt.
• Zero-Trust-freundlich. In Kombination mit dem Credential Provider V2 ist jede Web-Anmeldung an eine Workstation-Anmeldung gekoppelt, die selbst durch eine NFC-Karte, PKI-Smartcard oder ein USB-Token belegt war.

Für Ihre Anwender

• Ein-Klick- oder stille Anmeldung. Die meisten Seiten melden sich automatisch an, sobald die Seite vollständig geladen ist; die übrigen brauchen einen Klick.
• Keine wiederholten Eingabeaufforderungen. Anwender tippen Benutzernamen und Passwörter für die täglichen Anwendungen nicht mehr.
• Keine Unterbrechungen im Arbeitsablauf. Einmal ausgerollt, bleibt Web SSO unsichtbar — bis auf den seltenen Fall, in dem eine Eingabeaufforderung notwendig ist. Dann fragt es einmal und merkt sich das Ergebnis.
• TOTP-Auto-Fill. Web SSO kann auch den 6-stelligen Einmal-Code auf dem Zweitfaktor-Bildschirm erzeugen und eintragen. Kein Handy, kein Code-Kopieren zwischen Fenstern.

Über den Browser hinaus: Legacy- und Java-Anwendungen

Derselbe Credential-Broker, der die Browser-Erweiterung steuert, kann Anwender auch in alte native Windows-Anwendungen und in Java-Desktop-Anwendungen anmelden, die einen eigenen Anmelde-Dialog anzeigen. Ein häufiges Bereitstellungs-Muster ist T2med — die Java-basierte Praxisverwaltungs-Suite —, bei der Web SSO die tägliche Reibung der Programm-Start-Anmeldungen für medizinisches Personal beseitigt. Vollständige T2med-Fallstudie inklusive Demo-Video. Der Mechanismus lässt sich auf jede Anwendung verallgemeinern, die eine erkennbare Anmelde-Oberfläche aufweist.

Zwei Bereitstellungs-Wege

Mit CP V2 gebündelt	Wird automatisch vom Credential-Provider-Installer mit installiert, wenn Sie das Setup der CodeB Tools Edition ausführen. Kein separater Installationsschritt.
Einzeln	Web-SSO-Paket herunterladen, die ausführbare Datei beim ersten Start einmalig als Administrator ausführen, damit sie sich bei den unterstützten Browsern registriert — fertig. Keine CP-V2-Abhängigkeit.
Browser-Unterstützung	Microsoft Edge (Edge Add-ons Store) · Google Chrome (Chrome Web Store) · Chromium-basierte Browser über die Chrome-Erweiterung
Native & Java-Anwendungen	Ja — Anmeldedaten lassen sich in alte Win32-Anmelde-Dialoge und Java-Desktop-Anwendungen eintragen. Referenz: T2med.
Zweiter Faktor	Erzeugt und füllt RFC 6238 TOTP-Codes auf dem 2FA-Schritt automatisch ein, wobei das Geheimnis im nativen Helfer und nicht in der Seite gehalten wird
Konto-Konfiguration	Starten Sie CodeBWebSSO.exe aus der Toolbox, um Benutzerkonten je Seite/Anwendung anzulegen und zu bearbeiten
Verteilung	Browser-Erweiterungen registrieren sich automatisch beim ersten Browser-Neustart nach der Installation; der native Helfer ist eine einzelne ausführbare Datei
Lizenzierung	Im Credential Provider V2 enthalten · einzelne Sitz-Lizenz verfügbar