In diesem Artikel werde ich Ihnen erklären, wie wir für Anwendungen auf Oracle Weblogic Server von der NTLM- zur Kerberos-Autorisierung gewechselt sind, wodurch die Benutzeranmeldung vereinfacht wird, da kein Kennwort mehr eingegeben werden muss. Alle Benutzer sowie der Anwendungsserver befinden sich in derselben Domäne. Die Domänenautorisierung für Weblogic-Serveranwendungen wurde ebenfalls zuvor konfiguriert. Alle Konfigurationen wurden in WLS 12.1.2 überprüft.
Zunächst eine kleine Theorie, ganz kurz zum weiteren Verständnis des Interaktionsprozesses.
Was ist Single Sign-On?
Single Sign-On (SSO) ist ein Mechanismus, mit dem ein Benutzer durch eine Einzelbenutzerauthentifizierungsaktion auf alle Computer und Systeme zugreifen kann, auf die er zugreifen darf, ohne mehrere Kennwörter eingeben zu müssen. Zuvor eingegebene Anmeldeinformationen werden von verschiedenen Komponenten transparent wiederverwendet.
Was ist Kerberos?
Kerberos ist ein Netzwerkauthentifizierungsprotokoll, das erstmals vom Massachusetts Institute of Technology entwickelt wurde. Kerberos ist eine sichere Methode zur Authentifizierung einer Anforderung für einen Dienst im Netzwerk und bietet eine starke Authentifizierung für Client-Server-Anwendungen mithilfe der Kryptografie mit einem geheimen Schlüssel.
Was ist SPNEGO?
SPNEGO ist eine einfache und sichere GSSAPI-Verhandlungsmaschine. Dies ist eine standardisierte Schnittstelle für die Authentifizierung (z. B. JNDI für Verzeichnissuchen). Die Standardimplementierung für SPNEGO unter Windows ist Kerberos (z. B. LDAP für JNDI). Die Microsoft-Terminologie verwendet "Integrierte Windows-Authentifizierung" als Synonym für SPNEGO. Bei der integrierten Windows-Authentifizierung können Kerberos- oder NTLM-Protokolle ausgehandelt werden.
Wenn ein Server eine Anforderung von Internet Explorer (IE 6.1 oder höher) empfängt, fordert er möglicherweise den Browser auf, das SPNEGO-Protokoll zur Authentifizierung zu verwenden. Dieses Protokoll führt die Kerberos-Authentifizierung über HTTP durch und ermöglicht es Internet Explorer, delegierte Berechtigungen zu delegieren, damit sich die Webanwendung im Namen des Benutzers bei nachfolgenden Kerberized-Diensten anmelden kann.
Wenn der HTTP-Server SPNEGO ausführen möchte, gibt er eine Antwort "401 Unauthorized" auf die HTTP-Anforderung mit dem Titel "WWW-Authorization: Negotiate" zurück. Internet Explorer kontaktiert dann den Ticket Service (TGS), um ein Ticket zu erhalten. Er wählt den speziellen Namen des Serviceteilnehmers, um ein Ticket anzufordern, zum Beispiel:
HTTP/webserver@<DOMAIN NAME>
Das zurückgegebene Ticket wird dann in ein SPNEGO-Token eingeschlossen, das verschlüsselt und per HTTP-Anforderung an den Server zurückgesendet wird. Der Token wird entfaltet und das Ticket authentifiziert.
Vorteile von Kerberos
Mit Kerberos können Administratoren die NTLM-Authentifizierung deaktivieren, sobald alle Netzwerkclients Kerberos authentifizieren können. Kerberos ist flexibler und effizienter als NTLM und sicherer.
Konfigurieren Sie Kerberos-basiertes SSO in einer Weblogic Application Server-Umgebung
Interaktionsschema:
- Wenn ein registrierter Benutzer (PC) eine Ressource von Oracle WebLogic Server (WLS) anfordert, sendet er die ursprüngliche HTTP-GET-Anforderung.
- Der Oracle WebLogic Server (WLS) -Server, auf dem der SPNEGO-Tokencode ausgeführt wird, erfordert eine Authentifizierung und gibt eine Antwort mit 401 Zugriff verweigert, WWWAuthenticate: Negotiate aus.
- Ein Client (Browser auf dem PC) fordert ein Sitzungsticket von TGS / KDC (AD) an.
- TGS / KDC (AD) stellt dem Client das erforderliche Kerberos-Ticket (vorausgesetzt, der Client ist autorisiert) zur Verfügung, das in das SPNEGO-Token eingeschlossen ist.
- Der Client sendet die HTTP-GET-Anforderung erneut. + SPNEGO-Token im Berechtigungsheader aushandeln: Base64 (Token) aushandeln.
- Wenn Sie die SPNEGO-Webauthentifizierung auf dem Weblogic-Server überprüfen, wird ein HTTP-Header mit dem SPNEGO-Token angezeigt. SPNEGO überprüft das SPNEGO-Token und erhält Benutzerinformationen.
- Nachdem Weblogic Benutzerinformationen empfangen hat, überprüft es den Benutzer in Microsoft Active Directory / KDC. Nach Abschluss des Authentifizierungsprozesses führt Weblogic den entsprechenden Java-Code (Servlets, JSP, EJB usw.) aus und überprüft die Autorisierung.
- Der Oracle WebLogic Server-Token-Handler-Handlercode akzeptiert und verarbeitet das Token über die GSS-API, authentifiziert den Benutzer und antwortet mit der angeforderten URL.
Jetzt lass uns üben
1. Wir nehmen Einstellungen auf der Serverseite der Domäne des Controllers vor, auf dem die TGS / KDC-Dienste konfiguriert sind.
- Erstellen Sie einen Benutzer in Active Directory (Kennwort darf nicht ablaufen)
- Legen Sie den entsprechenden SPN für den WLS-Servernamen fest
Führen Sie die von SPN festgelegte Überprüfung durch
setspn –l HTTP_weblogic
sollte zwei Datensätze zurückgeben
Generieren Sie eine Keytab-Datei
ktpass -princ HTTP_weblogic@mycompany.com -pass PASSWORD -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -kvno 0 -out c:\krb5.keytab
Kopieren Sie diese Datei auf den WLS-Server
2. WLS-Server-Setup
- Sie müssen die Datei krb5.ini im Ordner% windir%: C: \ Windows erstellen. Diese Datei enthält Konfigurationseinstellungen für Clients, z. B. wo sich das KDC befindet. Die Datei sieht folgendermaßen aus:
[libdefaults] default_realm = <DOMAIN NAME> ticket_lifetime = 600 [realms] <DOMAIN NAME> = { kdc = <HOSTNAME OF AD/KDC> admin_server = <HOSTNAME OF AD/KDC> default_domain = <DOMAIN NAME> } [domain_realm] . <DOMAIN NAME>= <DOMAIN NAME> [appdefaults] autologin = true forward = true forwardable = true encrypt = true
- Erstellen Sie die Konfigurationsdatei krb5Login.conf:
com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; }; com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; };
Bitte beachten Sie, dass der Domainname in
Großbuchstaben geschrieben sein muss. Verwenden Sie für frühere Versionen com.sun.security.jgss.initiate in der vorherigen Konfiguration anstelle von com.sun.security.jgss.krb5.initiate.
- Die Dateien krb5Login.conf und krb5.keytab müssen sich im Stammverzeichnis des WLS-Serverdomänenverzeichnisses befinden.
- Bearbeiten der Datei setDomainEnv
Suchen Sie den Zeilensatz JAVA_OPTIONS =% JAVA_OPTIONS% und fügen Sie ihn am Ende hinzu
-Djava.security.auth.login.config=< >\krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true
- In diesem Fall ziehen wir nicht in Betracht, die WLS-Autorisierung in AD einzurichten. Wir glauben, dass dies funktioniert. Wenn Sie dieses Element malen müssen, schreiben Sie in die Kommentare.
- SPNEGO in WLS konfigurieren
Wechseln Sie dazu zur WebLogic Server-Verwaltungskonsole
Gehen Sie zum Abschnitt Sicherheitsbereiche> myrealm> Anbieter und klicken Sie auf die Schaltfläche Hinzufügen
Wählen Sie den Typ des "WebLogic Negotiate Identity Assertion Providers".
Überprüfen Sie, ob beide Parameter ausgewählt sind.
Wir drücken die Reorder-Taste und steuern die Pfeile, um die Reihenfolge der Autorisierungstypen festzulegen. An erster Stelle sollte der WebLogic Negotiate Identity Assertion-Anbieter an zweiter Stelle installiert werden. Anbieter, der die LDAP-Authentifizierung durchführt (Domänenautorisierung)
- Starten Sie den Server neu
- Als Nächstes müssen Sie der Anwendung die CLIENT-CERT-Autorisierungsmethode mitteilen. Diese Änderungen werden in der Datei web.xml der Anwendung angewendet
<security-constraint> <display-name>Security Constraint for SSO </display-name> <web-resource-collection> <web-resource-name>My webapp</web-resource-name> <description>Group of Users</description> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> <security-role> <description>Role description</description> <role-name>valid-users</role-name> </security-role>
Die Rolle muss im System vorinstalliert sein. In unserem Fall wird die integrierte Rolle für ADF (gültige Benutzer) verwendet, und basierend auf Domänengruppen werden Berechtigungen erteilt.
Um Probleme mit der Autorisierung zu identifizieren, müssen Sie das Debuggen aktivieren. Gehen Sie dazu zum Abschnitt.
Umgebung -> Server, wählen Sie unseren Server -> Debug -> Weblogic (erweitern) -> Sicherheit -> atn, aktivieren Sie das Kontrollkästchen und aktivieren Sie es.
Zum Aktivieren und Deaktivieren des Debugs ist kein Neustart erforderlich.
Melden Sie sich am Domänencomputer an, klicken Sie auf den Anwendungslink und melden Sie sich an, ohne ein Kennwort einzugeben. Es ist zu beachten, dass die Schaltfläche Beenden in der Anwendung in dieser Konfiguration nicht funktioniert.