Problem mit Update von ApacheHttpClient von 5.2 auf 5.3

[Gelöschtes Mitglied 68249]

Wahrscheinlich ist die Lösung total einfach und ich bin zu blöde um sie zu sehen.
Im ApacheHttpClient 5.3 ist NTCredentials deprecated. Diese funktionalität habe ich aber verwendet:

private HttpClientContext buildDefaultContext() {

    AuthScope authScope = new AuthScope((SSL ? "HTTPS" : "HTTP"), SERVER, PORT, null, null);
    BasicCredentialsProvider credsProvider = new BasicCredentialsProvider();

    if(AUTH == Authorization.BASIC) {
        credsProvider.setCredentials(authScope, new UsernamePasswordCredentials(USERNAME, PASSWORD.toCharArray()));
    } else if(AUTH == Authorization.NT) {
        credsProvider.setCredentials(authScope, new NTCredentials(USERNAME, PASSWORD.toCharArray() ,null, REFSYSCONFIG.get("DOMAIN")));
    }

    HttpHost targetHost = new HttpHost((SSL ? "HTTPS" : "HTTP"), SERVER, PORT);
    AuthCache authCache = new BasicAuthCache();
    authCache.put(targetHost, new BasicScheme());

    HttpClientContext context = HttpClientContext.create();
    context.setCredentialsProvider(credsProvider);
    context.setAuthCache(authCache);
    return context;
}

In Zeile 9 baue ich für bestimmte Verbindungen einen credsProvider mit NTCredentials.
In den PatchNotes steht drin ich solle eben dafür auf Basic wechseln, aber irgendwie bin ich zu blöde das um zu setzen. Fakt ist, ohne Domäne schlägt die Anmeldung fehl.
Hatte auch schon sowas probiert:

credsProvider.setCredentials(authScope, new UsernamePasswordCredentials(USERNAME + "@" + DOMAIN, PASSWORD.toCharArray()));

ging aber leider auch nicht.

 

[KonradN]

Also die üblichen beiden Wege, die Domain beim User mit zu geben sind:
user@domain
domain\user

Ersteres hast Du bereits versucht, das zweite wäre noch denkbar und bestimmt einen Versuch wert.

 

[Gelöschtes Mitglied 68249]

Schade, Antwort ist 401 Unauthorized.

Mir fällt einfach nicht ein, wie ich das anders machen kann.

 

[Oneixee5]

ohne Domäne schlägt die Anmeldung fehl

Ja das ist richtig. Die wird benötigt, kann man aber auslesen - bei uns zumindest.
"HTTP" + Authorization.BASIC würde ich nicht tun, eher eine Exception werfen. Authorization.BASIC ist nicht sicher. Selbst die NTCredentials sollte man nicht per "HTTP" verwenden.

String UserDomainName = System.getenv("USERDOMAIN");

 

[Gelöschtes Mitglied 68249]

Die Antwort verwirrt mich. Wir haben so gut wie keine HTTP-Verbindungen mehr. In Produktion definitiv keine mehr und in den PreProd Systemen könnten auch schon alle umgestellt sein.
Die Domain bekomme ich als Parameter aus der Config, weil es nicht zwingend meine gerade verwendete Domain sein muss.
Löst aber nicht mein Problem:
Der Server hätte gerne eine Domain bei der Anmeldung und Apache schmeißt die NTCredentials aus der Version 5.3 raus. Ich bin kein Freund davon jetzt noch nicht nach einer Lösung zu suchen und wenn die 5.2 dann voller Sicherheitslücken ist, da zu stehen und unter Druck eine Lösung zu brauchen.

 

[Oneixee5]

Die Antwort verwirrt mich. Wir haben so gut wie keine HTTP-Verbindungen mehr.

Wozu dann:

SSL ? "HTTPS" : "HTTP"

Offensichtlich wird HTTP immer noch verwendet. Ansonsten hättest du es nicht im Programm.

 

[LimDul]

DOMAIN/user müsste eigentlich korrekt sein.

Wichtig ist - Domain muss komplett in Uppercase sein. Was ich gemacht habe, mir einfach mal den Source-Code angesehen:

https://android.googlesource.com/pl...src/org/apache/http/auth/NTUserPrincipal.java - Da sieht man wie das zusammengebaut wird.

 

[Gelöschtes Mitglied 68249]

@Oneixee5: HTTP wäre noch möglich

Ich habe jetzt die Zeile folgendermaßen angepasst:

} else if(AUTH == Authorization.NT) {
    // credsProvider.setCredentials(authScope, new NTCredentials(USERNAME, PASSWORD.toCharArray() ,null, config.getDomain()));
    credsProvider.setCredentials(authScope, new UsernamePasswordCredentials(config.getDomain().toUpperCase() + "/" + USERNAME, PASSWORD.toCharArray()));
}

Den Rest habe ich nicht geändert.

Leider komme ich trotzdem auf einen 401.

Muss evtl. das AuthScope noch angepasst werden?

 

[LimDul]

Hilft dir das weiter: https://stackoverflow.com/questions/77784888/apache-http-client-5-3-ntcredentials-no-longer-working?

 

[Gelöschtes Mitglied 68249]

Den hatte ich tatsächlich auch gefunden, aber wenn ich das richtig verstehe "reaktiviert" er nur die alten Funktionen, die sind aber deprecated und somit potentiell in einer der nächsten Versionen raus. Außerdem teste ich das Ganze ja aktuell in der 5.2, und wenn es da schon nicht auf andrem Wege funktioniert, dann später in der 5.3 leider auch nicht.

 

[Oneixee5]

Ich habe mich mal etwas schlau gemacht: NTCredentials ist nicht das Problem, nur die Reaktion... NTLM ist von $MS abgekündigt und wird zukünftig nicht mehr unterstützt. Ob überall in Windows weiß ich nicht, es gab wohl für das AD, Mailserver und Proxy eine Info an unseren Betrieb. NTLM gilt als nicht sicher. Du müsstest dich also in die Richtung Kerberos orientieren. Ich verwende da schon seit Jahren Waffle - damit hat man den wenigsten Ärger. In wieweit das ApacheHttpClient unterstützt weiß ich nicht. Das ist mir sowieso zu umständlich, ich nehme da lieber etwas mit höherem Abstraktions-Level.
Ich muss da auch mal ein paar Projekte nach NTLM durchschauen. Die werden immer nur selten gebraucht und sind runter gefahren. Irgend ein Admin fährt die dann für irgendwelche Wahlen hoch und dann geht der Ärger los. Patchen - immer auf den letzten Drücker. Es sind ja bald Europawahlen - da hätte ich schon mal etwas Vorsprung ...

 

[Gelöschtes Mitglied 68249]

Hi, muss das Thema wieder aufwärmen, weil ich noch immer keine Lösung habe.
Also ich hatte die Tage mal Lust meine Verwendung des Apache HTTP Client gegen die Nativen NET-Sachen von Java zu tauschen. Ich dachte mir weniger Overhead == mehr Performance.

Grundsätzlich funktioniert alles mit wirklich wenig Code, aber es hapert mal wieder an der NT Authentifizierung, da bleibt der 401 stehen. Ich habe mal SPNEGO und WAFFLE grob überflogen, das ließt sich in beiden Fällen, als wenn das eine Sache für eine Serveranwendung wäre. Ich habe aber zusätzlich ein paar kleine Standalone-Anwendungen, die einfach über den Scheduler geladen werden, also keine Session, kein angemeldeter Domänenbenutzer, nur die JVM und die Zugangsdaten aus der Config.
Ich finde außerdem für keins der Systeme mal ein How to get started um es Step by Step für mich zu probieren. Oder ich suche falsch.

Achso, der Code sieht mittlerweile so aus:

    public HttpClientIntegration(Authorization authType, RestConfigInterface config) {
        String username = config.getUser();
        String password = config.getPassword();

        this.authType = authType;

        if (authType == Authorization.BASIC) {
            this.httpClient = HttpClient.newBuilder()
                    .authenticator(new Authenticator() {
                        @Override
                        protected PasswordAuthentication getPasswordAuthentication() {
                            return new PasswordAuthentication(username, password.toCharArray());
                        }
                    })
                    .build();
            this.authValue = null;
        } else if (authType == Authorization.HEADER) {
            this.httpClient = HttpClient.newHttpClient();
            this.authValue = username; // Token is passed as username
        } else if (authType == Authorization.NT) {
            String domain = config.getDomain();
            this.httpClient = HttpClient.newBuilder()
                    .authenticator(new Authenticator() {
                        @Override
                        protected PasswordAuthentication getPasswordAuthentication() {
                            return new PasswordAuthentication(domain.toUpperCase() + "/" + username, password.toCharArray());
                        }
                    })
                    .build();
            this.authValue = null;
        } else {
            this.httpClient = HttpClient.newHttpClient();
            this.authValue = null;
        }
    }

 

[Oneixee5]

Du machst im Prinzip das Gleiche wie bei Basic, nur das du die Domain davor setzt. So funktioniert das nicht. NTLM macht schon etwas mehr.

NTLM

Die NT LAN Manager (NTLM)-Authentifizierung ist ein Abfrage/Rückmeldungsschema, das eine Variante der Digestauthentifizierung mit höherer Sicherheit darstellt. NTLM verwendet die Windows-Anmeldeinformationen, um die Abfragedaten anstelle des unverschlüsselten Benutzernamens und Kennworts zu transformieren. Die NTLM-Authentifizierung erfordert mehrere Austausche zwischen dem Client und dem Server. Der Server sowie dazwischen liegende Proxys müssen beständige Verbindungen unterstützen, um die Authentifizierung erfolgreich abzuschließen.

 

[Gelöschtes Mitglied 68249]

Gut, ich hatte gehofft, dass sie mehr macht, als nur zwei Variablen zu verketten. Allerdings waren das ja die Ansätze aller anderen.
Heute morgen hatte ich mich bestimmt eine Stunde mit dem Code vom ApacheHttpClient beschäftigt und auch da drin ist nicht viel mehr zu finden, außer dass er bei getPrincipal domain\username zurück gibt.
Also bin ich davon ausgegangen, dass beim Aufbau der Verbindung bzw. beim Negotiaten unterschiedliche Dinge passieren. Aber ich hatte gehofft, da der ApacheHttpClient an der Stelle grundsätzlich auch nicht mehr hat, als einfache Strings, dass man diese irgendwie nachbauen kann.

Aber von dir kam doch z.B. die WAFFLE-Bibliothek ins Spiel. Kann man damit evtl. etwas machen? Oder vielleicht ist mein Teller wieder zu klein: wenn Microsoft NTLM nicht sicher genug findet, was soll denn dann zukünftig die Alternative sein?

 

[Oneixee5]

Naja, dein Ziel ist etwas unverständlich. Du hast geschrieben, das du den Login nicht nur auf Servern einsetzen willst. Verwendest aber Apache HTTP Client - was kann man damit anderes ansprechen als Server?
Wenn du Waffle am Server einsetzt und der Browser der Client auf einer Windows Maschine, dann musst du Client seitig nur den Fall programmieren, das der Login abgelehnt wurde. Der Rest funktioniert out of the box.
Wenn du wirklich einen Java-Client erstellen willst, dann kannst du dir mal das hier anschauen: https://github.com/qumu/kerberos-client, oder es gibt da auch Tutorials. Oft sind die aber nicht so richtig komplett. Such am besten bei Microsoft.

wenn Microsoft NTLM nicht sicher genug findet, was soll denn dann zukünftig die Alternative sein?

Kerberos

Aber wie ich oben schon geschrieben habe:

Das ist mir sowieso zu umständlich, ich nehme da lieber etwas mit höherem Abstraktions-Level.

Es ist mir wichtiger, dass etwas fertig wird, als das ich alles selbst programmiere. Mit etwas unfertigem kann ich nichts verdienen. Notfalls muss man so eine Sache mal kaufen.

Ein privates Projekt, dass länger als ein oder zwei Monate dauert wird sowieso nie fertig. Man hat dann keine Lust mehr und die Basis ist dann schon veraltet. Es gibt dann keinen Lerneffekt mehr und wer will dann schon bei Github veröffentlichen und sagen: Sieh mal hier, ich hab was neues gebaut, dass auf einer veralteten Technologie basiert!
Geschäftlich ist das anders, da hat man mehr Ressourcen und Manpower. Da ist es schon mal möglich eine Rückstand aufzuholen und technische Schulden abzubauen.

 

[Gelöschtes Mitglied 68249]

Naja, dein Ziel ist etwas unverständlich

Das wisst ihr doch mittlerweile, dass ich irgendwie nie richtig erklären kann, was ich eigentlich will. Also im aktuellen Fall:
Ich habe ein einzelnes Java-Programm, das per Rest-Calls andere Programme fernsteuern soll. Da ich nicht für jedes andere Programm den Aufruf neu schreiben möchte habe ich eine Zentrale Klasse gebaut, die den reinen Aufruf und dessen Antwort übernehmen soll. Mir ist in dem Fall nur wichtig, was der ReturnCode war und was in der Antwort steht.
Da ApacheHttpClient keine Unterstützung mehr für NTLM anbietet und ich Kerberos auch nirgends in den Details finden konnte habe ich versucht mit der Abstraktion nach unten zu gehen. Aber, wie schon bemerkt, bringt das nichts, weil genauso schlecht.
Bei Kerberos dachte ich immer, da muss vorher ganz viel eingerichtet werden und da müssen DLLs und solche Dinge zur Verfügung gestellt werden.
Aber den Link, den du da angehangen hast, da sieht der Aufwand recht überschaubar aus. Das ist auch der Apache HTTPClient, allerdings sehe ich nicht, welche Version da verwendet worden ist, dafür kenne ich mich nicht genug mit Spring und Gradle aus.
Was für Bezahl-Lösungen gibt es denn für das Problem?