Java-Client und Kerberos/SSO - Krb5LoginModule - Tickets nicht wiederverwenden

Question

Ich verwende JMeter, der von JDK 1.8Krb5LoginModule abhängt.

Es scheint mir, dass die Krb5LoginModule eine Kerberos-Sitzung über mehrere Anfragen nicht verwalten kann. Dies führt zu einem HTTP 401 und erneutem Handshaking vor jeder Anfrage.

Ich versuche eine Produktionsumgebung zu reproduzieren, die schwerwiegende intermittierende Leistungsprobleme hat, und ich möchte die Kerberos/SSO-Authentifizierung in meine Tests aufnehmen, aber ich kann nicht wie die Windows-Clients, die meine verwenden REST-Server.

Der REST-Server stellt Daten für Hunderte von Excel-Add-In-Clients zur Verfügung, die für die Authentifizierung mit Kerberos eingerichtet sind. In den Zugriffsprotokollen sehe ich, dass jeder Client zunächst eine HTTP-Statusantwort von 401 auslöst, gefolgt von einer 200 und weiteren 200 für die Dauer der Clientaktivität.

Um Verwirrung zu vermeiden, verarbeitet der Server Kerberos Hand-Shaking und ist NICHT mit Servlet-Container-Sitzungen.

Wenn mein Test ausgeführt wird, sehe ich, dass jede Anfrage von einem 401 vom Server abgelehnt wird, Java geht zum Kerberos KDC, um ein anderes Ticket zu erhalten, und sendet es dann erneut. Während dies funktioniert, kann mein KDC-Server nicht mehr als ein paar Anfragen pro Sekunde verarbeiten und die Anfragen zeitweise abbrechen, so dass ich meinen Belastungstest nicht sehr hochfahren kann.

Warum behält Krb5LoginModule nicht das Kerberos-Ticket, das es vom KDC erhält, und die Vorabauthentifizierung für jeden Aufruf, wie Excel?

Dies ist, was ich für die Config versucht haben:

JMeter { 
    com.sun.security.auth.module.Krb5LoginModule required 
     useTicketCache=true 
     ticketCache="FILE:krb.cache" 
     useKeyTab=true 
     keyTab="FILE:krb.keytab" 
     storeKey=true 
     principal="-tsk-thing-ldap-dev@DO.AD.DUM.COM" 
     debug=true; 
}; 

Ich habe mit keytabs versucht und ohne, mit Ticket-Caching und ohne. Ich hoffe, ich mache nur die Konfiguration falsch, aber ich kann nicht sehen, wie.

Dies ist, was ich meine Vermutung bin stützen auf: Oracle: Single sign-on using Kerberos

und die API: Krb5LoginModule - Oracle JDK 1.8 API docs

Answer 1

1. Ich glaube nicht, dass Sie die Anführungszeichen um Pfade benötigen und diese FILE: Bit ist nicht ebenso erforderlich, wie:

   ticketCache=/path/to/your/krb.cache 
   

2. Warum Sie beide Ticket-Cache und keytabs verwenden, sollte man eno sein ugh (es sei denn, Sie müssen Fallback-Szenario testen)

3. Welches Betriebssystem verwenden Sie?

Ich erinnere mich an das Problem mit so etwas wie die Lösung:

com.sun.security.jgss.krb5.initiate { 
    com.sun.security.auth.module.Krb5LoginModule required 
    debug=true 
    doNotPrompt=true 
    useTicketCache=true   
}; 

und Einstellung der folgenden Registrierungsschlüssel (Windows 7)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters 
Value Name: allowtgtsessionkey 
Value Type: REG_DWORD 
Value: 0x01 (default is 0) 

Referenzen:

• JSch And Kerberos Authentication
• JGSS Troubleshooting
• Windows Authentication with Apache JMeter

Answer 2

JAA ist nicht das Ticket in den Cache gehen zu beharren, ist es nur in der Lage bereits gespeicherten Tickets zu erwerben. Mehr Infos in meiner Frage/Antwort here

Sie müssen kinit-Tool verwenden (im Paket mit Java Distribution oder dem Linux-Tool), um Tickets in eine Cache-Datei zu beharren, können Sie auch Ihre eigenen Krb5LoginManger um umschreiben auszuführen das (harte Weg).

Aber ich nehme es etwas in dem Adam-Workflow gebrochen ist, in meinem understating von GSS, für die gleiche Sitzung, Server und Client, habe immer auf das gleiche GSSContext Objekt verweisen, dass sie bei der Initialisierung erstellt.