Einordnung — was BundID ist und wer sie betreibt
Die BundID ist das Nutzerkonto des Bundes für natürliche Personen. Sie wird vom Bundesministerium für Digitales und Staatsmodernisierung (BMDS, hervorgegangen aus dem BMI) verantwortet und technisch vom ITZ-Bund betrieben. Die Onboarding- und Verwaltungsschnittstelle für Diensteanbieter ist das Self-Service-Portal unter https://ssp.id.bund.de/, das seit dem 16. September 2024 in Betrieb ist und den vorherigen, formularbasierten Antragsprozess ablöst.
Wichtig für die Einordnung sind drei Abgrenzungen. Erstens: BundID ist für natürliche Personen — Unternehmen identifizieren sich über das Mein Unternehmenskonto (MUK) auf ELSTER-Basis. Ein Fachverfahren mit Anträgen sowohl von Bürgern als auch von Selbstständigen oder Gesellschaften muss beide Konten parallel anbinden. Zweitens: BundID ist kein SSO für Mitarbeiter — sie ist eine externe Identifizierungsquelle für Bürger gegenüber Verwaltungsdiensten. Drittens: die Bundesländer haben historisch eigene Servicekonten betrieben — die Bayern-ID auf der AKDB-Plattform ist das prominenteste Beispiel. Die OZG-Konsolidierung läuft auf BundID als bundesweites Standardkonto zu, eine vollständige Migration aller Länder ist 2026 aber noch nicht abgeschlossen.
Der Anbindungsweg ist seit dem SSP-Relaunch klar standardisiert. Es gibt drei Umgebungen: die Integrationsumgebung unter https://int.id.bund.de/ (für Tests und die Erstanbindung, ohne echte Personendaten), eine Testumgebung unter https://test.id.bund.de/ (für bestimmte Testszenarien) und die Produktivumgebung unter https://id.bund.de/. Der Support läuft primär über das SSP-Kontaktformular (Service → Serviceanfrage), Notfall-Adresse ist bundID@bmi.bund.de.
Vertrauensniveaus und Identifizierungsmittel
BundID kennt vier Stufen der Authentifizierung. Die Stufen sind im SAML-Response als Attribut stork-vt (OID urn:oid:1.2.40.0.10.2.1.1.261.94) abgebildet und korrespondieren mit den Werten STORK-QAA-Level-1 bis STORK-QAA-Level-4. Im Authentication-Request fordert das Fachverfahren das Minimum über RequestedAuthnContext mit Comparison="minimum" an.
Basisregistrierung
Benutzername und Passwort. Entspricht ausdrücklich nicht den Vorgaben der eIDAS-Verordnung — wird aus Benutzerfreundlichkeit angeboten, etwa für die Verwaltung des eigenen Kontos und das Sichten des Postfachs. Geeignet für rechtlich nicht bindende Vorgänge.
Substanziell
ELSTER-Zertifikat und einzelne notifizierte EU-Identitäten. Identität ist administrativ verifiziert. Reicht für die meisten Anträge ohne Schriftformerfordernis.
Hoch
„Online-Ausweis" — der Personalausweis mit Onlinefunktion, die Smart-eID, der elektronische Aufenthaltstitel und die Unionsbürgerkarte — sowie einzelne notifizierte EU-Identitäten. Pflicht, wo die Schriftform durch elektronische Mittel ersetzt wird (§ 3a VwVfG). Hinweis: „hoch" ist nicht in allen EU-Mitgliedstaaten verfügbar.
Identifizierungsmittel
Die im Authentication-Request über AKDB-Extensions auswählbaren Methoden sind Benutzername, eID, eIDAS, Authega, Diia, Elster und FINK. Das Fachverfahren legt fest, welche Methoden für die Anwendung zugelassen sind.
Das tatsächlich erreichte Niveau steht im Attribut-Statement der Assertion. Die zentrale Regel für die Anwendung: nie blind vertrauen, sondern bei jedem schutzwürdigen Schritt prüfen, ob die Sitzung das geforderte Niveau erreicht. Will ein Nutzer von „substanziell" auf „hoch" hochstufen, baut die Anwendung einen neuen AuthnRequest mit höherem RequestedAuthnContext — das ist der Step-Up-Fall.
Protokollwahl — SAML 2.0 als Standardweg
Anders als viele moderne Identity-Provider arbeitet BundID heute primär mit SAML 2.0. Eine OIDC-Variante ist im Onboarding-Portal vorbereitet und wird sukzessive ausgerollt, aber bei der überwiegenden Mehrheit der produktiven Anbindungen — Fachverfahren in Kommunen, Hochschul-Portale, Landesbehörden — ist SAML der eingesetzte Stack. Die folgenden Abschnitte beziehen sich daher auf SAML; die Konfigurationsmuster sind in OIDC analog, der Onboarding-Prozess identisch.
Die SAML-Konfiguration ist klar definiert. Der Identity-Provider wird über die folgenden URLs angesprochen:
# Integration (Test)
IdP Metadata: https://int.id.bund.de/idp
SSO HTTP-POST: https://int.id.bund.de/idp/profile/SAML2/POST/SSO/
SSO HTTP-Redirect: https://int.id.bund.de/idp/profile/SAML2/Redirect/SSO/
# Produktion
IdP Metadata: https://id.bund.de/idp
SSO HTTP-POST: https://id.bund.de/idp/profile/SAML2/POST/SSO/
SSO HTTP-Redirect: https://id.bund.de/idp/profile/SAML2/Redirect/SSO/
Der NameIDFormat ist urn:oasis:names:tc:SAML:2.0:nameid-format:transient — das ist ein bewusst kurzlebiger Identifier, nicht der stabile Personenidentifikator. Den dauerhaften Schlüssel liefert BundID stattdessen über das Attribut extident mit der OID urn:oid:1.3.6.1.4.1.25484.494450.3 — das ist das bereichsspezifische Personenkennzeichen Version 2 (bPK2), das pro Diensteanbieter eindeutig und über Sessions hinweg stabil ist.
Wichtig — und der Punkt, an dem die Analogie zu OAuth aufhört: in einer SAML-Föderation gibt es keine Client-ID und kein Client-Secret im OAuth-Sinne. Die Identität des Diensteanbieters wird über die EntityID (eine URL, z. B. https://fachverfahren.example.de/saml) und ein X.509-Zertifikat hergestellt, das beim Onboarding ins SSP hochgeladen wird. Authentisierung der Nachrichten erfolgt nicht über einen geteilten Geheimnis-String, sondern über XML-Signaturen mit RSA-Schlüsseln. Was bei OAuth Client-Secret heißt, ist hier der private Schlüssel zum hinterlegten Zertifikat.
Onboarding Schritt für Schritt
Was muss eine Kommune oder eine Behörde konkret tun, damit ihr IT-Dienstleister ein Fachverfahren produktiv an BundID anbinden kann? Acht Schritte, in der Reihenfolge, in der sie ablaufen.
Schritt 1 — BMI-ID der Behörde sicherstellen
Die Behörde muss im SSP unter einer BMI-ID bekannt sein — einer eindeutigen Kennung, die das BMDS pro Behörde vergibt. Ohne diese Kennung kann keine Anbindung beantragt werden. Viele Kommunen haben sie bereits, weil sie über andere OZG-Verfahren schon im Bund-Ökosystem registriert sind; im Zweifel über das SSP-Kontaktformular oder per Mail an bundID@bmi.bund.de erfragen. Diesen Schritt erledigt die Behörde, nicht der IT-Dienstleister — er setzt einen behördlichen Verwaltungsakt voraus.
Schritt 2 — SSP-Account anlegen
Ein Berechtigter der Behörde registriert sich unter https://ssp.id.bund.de/. Im SSP werden anschließend alle Anbindungsvorgänge gepflegt — Antrag der Komponente Authentifizierung, Antrag der Komponente Postfach, Upload der Metadaten, Sperrung von Zertifikaten, Pflege der LeiKa-Leistungen. Der IT-Dienstleister kann delegiert mitarbeiten, der formale Antrag liegt aber bei der Behörde.
Schritt 3 — Antrag „Komponente Authentifizierung" stellen
Im SSP-Menü Leistungen → Antrag Komponente Authentifizierung wird das Verfahren beantragt. Pflichtangaben sind unter anderem: Name und Beschreibung der Anwendung, Datenschutzerklärung, Impressum, Liste der angeforderten Attribute mit fachlicher Begründung (Datenminimierungsprinzip nach DSGVO), benötigte Vertrauensniveaus, freigeschaltete Identifizierungsmittel, Logo in den geforderten Formaten. Das Logo ist erfahrungsgemäß die häufigste Verzögerungsursache — Auflösung, Farbraum und Hintergrund sind strikt vorgegeben. Wer hier nachlässig ist, verliert leicht zwei bis drei Werktage durch Re-Submissions.
Schritt 4 — Schlüsselpaar und Zertifikate erzeugen
Das Fachverfahren braucht mindestens zwei Zertifikate: ein Signing-Zertifikat (für die Signatur der AuthnRequests und SP-Metadaten) und ein Encryption-Zertifikat (für die Entschlüsselung der vom IdP zurückgelieferten Assertion). In den meisten Setups werden beide Aufgaben mit demselben Schlüssel abgedeckt; produktiv kann man auch ein primäres und ein sekundäres Signing-Zertifikat parallel hinterlegen, um Schlüsselrotation ohne Downtime zu ermöglichen.
Vorgaben: Schlüsselalgorithmus RSA, Signaturalgorithmus SHA512withRSA, Schlüssellänge 2048 oder 4096 Bit. Die Zertifikate werden im SSP als Base64-kodierter Inhalt ohne BEGIN/END-Header hinterlegt — eine kleine, aber häufige Stolperstelle. Eine Behörde mit eigenem PKI-Stack erzeugt die Schlüssel dort; alternativ kann der IT-Dienstleister sie generieren und im SSP eintragen.
Schritt 5 — SP-Metadaten erzeugen und im SSP hochladen
Das Fachverfahren generiert seine Service-Provider-Metadaten als XML-Dokument. Spring Security SAML2 stellt diese Datei automatisch unter /saml2/service-provider-metadata/{registrationId} bereit. Inhalte: EntityID (eine URL des Fachverfahrens, z. B. https://kommune.example.de/saml), AssertionConsumerService-URL (der Endpunkt, an dem die Assertion zurückkommt, HTTP-POST-Binding), die genannten X.509-Zertifikate Base64-kodiert, das verwendete Signaturverfahren rsa-sha256 oder rsa-sha512 und das Verschlüsselungsverfahren aes128-cbc oder aes256-gcm.
Im SSP unter Leistungen → Upload und Aktualisierung der Metadaten werden die Werte in eine Maske eingetragen und das Zertifikat eingefügt. Hochladen lässt sich theoretisch jederzeit; verarbeitet wird nach Aussage des Betreibers einmal pro Woche, jeden Dienstagnachmittag. Das ist die Stelle, an der ein Anbindungsplan an die Bund-Taktung anschließen muss — wer am Donnerstag hochlädt, hat fünf Werktage Wartezeit.
Schritt 6 — IdP-Metadaten in das Fachverfahren einbinden
Die andere Richtung: das Fachverfahren braucht die Metadaten von BundID, um Assertions verifizieren und den AuthnRequest verschlüsseln zu können. Sie werden von https://int.id.bund.de/idp (Test) bzw. https://id.bund.de/idp (Produktion) als XML abgerufen. Spring Security kann diese Datei direkt per metadata-uri einbinden. Wer mit Plattformen arbeitet, die nur PEM-Format akzeptieren (HISinOne ist ein Beispiel), muss aus der Metadaten-XML das Zertifikat zwischen den <ds:X509Certificate>-Tags extrahieren, mit BEGIN/END-Header umformatieren (etwa über samltool.com/format_x509cert.php) und als .crt-Datei abspeichern.
Schritt 7 — AuthnRequest mit AKDB-Extensions konfigurieren
Seit August 2024 verlangt BundID, dass jeder AuthnRequest die AKDB-SAML-Extensions mit Namespace https://www.akdb.de/request/2018/09 mitliefert. Sie steuern, welche Identifizierungsmittel im Login-Bildschirm angezeigt werden, welcher Anwendungsfall (Login, Selbstregistrierung, Account-Verknüpfung) durchlaufen wird und welche Attribute angefordert werden. Der nächste Abschnitt zeigt die XML-Struktur konkret.
Schritt 8 — Integration testen und produktiv schalten
Erste Tests erfolgen in der Integrationsumgebung gegen int.id.bund.de mit synthetischen Testidentitäten — Benutzername/Passwortkonten lassen sich direkt selbst registrieren, für die eID-Variante kann ein Testausweis vom BMI bezogen oder per PersoSim simuliert werden (BSI-Testinfrastruktur, AusweisApp im Entwicklermodus). Erst nach erfolgreichem Durchlaufen aller Use-Cases — Login, Step-Up, gegebenenfalls Account-Verknüpfung — wird die Produktivschaltung im SSP beantragt.
SP-Metadaten — das Herzstück der Föderation
Die Service-Provider-Metadaten sind das einzige, was BundID vom Fachverfahren formal kennt. Eine knappe, korrekt strukturierte Datei sieht im Kern so aus:
<md:EntityDescriptor entityID="https://kommune.example.de/saml"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
AuthnRequestsSigned="true"
WantAssertionsSigned="true">
<md:KeyDescriptor use="signing">
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>
MIIDGDCC... <!-- Base64, ohne BEGIN/END-Header -->
</ds:X509Certificate></ds:X509Data></ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>
MIIDGDCC...
</ds:X509Certificate></ds:X509Data></ds:KeyInfo>
</md:KeyDescriptor>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://kommune.example.de/login/saml2/sso/bundid"
index="0" isDefault="true" />
</md:SPSSODescriptor>
</md:EntityDescriptor>
Drei Stellen sind kritisch. Die EntityID ist eine technische URL, kein Frontend-Link — sie muss eindeutig, stabil und im SSP genauso eingetragen sein wie im XML. Die AssertionConsumerService-Location ist der HTTP-POST-Endpunkt, an dem das Fachverfahren die Assertion entgegennimmt; bei Spring Security ist das per Default /login/saml2/sso/{registrationId}. Und die Zertifikate sind Base64 ohne Header — wer den BEGIN/END-Block in der XML belässt, bekommt eine Parser-Fehlermeldung des SSP.
AuthnRequest mit AKDB-Extensions
Seit August 2024 verlangt BundID, dass jeder Authentication-Request die AKDB-Extensions mitführt — sie steuern, welche Identifizierungsmittel angeboten werden und welche Attribute angefordert werden. Ohne diese Extensions akzeptiert der IdP den Request nicht mehr.
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:akdb="https://www.akdb.de/request/2018/09"
Destination="https://int.id.bund.de/idp/profile/SAML2/POST/SSO/"
ID="_abc123" Version="2.0" IssueInstant="2026-05-14T10:00:00Z"
AssertionConsumerServiceURL="https://kommune.example.de/login/saml2/sso/bundid"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
<saml:Issuer>https://kommune.example.de/saml</saml:Issuer>
<samlp:Extensions>
<akdb:AuthenticationRequest
xmlns:akdb="https://www.akdb.de/request/2018/09" Version="2">
<akdb:AuthnMethods>
<akdb:Benutzername><akdb:Enabled>true</akdb:Enabled></akdb:Benutzername>
<akdb:eID><akdb:Enabled>true</akdb:Enabled></akdb:eID>
<akdb:eIDAS><akdb:Enabled>true</akdb:Enabled></akdb:eIDAS>
<akdb:Elster><akdb:Enabled>true</akdb:Enabled></akdb:Elster>
</akdb:AuthnMethods>
<akdb:RequestedAttributes>
<akdb:RequestedAttribute Name="urn:oid:1.3.6.1.4.1.25484.494450.3"
RequiredAttribute="true" />
<akdb:RequestedAttribute Name="urn:oid:2.5.4.42"
RequiredAttribute="true" /> <!-- givenName -->
<akdb:RequestedAttribute Name="urn:oid:2.5.4.4"
RequiredAttribute="true" /> <!-- surname -->
<akdb:RequestedAttribute Name="urn:oid:1.2.40.0.10.2.1.1.261.94"
RequiredAttribute="true" /> <!-- stork-vt -->
</akdb:RequestedAttributes>
</akdb:AuthenticationRequest>
</samlp:Extensions>
<samlp:RequestedAuthnContext Comparison="minimum">
<saml:AuthnContextClassRef>STORK-QAA-Level-3</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
Drei Anwendungsfälle steuern die Extensions: Login (normale Anmeldung), Selbstregistrierung (der Bürger hat noch kein BundID-Konto und legt es im Zuge der Anmeldung an) und Account-Verknüpfung (Wiederanbindung nach einem Pseudonym-Wechsel, etwa nach Personalausweis-Tausch). Welcher Fall durchlaufen werden soll, steht im Service-Element der Extensions. Die genauen Werte und Code-Block-Vorlagen sind im SSP-Leitfaden unter https://ssp.id.bund.de/ip?id=downloads dokumentiert.
Attribute und ihre OIDs
BundID liefert Personenattribute als SAML-Attribute mit OIDs als Namen — nicht mit Klartext-Bezeichnern wie bei OIDC. Welche Attribute kommen, hängt vom angeforderten Vertrauensniveau und vom verwendeten Identifizierungsmittel ab. Auf Niveau „Basisregistrierung" gibt es nur das Pseudonym; auf „substanziell" und „hoch" stehen die verifizierten Personendaten zur Verfügung.
givenName urn:oid:2.5.4.42 Vorname
surname urn:oid:2.5.4.4 Nachname
email urn:oid:0.9.2342.19200300.100.1.3 E-Mail-Adresse
street urn:oid:2.5.4.18 Straße der Adresse
postcode urn:oid:2.5.4.17 Postleitzahl
city urn:oid:2.5.4.7 Ort
country urn:oid:1.2.40.0.10.2.1.1.225599 Land der Adresse
title urn:oid:0.9.2342.19200300.100.1.40 Akademischer Grad
gender urn:oid:1.3.6.1.4.1.33592.1.5.5 Geschlecht
birthdate urn:oid:1.2.40.0.10.2.1.1.55 Geburtsdatum
placeOfBirth urn:oid:1.3.6.1.5.5.7.9.2 Geburtsort
birthName urn:oid:1.2.40.0.10.2.1.1.225566 Geburtsname
nationality urn:oid:1.2.40.0.10.2.1.1.225577 Staatsangehörigkeit
phone urn:oid:2.5.4.20 Telefonnummer
extident urn:oid:1.3.6.1.4.1.25484.494450.3 bPK2 — der stabile Identifier
postkorb-handle urn:oid:2.5.4.18 Identifier für das Postfach
stork-vt urn:oid:1.2.40.0.10.2.1.1.261.94 Vertrauensniveau
Das wichtigste Attribut ist extident — das bereichsspezifische Personenkennzeichen Version 2 (bPK2). Es ist diensteanbieterspezifisch (jedes Fachverfahren bekommt für denselben Bürger eine eigene Kennung), stabil über Sessions hinweg und der korrekte Primärschlüssel in der lokalen User-Tabelle. Eine Verkettung von Aktenbeständen zweier Behörden über das bPK2 ist technisch ausgeschlossen, weil die Kennungen pro Diensteanbieter neu abgeleitet werden — das ist der Verkettungsschutz nach BSI TR-03130.
Bei eID-Authentifizierung ist das bPK2 kryptographisch an die Karte gebunden, nicht an die Person. Ein Kartentausch nach Verlust erzeugt ein neues bPK2 — das Fachverfahren braucht für solche Fälle einen Kontowiederanbindungs-Prozess, typischerweise über Aktenzeichen plus Geburtsdatum.
Anbindung in Spring Boot mit Spring Security SAML2
Spring Security 6 liefert mit dem spring-boot-starter-saml2-service-provider eine produktivfertige SP-Implementierung. Die Konfiguration hat zwei Teile: die application.yml mit der Registrierung der Föderation und ein SecurityFilterChain-Bean mit dem Attribut-Mapping.
Dependencies und application.yml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-saml2-service-provider</artifactId>
</dependency>
spring:
security:
saml2:
relyingparty:
registration:
bundid:
entity-id: https://kommune.example.de/saml
assertingparty:
# Test gegen Integration:
metadata-uri: https://int.id.bund.de/idp
# Für Produktion: https://id.bund.de/idp
signing.credentials:
- private-key-location: classpath:saml/sp-signing.key
certificate-location: classpath:saml/sp-signing.crt
decryption.credentials:
- private-key-location: classpath:saml/sp-encryption.key
certificate-location: classpath:saml/sp-encryption.crt
server:
forward-headers-strategy: framework
Die SP-Metadaten stellt Spring automatisch unter /saml2/service-provider-metadata/bundid bereit — das ist die URL, die im SSP als EntityID-Endpunkt referenziert wird. Die letzte Zeile mit forward-headers-strategy ist Pflicht hinter einem Reverse-Proxy, sonst baut Spring die AssertionConsumerServiceURL aus der lokalen Sicht statt aus der öffentlichen — und der IdP lehnt mit „Recipient mismatch" ab.
SecurityFilterChain und Attribut-Mapping
@Configuration
@EnableWebSecurity
public class BundIdSecurityConfig {
@Bean
SecurityFilterChain filter(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(a -> a
.requestMatchers("/", "/public/**").permitAll()
.requestMatchers("/antrag/schriftform/**").hasAuthority("LOA_HOCH")
.requestMatchers("/antrag/**").hasAnyAuthority("LOA_HOCH", "LOA_SUBSTANTIELL")
.anyRequest().authenticated())
.saml2Login(saml -> saml
.authenticationManager(authMgr())
.authenticationRequestResolver(akdbExtensionResolver()))
.saml2Logout(Customizer.withDefaults());
return http.build();
}
private AuthenticationManager authMgr() {
OpenSaml4AuthenticationProvider p = new OpenSaml4AuthenticationProvider();
p.setResponseAuthenticationConverter(this::convertAssertion);
return new ProviderManager(p);
}
private Saml2Authentication convertAssertion(ResponseToken token) {
Saml2Authentication base =
OpenSaml4AuthenticationProvider
.createDefaultResponseAuthenticationConverter().convert(token);
Map<String, List<Object>> attrs =
((Saml2AuthenticatedPrincipal) base.getPrincipal()).getAttributes();
String storkVt = firstString(attrs, "urn:oid:1.2.40.0.10.2.1.1.261.94");
String bpk2 = firstString(attrs, "urn:oid:1.3.6.1.4.1.25484.494450.3");
Set<GrantedAuthority> auths = new HashSet<>(base.getAuthorities());
auths.add(mapLoa(storkVt));
DefaultSaml2AuthenticatedPrincipal principal =
new DefaultSaml2AuthenticatedPrincipal(bpk2, attrs);
return new Saml2Authentication(principal,
base.getSaml2Response(), auths);
}
private GrantedAuthority mapLoa(String storkVt) {
return switch (storkVt) {
case "STORK-QAA-Level-4" -> new SimpleGrantedAuthority("LOA_HOCH");
case "STORK-QAA-Level-3" -> new SimpleGrantedAuthority("LOA_SUBSTANTIELL");
default -> new SimpleGrantedAuthority("LOA_NIEDRIG");
};
}
}
Der wichtige Punkt im Converter: der Spring-Principal-Name wird auf das bPK2 gesetzt, nicht auf die transient NameID. Damit ist der stabile Diensteanbieter-spezifische Identifier der primäre Schlüssel für die lokale User-Tabelle — Email, Name und Adresse sind nur Snapshot-Daten, die sich ändern können.
Den akdbExtensionResolver() baut man, indem man den Default-Saml2AuthenticationRequestResolver erweitert und vor dem Marshalling die AKDB-Extensions ins Extensions-Element einsetzt. Spring Security bietet dafür den Customizer-Hook im OpenSAML4-Request-Builder; konkrete Beispiele liefern die Open-Source-Adapter wie ba-itsys/keycloak-extension-bundid (ein Keycloak-Plugin, dessen Logik sich strukturell auf Spring übertragen lässt).
Anbindung testen — vor der Produktivschaltung
In der Integrationsumgebung sind die folgenden Wege zur Erzeugung von Test-Identitäten produktiv etabliert.
Selbstregistrierung mit Benutzername und Passwort. Schnellster Weg, den End-to-End-Flow auf Vertrauensniveau „Basisregistrierung" zu prüfen. Konto unter int.id.bund.de selbst anlegen, Mail-Bestätigung durchlaufen, Anmeldung im Fachverfahren auslösen — Erfolg gegeben, sobald das bPK2 im Backend ankommt.
Testausweise vom BMI. Für Tests auf Vertrauensniveau „hoch" stellt das BMI auf Anfrage physische Testausweise mit Online-Funktion zur Verfügung. Diese Ausweise sind kryptographisch echt, enthalten aber fiktive Personendaten und sind nur in der Integrationsumgebung gültig. Anforderung über das SSP-Kontaktformular, Lead-Zeit etwa eine Woche.
PersoSim und AusweisApp im Entwicklermodus. Das BSI stellt unter https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Elektronische-Identitaeten/Online-Ausweisfunktion/Testinfrastruktur/PersoSim/PersoSim_node.html einen Simulator bereit, der den Personalausweis-Chip vollständig in Software nachbildet. Zusammen mit der AusweisApp im Entwicklermodus lassen sich beliebig viele Testidentitäten anlegen — sinnvoll für Last- und Edge-Case-Tests.
BundID-Simulator. Die Bundesagentur für Arbeit hat unter github.com/ba-itsys/bundid-simulator einen fachlichen Mock veröffentlicht, der SAML-Requests annimmt und Responses nach BundID-Spezifikation zurückgibt. Spring-Boot-Anwendung mit Docker-Image (ghcr.io/ba-itsys/bundid-simulator), eingebaute Beispielliste mit zwölf Testpersonen, konfigurierbare Antworten OK / CANCEL / ERROR. Sehr nützlich für CI-Pipelines, in denen man die Integrationsumgebung nicht erreichen kann.
Postfach und Bescheidzustellung über FIT-Connect
BundID führt für jeden Nutzer ein elektronisches Postfach. Bescheide werden aber nicht vom Fachverfahren direkt zugestellt — die Zustellung läuft über FIT-Connect, den Verbindungsdienst der FITKO. Im SSP wird parallel zur Authentifizierungskomponente die Komponente Postfach beantragt, das BundID-Postfach-Zertifikat ausgestellt und dort gepflegt.
FIT-Connect besteht aus einer Submission-API, an die das Fachverfahren als Sender seinen Bescheid übergibt, und einem Zustelldienst, der die Weiterleitung an den jeweiligen Empfängerzustellpunkt übernimmt. Bei BundID-Bürgern ist das der Zustellpunkt des Postfachs, das im id.bund.de-Frontend angezeigt wird. Bescheide werden Ende-zu-Ende verschlüsselt über die FIT-Connect-Infrastruktur transportiert — der Inhalt ist als JWE gegen den öffentlichen Schlüssel des Empfängerzustellpunkts verschlüsselt und als JWS mit dem Sender-Schlüssel signiert.
Die FITKO publiziert eine Java-Client-Bibliothek, die JWE/JWS und die Submission-API ergonomisch kapselt. Der Submission-Status — übergeben, zugestellt, gelesen — kommt asynchron per Polling oder Webhook zurück. Für die Zustellfiktion (drei Tage nach Bereitstellung gilt der Bescheid analog zu § 41 VwVfG als zugegangen) muss das Fachverfahren den Bereitstellungszeitpunkt revisionssicher protokollieren — daraus wird die Widerspruchsfrist abgeleitet.
Stolperfallen aus produktiven Anbindungen
Sortiert nach Auftrittshäufigkeit — Punkte, die in fast jedem ersten Anbindungsversuch auftauchen.
Zertifikatsformat im SSP. Die Zertifikatsfelder im SSP erwarten nur den Base64-Inhalt ohne -----BEGIN CERTIFICATE----- und -----END CERTIFICATE-----. Wer den vollen PEM-Block einfügt, bekommt eine Validierungsfehlermeldung und einen verlorenen Werktag.
Metadaten-Verarbeitung im Wochentakt. Hochgeladene Metadaten werden, wie aus den Erfahrungsberichten ablesbar, üblicherweise am Dienstagnachmittag durch den Bund-Prozess verarbeitet. Wer am Mittwoch ein Update einspielt, kann sich erst am folgenden Mittwoch dagegen authentifizieren. Anbindungsplan und Upload-Zeitpunkt aufeinander abstimmen.
Zertifikat des IdP umspeichern. Wer auf einer Plattform anbindet, die das Metadata-XML nicht direkt akzeptiert (HISinOne ist das prominente Beispiel), muss das Zertifikat zwischen den <ds:X509Certificate>-Tags extrahieren, mit BEGIN/END-Header in eine neue Datei kopieren und als .crt speichern. Ein praktischer Helfer ist samltool.com/format_x509cert.php, der die Header automatisch ergänzt.
Forward-Header hinter dem Reverse-Proxy. Spring baut die AssertionConsumerServiceURL aus der lokal sichtbaren Request-URL — also http://localhost:8080/..., wenn der Reverse-Proxy nicht erkannt wird. Der IdP lehnt anschließend mit „Recipient mismatch" ab. Fix: server.forward-headers-strategy=framework setzen und sicherstellen, dass X-Forwarded-Proto und X-Forwarded-Host durchgereicht werden.
AKDB-Extensions vergessen. Seit August 2024 sind sie verpflichtend. Wer mit einem Default-Spring-Security-SAML-Resolver arbeitet, der keine Extensions injiziert, sieht in der Integrationumgebung leere Anmeldebildschirme oder eine generische Fehlermeldung. Den Resolver erweitern und die akdb:AuthenticationRequest-Struktur explizit setzen.
NameID-Modell missverstanden. Das transient NameID-Format ist kurzlebig und für jede Session neu. Wer es als Benutzerschlüssel verwendet, baut sich einen Bug, der bei der zweiten Anmeldung sichtbar wird. Stabilen Schlüssel aus extident (bPK2) ziehen.
Verwechslung mit MUK. Anträge von Selbstständigen oder Einzelunternehmern werden gelegentlich an BundID gerichtet, obwohl sie geschäftlich handeln und über das Mein Unternehmenskonto zu identifizieren wären. Eine frühe Frage im Antragsformular und die automatische Routing-Entscheidung verhindert die spätere Migration.
Ausblick — BundID neben der EUDI-Wallet
Mit der EUDI-Wallet wird 2026/2027 ein zweites Identifizierungsmittel ins Spiel kommen, das funktional mit BundID konkurriert. Die plausible Architektur ist eine, in der BundID zum Verifier gegenüber der EUDI-Wallet wird — der Bürger meldet sich bei id.bund.de an, BundID akzeptiert dafür sowohl die bisherigen Mittel (Benutzername, Elster, eID) als auch ein neues „Anmelden mit EUDI-Wallet"; die Wallet liefert das PID-Credential, BundID verifiziert es und stellt für die Fachverfahren die gewohnten Attribute zur Verfügung.
Für ein Fachverfahren ist die richtige Investition heute die saubere SAML-Anbindung an BundID mit Step-Up-Fähigkeit, bPK2-basierter Nutzerführung und FIT-Connect-Postfach. Eine parallele OID4VP-Anbindung direkt gegen die Wallet ist eine spätere Erweiterung, die sich für grenzüberschreitende Use-Cases oder Banking-/Versicherungs-Integrationen rechnet. Für rein deutsche Verwaltungsanwendungen bleibt BundID auf absehbare Zeit der primäre Einstiegspunkt.
