Jaspic ServerAuthModule delegiert nach JAAS Krb5LoginModule

Question

Ich muss ein angepasstes Jaspic ServerAuthModule schreiben (welches ein proprietäres Authentication Cookie zur HTTP Response UND HTTP Anfrage hinzufügen muss, um es an die Anwendungen weiterzuleiten, die auf dem App Server laufen). Die Authentifizierung muss mit Kerberos, SPNEGO erfolgen.

Der Application Server verwendet werden soll JBOSS EAP 6.4.x

ich arbeiten, um die Authentifizierung mit dem JAAS Krb5LoginModule bekommen verwaltet.

Die JBOSS EAP Standone.xml Ich benutze:

<security-domain name="host" cache-type="default"> 
    <authentication> 
     <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required"> 
      <module-option name="debug" value="true"/> 
      <module-option name="principal" value="HTTP/macbookAirRCH@EXAMPLE.COM"/> 
      <module-option name="storeKey" value="true"/> 
      <module-option name="useKeyTab" value="true"/> 
      <module-option name="doNotPrompt" value="true"/> 
      <module-option name="keyTab" value="/Users/jet/Downloads/kerberos/macbookAirRCH.keytab"/> 
     </login-module> 
    </authentication> 
    </security-domain> 
    <security-domain name="SPNEGO" cache-type="default"> 
    <authentication> 
     <login-module code="SPNEGO" flag="required"> 
      <module-option name="serverSecurityDomain" value="host"/> 
     </login-module> 
    </authentication> 
    <mapping> 
     <mapping-module code="SimpleRoles" type="role"> 
      <module-option name="user@EXAMPLE.COM" value="User,Admin"/> 
     </mapping-module> 
    </mapping> 
    </security-domain> 

Jboss-web.xml:

<jboss-web> 
    <security-domain>SPNEGO</security-domain> 
    <valve> 
     <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> 
    </valve> 
    <context-root>kerberosREST</context-root> 
</jboss-web> 

Ich schaffte es auch ein individuelles Jäspi Modul zum Laufen zu bringen (extends org.jboss.as.web.security.jaspi.modules.WebServerAuthModule) unter Verwendung der folgenden Konfiguration:

<security-domain name="testDomain" cache-type="default"> 
    <authentication-jaspi> 
     <login-module-stack name="lm-stack"> 
     <login-module code="SPNEGO" flag="required"> 
      <module-option name="serverSecurityDomain" value="host"/> 
     </login-module> 
     </login-module-stack> 
     <auth-module code="ch.test.jaspic.CustomServerAuthModule" flag="required" login-module-stack-ref="lm-stack"/> 
    </authentication-jaspi> 
     <mapping> 
      <mapping-module code="SimpleRoles" type="role"> 
      <module-option name="user@EXAMPLE.COM" value="User,Admin"/> 
      </mapping-module> 
      </mapping> 
</security-domain> 

Jboss-web.xml:

<jboss-web> 
    <security-domain>testDomain</security-domain> 
    <valve> 
     <class-name>org.jboss.as.web.security.jaspi.WebJASPIAuthenticator</class-name> 
    </valve> 
    <context-root>kerberosREST</context-root> 
</jboss-web> 

Wie kann ich die Standard-JAAS Krb5LoginModule verwenden?

Sollte ich die beiden Ventile in die jboss-web.xml aufnehmen? (Die Reihenfolge ist wichtig)

Jboss-web.xml:

<jboss-web> 
    <security-domain>testDomain</security-domain> 
    <valve> 
     <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> 
    </valve> 
    <valve> 
     <class-name>org.jboss.as.web.security.jaspi.WebJASPIAuthenticator</class-name> 
    </valve> 
    <context-root>kerberosREST</context-root> 
</jboss-web> 

Vielen Dank im Voraus

Answer 1

Der Application Server verwendet werden soll JBOSS EAP 6.4.x

Leider ist JASPIC auf dieser Version von JBoss nicht sehr gut implementiert. JBoss EAP 7 wird in Ordnung sein und sollte dieses Jahr oder vielleicht Anfang nächsten Jahres veröffentlicht werden (wenn alles gut geht) (aber niemand weiß, nicht einmal die Leute bei JBoss). Es gibt mehrere Betas von EAP 7, das neueste heißt JBoss WildFly 10 und ein etwas früheres heißt EAP 7 Beta 1.

Im Allgemeinen gibt es eine JAAS Bridge, wo Sie Ihren JASPIC SAM Ihr JAAS Login Modul anrufen lassen können . Sie müssen verstehen, dass ein JASPIC SAM der Authentifizierungsmechanismus ist und das JAAS Login Modul der Identitätsspeicher ist.

Ich bin mir ziemlich sicher, dass Sie nicht benötigen die JBoss spezifische Konfiguration des JAAS Login Modul. Dies ist nur erforderlich, damit der interne JBoss-Code (z. B. ihre Implementierung des Servlet-FORM-Authentifizierungsmechanismus) dieses Modul findet.

Wenn JASPIC verwendet wird, hat das SAM die Kontrolle.

Für die Brücke Profil finden Sie in diesen Artikel für weitere Informationen:

https://blogs.oracle.com/nasradu8/entry/loginmodule_bridge_profile_jaspic_in

Answer 2

Zu meinem (wenig) Verständnis, Valve s ist, grob gesagt, eine niedrigere Ebene, Container spezifisch und Container- breites Servlet Filter Gegenstück. Daher sollte das, was Sie versuchen zu tun, in der Tat mit der Pipeline (Valve Sequenz) in Ihrer Frage vorgestellt werden. Wenn NegotiationAuthenticator die eigentliche Authentifizierung abgeschlossen ist, WebJASPIAuthenticator --die ServerAuthModule (SAM) zu, indem sie es letztlich delegiert - würde prüfen, ob ein authentifizierter AnruferKrb5Principal (oder was auch immer Principal JBoss wickelt es mit) wurde mit der Anforderung zugeordnet ist von der ehemaligen und setzen Sie die Cookies entsprechend.

Ich frage mich, warum Sie sogar JASPIC nur für das Setzen von Cookies verwenden, wenn Sie stattdessen einfach eine einfache Filter verwenden können (und einige dieser JBoss-spezifischen Konfiguration als Bonus loswerden). Oder Sie könnten alternativ dazu, wenn Sie bereit wären, jegliche Spuren der Portabilität des Authentifizierungsmechanismus aufzugeben, versuchen, NegotiationAuthenticator zu verlängern, seine authenticate(...) Methode zu umgehen und die Cookies von dort abhängig vom Ergebnis einer Delegierung an die überschriebene Implementierung zu setzen.

Und schließlich gibt es den richtigen (wenn auch härteren) herstellerneutralen Ansatz, wo Sie NegotiationAuthenticator fallen lassen und seine Funktionalität als SAM neu implementieren. Wer weiß - ein Open-Source-SPNEGO-SAM könnte sogar irgendwo da draußen existieren. Für die Kerberos-Authentifizierung können Sie das vorhandene Krb5LoginModule verwenden, indem Sie es delegieren - wie dexter meyers wrote - gemäß JASPIC LoginModule Bridge Profil (Kapitel 6 der Spezifikation). LoginModule s (LMs) sollen natürlich nicht direkt verwendet werden, sondern über LoginContext s, die wiederum einige Configuration brauchen, um das richtige LM durch zu finden und mit zu initialisieren. Ob Sie JBoss's Configuration wiederverwenden (und deshalb das entsprechende proprietäre XML beibehalten), stellen Sie Ihre eigene beständige Darstellung zur Verfügung, oder kodieren Sie es einfach in einem benutzerdefinierten LoginContext/Configuration ist Ihre Wahl.

_{Im Idealfall würden Sie den LM auch vielleicht in einem zweiten SAM, orchestriert Anrufe an die zwei von einer separaten ServerAuthContext neu implementieren. Dies würde die proprietäre Konfiguration im Zusammenhang mit der Authentifizierung auf Kosten der zusätzlichen Komplexität und des zu wartenden Codes auf Null reduzieren.}