cXML – Authentifizierung

Der Connector prüft beim Login die Identitätsdaten aus dem cXML-Header-Element. Es stehen drei unabhängige Prüfpunkte zur Verfügung — jeder kann einzeln aktiviert oder deaktiviert werden.

Die drei Prüfpunkte

FROM — Identität des Käufers

Das <From>-Element identifiziert das kaufende System (den Käufer). Der Connector vergleicht den übermittelten Wert mit einem Shopware-Feld des eingeloggten Kunden.

Feld	Beschreibung
FROM überprüfen	Aktiviert oder deaktiviert diese Prüfung
FROM-Domain	Erwarteter Domain-Wert (z.B. DUNS, NetworkId, AribaNetworkUserId)
FROM-Feld	Shopware-Feld des Kunden, gegen das verglichen wird (E-Mail, Kundennummer oder Custom Field)

Beispiel im cXML:

<From>
  <Credential domain="NetworkId">
    <Identity>AN01234567890</Identity>
  </Credential>
</From>

TO — Identität des Empfängers

Das <To>-Element adressiert den Shop. Diese Prüfung stellt sicher, dass das cXML tatsächlich für dieses System bestimmt ist.

Feld	Beschreibung
TO überprüfen	Aktiviert oder deaktiviert diese Prüfung
TO-Domain	Erwarteter Domain-Wert
TO-Feld	Shopware-Feld für den Vergleich

SENDER / Shared Secret — Passwort-Prüfung

Das <Sender>-Element enthält den technischen Absender und optional ein Shared Secret (Passwort). Die SENDER-Prüfung validiert die Identität des technischen Absenders, die Shared-Secret-Prüfung das Passwort.

Feld	Beschreibung
SENDER überprüfen	Aktiviert oder deaktiviert die SENDER-Prüfung
SENDER-Domain	Erwarteter Domain-Wert — gilt nur für die SENDER-Identitätsprüfung, nicht für das Shared Secret
Shared Secret überprüfen	Aktiviert die Passwort-Prüfung
Shared Secret	Das erwartete Passwort — aus einem Shopware-Kundenprofil oder Custom Field

Seit 3.7.400 / 3.6.200

Ist Shared Secret überprüfen aktiv, wird der Login abgelehnt, wenn das Beschaffungssystem kein <SharedSecret> sendet oder das Element leer ist. Zuvor wurde ein leeres Secret toleriert. Sendet das System kein Shared Secret, muss die Prüfung deaktiviert werden.

Seit 3.7.500 / 3.6.300

Das Shared Secret wird aus dem ersten Sender-Credential gelesen, unabhängig von dessen Domain. Bislang wurde dafür die konfigurierte SENDER-Domain herangezogen, was gültige Logins abwies, sobald das Beschaffungssystem das Secret unter einer anderen Domain sendete. Die Suche bleibt bewusst auf <Sender> beschränkt — <From> und <To> werden nicht durchsucht. Geprüft wird das Secret weiterhin.

Beispiel im cXML:

<Sender>
  <Credential domain="DUNS">
    <Identity>123456789</Identity>
    <SharedSecret>geheim</SharedSecret>
  </Credential>
  <UserAgent>Ariba 1.0</UserAgent>
</Sender>

Standardkonfiguration

info

In der Standardkonfiguration ist nur FROM aktiv. TO und SENDER sind optional und werden nur benötigt, wenn das Procurement-System entsprechende Werte sendet und eine gegenseitige Identifizierung erwartet.

Typische Minimal-Konfiguration für Ariba:

Prüfpunkt	Aktiv	Domain	Feld
FROM	✅	NetworkId	E-Mail
TO	❌	–	–
SENDER	❌	–	–
Shared Secret	❌	–	–

Häufige Probleme

Login schlägt fehl — Authentifizierungsfehler

• Stimmt die Domain (NetworkId, DUNS, o.Ä.) mit dem exakten Wert überein, den das Procurement-System sendet?
• Ist der Kunde dem System im Tab Kunden zugewiesen?
• Ist das verwendete Shopware-Feld (E-Mail, Kundennummer, Custom Field) beim Kunden gepflegt?

Shared Secret schlägt fehl

• Stimmt das Passwort exakt (Groß-/Kleinschreibung beachten)?
• Ist das Feld am Shopware-Kundenprofil korrekt hinterlegt?
• Sendet das Beschaffungssystem überhaupt ein <SharedSecret>? Seit 3.7.400 / 3.6.200 führt ein fehlendes oder leeres Secret bei aktiver Prüfung zur Ablehnung — in diesem Fall die Prüfung deaktivieren.