SSO zwischen Domino und Websphere klappt nicht: Wo anfangen zu suchen?

[Tode]

Ich versuche gerade SSO zwischen Websphere und Domino zu etablieren (für Sametime), und ich habe -denke ich- alles gemacht, wie in den Anleitungen:

Im Websphere habe ich den Key für den LTPAToken generiert und exportiert (mit allen Einstellungen, wie sie an einschlägigen Stellen beschrieben sind).
Im Domino habe ich ein LTPAToken- Dokument erstellt und den Websphere- Key importiert.

Wenn ich mich jetzt am Domino anmelde, dann wird ein LTPAToken- Cookie erstellt (und auch ein LTPAToken2- Cookie, weil ich das so konfiguriert habe).
Mit diesem kann ich mich bei allen anderen Domino- Servern mit der selben LTPAToken- Zuweisung anmelden, aber nicht beim Websphere, der diesen Schlüssel generiert hat. Wenn ich mich dort erneut anmelde, wird das Token überschrieben, und ich bin beim Domino wieder ausgelockt.

Ich hatte jetzt den Verdacht, dass der Username im Cookie nicht stimmt, und habe Code gefunden, mit dem ich das Cookie auseinandernehmen kann. Wenn ich diesem (Java)- Code das Domino- Cookie übergebe, dann bekomme ich einen sauberen Output:

Token is for: u:user\:defaultWIMFileBasedRealm/CN=Torsten Link,OU=Freiburg,O=MyCompany
Token expires at: 2015-06-16-15:39:21 CEST

Übergebe ich aber das Websphere- Cookie, dann bekomme ich die Fehlermeldung

Caught inner: javax.crypto.BadPaddingException: Given final block not properly padded

Was auffällt: Das Websphere- Cookie ist 332 Zeichen lang, das Domino- Cookie 364 Zeichen.

Da in beiden Fällen ein Token generiert wird, und ich definitiv den vom Websphere exportierten Key verwende: Was kann man sonst noch falsch machen?

Ach ja: Ich verwende natürlich in beiden Fällen die selbe Domain, sowohl beim Aufruf der Websphere- Seite als auch beim Abruf der Domino- Seite.

Zusatzinfo: Auf dem Websphere- Server gibt es mehrere Domains (domain.net und domain.com), in der Konfiguration für SSO ist aber die richtige hinterlegt.

[Tode]

Also beantworte ich mir die Frage mal selbst:
Man fängt an mit DEBUG_SSO_TRACE_LEVEL=3 auf dem Domino.
Dann sieht man Meldungen wie folgende:

11:16:26.38 AM [0388:000A-17E0] SSO API> Decrypt Websphere style Single Sign-On token (LTPA).

• != u.

Und die heisst: Websphere verwendet einen anderen Schlüssel.

Das stimmt aber definitiv nicht. Also begebe ich mich in die Tiefen der Websphere SSO- Konfiguration.
Link Nummer 1 (und die Hilfe der Console selbst sagt: Domainname muss ohne führenden Punkt angegeben werden
Link Nummer 2 besteht auf dem Punkt vor dem Domainnamen
Ausserdem steht hier, dass man "Interoperability Mode and Web inbound security attribute propagation" auf jeden Fall einschalten soll.
Link Nummer 3 stimmt dem zu, auf jeden Fall beide Optionen aktivieren, ein anderer Link (den ich jetzt nicht mehr finde) sagt aber, dass Web inbound security attribute propagation deaktiviert sein muss...

Plötzlich kommt irgendwo zur Sprache, dass man den REALM fürs Federated Repository auf den LDAP- Server setzen muss, was irgendwie komisch erscheint...

Wie auch immer: Nach mehrmaligem neuerstellen der Keys im Websphere und durchprobieren sämtlicher möglicher Kombinationen in SSO- Config und LTPAToken auf Websphere und Domino- Seite funktioniert es jetzt endlich. JIPPIEH

[oliK]

Was war denn hier jetzt genau die Lösung?

[Tode]

Das ist über zwei Jahre her... keine Ahnung mehr, welche Konstellation da am Ende genau funktioniert hat.
Ich weiß nur: Ich habe das in der Zwischenzeit mehrfach gemacht und nie mehr Probleme damit gehabt....