Categories
Development Java

NTLM mit Java

Um Daten von einem bestimmten Webservice beziehen zu können, muss der Aufruf durch einen authentifizierten User erfolgen. Der Webservice steht im Intranet des Kunden und der Aufruf im Browser funktioniert ohne Authentifizierung, denn im Hintergrund wird der Windows User übermittelt.

Der Aufruf über Java funktioniert nicht, da kein User übermittelt wird.

Die Authentifizierung am Webservice erfolgt lt. Ansprechpartner durch eine Windows Authentifizierung, was technischer ausgedrückt NTLM sein sollte.

Test Projekt aufsetzen

Um den Zugang zu testen ohne dabei den ganzen Ballast der großen Anwendung mitschleppen zu müssen, wird ein neues Projekt zum Testen aufgesetzt.

Das Projekt wird auf Java 8 konfiguriert und kommt mit einer einzigen Abhängigkeit aus: Dem Apache HTTPClient 4.5

<!-- https://mvnrepository.com/artifact/org.apache.httpcomponents/httpclient -->
<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpclient</artifactId>
    <version>4.5.13</version>
</dependency>

Test 1

public static void test01() throws Exception {

  DefaultHttpClient httpclient = new DefaultHttpClient();
  httpclient.getAuthSchemes().register("ntlm", new NTLMSchemeFactory());
  httpclient.getCredentialsProvider().setCredentials(new AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT),
                                                     new NTCredentials(username, password, "", ""));
  HttpGet httpGet = new HttpGet(url);
  httpGet.addHeader("accept", "application/json;odata=verbose");
  httpGet.addHeader("content-Type", "application/json;odata=verbose");
  httpGet.getParams().setBooleanParameter(CoreProtocolPNames.USE_EXPECT_CONTINUE, false);
  // HttpResponse response = httpclient.execute(httpGet);
  // System.out.println("Responseeee" + response.getStatusLine());
  try (CloseableHttpResponse response2 = httpclient.execute(httpGet)) {
    StatusLine statusLine = response2.getStatusLine();
    System.out.println(statusLine.getStatusCode() + " " + statusLine.getReasonPhrase());
    String responseBody = EntityUtils.toString(response2.getEntity(), StandardCharsets.UTF_8);
    System.out.println("Response body: " + responseBody);
  }
}

Der Code funktioniert, wirft aber noch eine WARNING mit aus:

Mai 30, 2022 4:15:35 PM org.apache.http.client.protocol.RequestTargetAuthentication process 
WARNING: NEGOTIATE authentication error: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt))
200 OK
Response body: [{"Vkorg":"","VkorgDesc":"TEST Korea Limited"}]

Test 2

    public static void test02() throws Exception {
        PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
        cm.setMaxTotal(18);
        cm.setDefaultMaxPerRoute(6);

        RequestConfig requestConfig = RequestConfig.custom()
        .setSocketTimeout(30000)
        .setConnectTimeout(30000)
        .setTargetPreferredAuthSchemes(Arrays.asList(AuthSchemes.NTLM))
        .setProxyPreferredAuthSchemes(Arrays.asList(AuthSchemes.BASIC))
        .build();

        CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
        credentialsProvider.setCredentials(AuthScope.ANY,
                new NTCredentials(username, password, "", ""));

        // Finally we instantiate the client. Client is a thread safe object and can be used by several threads at the same time. 
        // Client can be used for several request. The life span of the client must be equal to the life span of this EJB.
        CloseableHttpClient httpclient = HttpClients.custom()
        .setConnectionManager(cm)
        .setDefaultCredentialsProvider(credentialsProvider)
        .setDefaultRequestConfig(requestConfig)
        .build();
        
        HttpGet httpGet = new HttpGet(url);            
        // HttpClientContext is not thread safe, one per request must be created.
        HttpClientContext context = HttpClientContext.create();    
        try ( CloseableHttpResponse response = httpclient.execute(httpGet, context) ) {
            StatusLine statusLine = response.getStatusLine();
            System.out.println(statusLine.getStatusCode() + " " + statusLine.getReasonPhrase());
            String responseBody = EntityUtils.toString(response.getEntity(), StandardCharsets.UTF_8);
            System.out.println("Response body: " + responseBody);
        }
    }

Der Code funktioniert und wirft keine Warnung mehr aus.

Categories
Development Linux

Reverse Proxy mit OneLogin hinter LoadBalancer

Die Version des Reverse Proxy mit OneLogin wird um einen vorgelagertem Load Balancer und einem zweiten Reverse Proxy erweitert:

Docker Compose

version: '3.8'
services:

  loadbalancer:
    build: ./loadbalancer
    hostname: loadbalancer
    volumes:
      - ${PWD}/loadbalancer/conf/loadbalancer_httpd.conf:/usr/local/apache2/conf/httpd.conf
      - ${PWD}/loadbalancer/conf/loadbalancer.conf:/usr/local/apache2/conf/loadbalancer.conf
    ports:
      - 80:80

  reverseproxy_1:
    build: ./reverseproxy
    hostname: reverseproxy_1
    volumes:
      - ./reverseproxy/public_html:/usr/local/apache2/htdocs
      - ${PWD}/reverseproxy/conf/reverseproxy_httpd.conf:/usr/local/apache2/conf/httpd.conf
      - ${PWD}/reverseproxy/conf/reverseproxy.conf:/usr/local/apache2/conf/reverseproxy.conf

  reverseproxy_2:
    build: ./reverseproxy
    hostname: reverseproxy_2
    volumes:
      - ./reverseproxy/public_html:/usr/local/apache2/htdocs
      - ${PWD}/reverseproxy/conf/reverseproxy_httpd.conf:/usr/local/apache2/conf/httpd.conf
      - ${PWD}/reverseproxy/conf/reverseproxy.conf:/usr/local/apache2/conf/reverseproxy.conf


  showheaders:
    build: ./showheaders
    hostname: showheaders     

Ich hatte zuerst versucht, den Reverse Proxy über scale zu vervielfältigen, aber das funktionierte nicht, da jeder RP den selben Hostnamen zugewiesen bekommt.
Laut Forenkommentaren soll man das Problem wohl mittels Scripte oder Docker Swarm lösen können, für dieses kleine Projekt war es hingegen völlig ausreichend, den Block für den RP zu duplizieren.

Load Balancer

Neu hinzugekommen ist der den beiden RPs vorgeschaltete Load Balancer.

Die Regel, nach der das Loadbalancing erfolgt, ist hier nicht relevant und wird nicht explizit gesetzt.

Der erste Versuch, bei dem die Anfragen abwechselnd auf den RPs verteilt werden funktioniert für die public Pages.

[...]
    <Proxy "balancer://myreverseproxy">
        BalancerMember http://reverseproxy_1:80
        BalancerMember http://reverseproxy_2:80
    </Proxy>
    
    ProxyPass /          balancer://myreverseproxy/
    ProxyPassReverse /   balancer://myreverseproxy/
[...]

Die geschützten Seiten ließen sich nicht öffnen.

Der Login bei OneLogin funktioniert, aber nicht das öffnen der Seite. Anscheinend harmoniert der OneLogin Flow nicht mit diesem Setup, es scheint so, als ob die Antwort der Anfrage von RP1 an OneLogin von RP2 erhalten wird, dieser aber nichts damit anfangen kann und eine neue Authentifizierungsanfrage an OneLogin schickt, deren Antwort wiederum von RP1 erhalten wird , dieser aber nichts damit anfangen kann und eine neue Authentifizierungsanfrage an OneLogin schickt, deren Antwort wiederum von RP2 erhalten wird , dieser aber nichts damit anfangen kann und eine neue Authentifizierungsanfrage an OneLogin schickt, deren Antwort wiederum von RP1 erhalten wird, […]

Es ist also notwendig, das wir immer auf dem selben RP landen. Das Load Balancing darf nur einmal am Anfang statt finden.

Um das zu erreichen, setzten wir einen Header, der die Route zum RP enthält und setzten die Session sticky.

[...]
    ## Header for LoadBalancer
    Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED


    #define loadbalancer for Applicationserver
    <Proxy "balancer://myreverseproxy">
        BalancerMember http://reverseproxy_1:80 route=reverseproxy_1
        BalancerMember http://reverseproxy_2:80 route=reverseproxy_2
        ProxySet stickysession=ROUTEID
    </Proxy>

    ProxyPass /          balancer://myreverseproxy/
    ProxyPassReverse /   balancer://myreverseproxy/

[...]

Test

Über die Logausgaben in dem Terminalfenster, in dem Docker Compose gestartet wurde, kann man gut nachvollziehen, welche Server aufgerufen werden:

In der ShowHeaders Anwendung können wir sehen, welche ROUTEID gesetzt wurde und über den x-forwarded-host können wir die Route nachvollziehen.

In obigem Beispiel sind wir über RP2 gekommen. Wenn wir den ROUTID Cookie auf RP1 ändern, wird die nächste Anfrage über RP1 gerouted.

GitHub

Die Dateien zu diesem Post sind im OneLogin-GitHub-Projekt unter version3 zu finden.

Getrennte Netze

Im nächsten Schritt möchte ich verschiedene Netzwerke und Server verwenden.

Der User kommt aus dem Internet und geht über den Load Balancer in die DMZ, in der er über die RPs Zugang zu den Public Servern hat und nach Authentifizierung über OneLogin (Internet) gelangt er in das Interne Netz wo er Zugang auf den ShowHeaders und die Privaten Server hat.

Vorbereitet wird auch schon die Authorisierung über die RPs und OneLogin: Falls der Benutzer die Rolle user hat, bekommt er Zugang auf den User Server, falls er die Rolle admin hat, bekommt er Zugang auf den Admin Server.

In der Docker Compose Datei werden all die Server in der Services Sektion angelegt und den jeweiligen Netzwerken zugewiesen, in der darauf folgenden Networks Sektion definiert werden:

version: '3.8'
services:

  loadbalancer:
    build: ./loadbalancer
    hostname: loadbalancer
    volumes:
      - ${PWD}/loadbalancer/conf/loadbalancer_httpd.conf:/usr/local/apache2/conf/httpd.conf
      - ${PWD}/loadbalancer/conf/loadbalancer.conf:/usr/local/apache2/conf/loadbalancer.conf
    networks:
      public_network:
      dmz_network:
    ports:
      - 80:80

  reverseproxy_1:
    build: ./reverseproxy
    hostname: reverseproxy_1
    volumes:
      - ./reverseproxy/public_html:/usr/local/apache2/htdocs
      - ${PWD}/reverseproxy/conf/reverseproxy_httpd.conf:/usr/local/apache2/conf/httpd.conf
      - ${PWD}/reverseproxy/conf/reverseproxy.conf:/usr/local/apache2/conf/reverseproxy.conf
    networks:
      dmz_network:
      private_network:

[...]

  admin: 
    image: httpd:2.4
    hostname: admin
    volumes:
      - ./admin/public_html:/usr/local/apache2/htdocs
    networks:
      private_network:

networks:
  public_network:
    external: true
  dmz_network:
    external: false
  private_network:
    external: false

Das Public Netzwerk muss angelegt werden, anschließend kann Docker Compose gestartet werden:

docker network create public_network

docker-compose up

Test

Wie zuvor: Über die Logausgaben in dem Terminalfenster, in dem Docker Compose gestartet wurde, kann man gut nachvollziehen, welche Server aufgerufen werden.

Vor dem Login werden über Load Balancer und RPs die Seiten der beiden Public Server angezeigt.

Nach dem Login werden auch die Private und ShowHeaders Seiten angezeigt.

Außerdem werden auch die Seiten der User und Admin Server angezeigt. Das sollte nur erfolgen, wenn der eingeloggte Benutzer auch die entsprechenden Rollen hat, wird aber momentan noch nicht abgefragt. Die Umsetzung wird weiter unten beschrieben, sobald ich herausgefunden habe, wie sie zu implementieren ist.

GitHub

Die Dateien zu diesem Post sind im OneLogin-GitHub-Projekt unter version4 zu finden.

Authorisierung

Der Zugang zu den Seiten der User und Admin Server soll nur mit entsprechenden Rollen erfolgen.

Die Implementierung ist noch offen.

UPDATE: Inzwischen konnte ich mit einem Experten für OneLogin sprechen und wurde aufgeklärt, dass es seitens OneLogin gar nicht vorgesehen ist, dass die Anwendungs-Rollen in OneLogin gepflegt werden.

Folglich kann keine Authorisierung durch den RP mit OneLogin erfolgen.

Categories
Development

Reverse Proxy mit rechtebasiertem Zugriff

Im letzten Post habe ich einen Reverse Proxy mit OneLogin aufgebaut.

In dem Setup hat jeder eingeloggte Benutzer Zugriff auf alle privaten Seiten.

Jetzt wird das Setup erweitert, so dass es Seiten gibt, die für eingeloggte Benutzer verfügbar sind und Seiten, die nur für Administratoren verfügbar sind.

In OneLogin gibt es, soweit ich das sehen konnte, keine einzelnen Rechte, sondern nur Rollen.

Rollen anlegen

In OneLogin zwei Rollen anlegen:

  • user
  • admin

Dazu in der OneLogin Administration auf Users -> Roles -> New Role gehen und dort die Rollen anlegen, dabei direkt der App zuweisen.

Unter Users -> Users -> User auswählen, dort unter Applications die Rollen hinzufügen:

Zu meiner Überraschung werden die Rollen von OneLogin nicht mit übergeben:

Auf Applications, Application auswählen, dort auf Access und role-specivic policy:

TBD

Das hat noch nicht weiter geholfen.

Frage auf Stack Overflow gestellt: apache – Role based authorization with mod_auth_openidc and OneLogin – Stack Overflow

UPDATE: Es geht nicht

Wie ich inzwischen erfahren durfte, ist es gar nicht in OneLogin vorgesehen, dass die Anwendungs-Rollen in OneLogin gepflegt werden.

Die Authorisierung muss also (vorerst) innerhalb der Anwendung erfolgen.

Categories
Development Linux

Reverse Proxy mit OneLogin

Im letzten Post habe ich mir OneLogin angeschaut und zwei Javascript Beispiele zum laufen gebracht.

In diesem Post möchte ich einen Reverse Proxy aufbauen, der eine öffentlich zugängliche Seite bereit stellt und eine private Seite nur für eingeloggte Mitglieder.

OneLogin

Auf der OneLogin Applications Seite sammle ich folgende Informationen ein, die später in der ReverseProxy Konfiguration benötigt werden:

  • Client ID
  • Client Secret
  • Issuer URL

Außerdem wird der Token Endpoint auf Basic gesetzt.

In der Configuration muss eine Redirect URI eingetragen werden, in diesem Fall: http://localhost/private/redirect_uri

Reverse Proxy

Den Reverse Proxy wird mit Docker aufgebaut.

Der Reverse Proxy wird eine Startseite bereit stellen und von dort auf eine öffentlich zugängliche Unterseite und einen geschützten Bereich verlinken.

In der ersten Version wird der geschützte Bereich lediglich eine weitere Unterseite sein.

In der zweiten Version wird ein weiterer geschützter Bereich mit der ShowHeaders App hinzugefügt.

GitHub

Es wird ein Projekt auf GitHub für diesen Post angelegt: DockerOneLoginApacheSample

In Eclipse habe ich zuerst das neue GitHub-Repository hinzugefügt und ausgechecked, dann händisch .project angelegt und konnte dann in Eclipse über Import das Project hinzufügen.
Fühlt sich viel zu umständlich an, aber ich muss das zum Glück nicht so oft machen, als dass ich dem jetzt weiter auf dem Grund gehen müsste, wie das besser geht.

Apache Module OpenID

Für den Apache HTTP wird mod_auth_openidc verwendet.

Docker

Es wird ein Docker Image angelegt, das wiederum über Docker-Compose gestartet wird, um Dateien des Filesystems einzubinden. Das ist für die Entwicklung leichter, am Ende könnte man natürlich alles in ein Image packen und starten.

Das Docker Image basiert auf dem offiziellen Apache HTTPD Image.
Es wird mod_auth_openidc hinzugefügt, sowie ca-certificates um eine verschlüsselte Verbindung per HTTPS zum OneLogin-Server aufbauen zu können.
Die Datei für den mod_auth_openidc muss noch an die richtige Stelle verschoben werden und ein Backup der originalen httpd.conf angelegt werden.

FROM httpd:2.4
RUN apt update && apt install -y \
	libapache2-mod-auth-openidc \
	ca-certificates
RUN cp /usr/lib/apache2/modules/mod_auth_openidc.so /usr/local/apache2/modules/
RUN mv conf/httpd.conf conf/container_httpd.conf
CMD ["httpd-foreground"]

Im Docker-Compose wird das Image gebaut und die HTML Seiten sowie Konfigurationsdateien eingebunden.

version: '3.8'
services:

  reverseproxy:
    build: ./reverseproxy
    hostname: reverseproxy
    volumes:
      - ./reverseproxy/public_html:/usr/local/apache2/htdocs
      - ${PWD}/reverseproxy/conf/reverseproxy_httpd.conf:/usr/local/apache2/conf/httpd.conf
      - ${PWD}/reverseproxy/conf/reverseproxy.conf:/usr/local/apache2/conf/reverseproxy.conf
    ports:
      - 80:80

Dabei wird die Datei reverseproxy_httpd.conf als httpd.conf eingebunden und über diese Datei wird die zuvor gesicherte, originale httpd.conf und anschließend die reverseproxy.conf geladen.
Das ist eine einfache Möglichkeit, die ursprüngliche Konfiguration zu erhalten. Für ein produktives Setup ist das vermutlich nicht die beste Wahl.

Die Variable ${PWD} ist unter Linux verfügbar, daher starte ich den Container unter Windows WSL.

Die Datei reverseproxy_httpd.conf (bzw. httpd.conf im Container) ist simpel aufgebaut und enthält nur die Includes zur ursprünglichen httpd.conf und zu unserer reverseproxy.conf:

# load original configuration first
Include conf/container_httpd.conf

# customized configuration
ServerName reverseproxy
Include conf/reverseproxy.conf

Apache HTTPD Konfiguration

Die in der OneLogin Seite eingesammelten Werte müssen entsprechend in die Konfiguration eingetragen werden.

Geschützt wird der Bereich, der unter /private liegt.

LoadModule proxy_module modules/mod_proxy.so
LoadModule xml2enc_module modules/mod_xml2enc.so
LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

LoadModule auth_openidc_module modules/mod_auth_openidc.so

<VirtualHost *:80>
    ServerAdmin deringo@github.com
    DocumentRoot "/usr/local/apache2/htdocs"
    ServerName localhost
  
    ## mod_auth_openidc
    ## https://github.com/zmartzone/mod_auth_openidc
    
    #this is required by mod_auth_openidc
    OIDCCryptoPassphrase a-random-secret-used-by-apache-oidc-and-balancer

    OIDCProviderMetadataURL https://deringo-dev.onelogin.com/oidc/2/.well-known/openid-configuration

    OIDCClientID geheim-a91c-013a-175a-02471d082b0b208817
    OIDCClientSecret wirklich-ganz-geheim
    # OIDCRedirectURI is a vanity URL that must point to a path protected by this module but must NOT point to any content
    OIDCRedirectURI http://localhost/private/redirect_uri

    # maps the email/prefered_username claim to the REMOTE_USER environment variable
    OIDCRemoteUserClaim email
    #OIDCRemoteUserClaim preferred_username

	<Location /private>
        AuthType openid-connect
        Require valid-user
    </Location>

</VirtualHost>

Befehle

Docker Container starten:

docker-compose up

In den laufenden Docker Container einloggen:

docker exec -it dockeroneloginapachesample_reverseproxy_1 bash

Im laufenden Docker Container den Apache neu durchstarten:

apachectl -t && apachectl restart

Testen

In einem neuen Browserfenster, im Inkognito Modus die Seite öffnen: http://localhost.

Der Link Index Page führt auf diese Index-Seite, der Public Page Link auf die öffentlich zugängliche Seite und Private Page auf die Seite, die nur für OneLogin User zugänglich ist.

Die Public Page:

Die Private Page führt im ersten Schritt zum OneLogin Login:

Erst nach erfolgreichem Login sehen wir die private Seite:

Reverse Proxy – mit ShowHeaders

Der Reverse Proxy schreibt einige Informationen in den Header, diese werden aber nur dem Server gesendet, der Client (zB unser Webbrowser) sieht davon nichts. Um sehen zu können, welche Informationen übermittelt werden, verwende ich eine kleine App, die nichts anderes macht, als die Header anzuzeigen, daher auch der Name ShowHeaders.

Bisher existierte noch kein Dockerfile für ShowHeaders, daher habe ich das für diesen Test entwickelt und hinzugefügt:

   FROM tomcat:8.5-jdk8-openjdk-slim
    RUN apt update && apt install -y \
        maven
    RUN git clone https://github.com/DerIngo/ShowHeaders.git
WORKDIR ShowHeaders
    RUN mvn package
WORKDIR $CATALINA_HOME
    RUN mv ShowHeaders/target/ROOT.war webapps
 EXPOSE 8080
    CMD ["catalina.sh", "run"]

ShowHeaders wird in die Docker Konfiguration mit aufgenommen:

version: '3.8'
services:

  reverseproxy:
    build: ./reverseproxy
    hostname: reverseproxy
    volumes:
      - ./reverseproxy/public_html:/usr/local/apache2/htdocs
      - ${PWD}/reverseproxy/conf/reverseproxy_httpd.conf:/usr/local/apache2/conf/httpd.conf
      - ${PWD}/reverseproxy/conf/reverseproxy.conf:/usr/local/apache2/conf/reverseproxy.conf
    ports:
      - 80:80

  showheaders:
    build: ./showheaders
    hostname: showheaders
    ports:
      - 8080:8080

Die Reverse Proxy Konfiguration erweitern:

LoadModule proxy_module modules/mod_proxy.so
LoadModule xml2enc_module modules/mod_xml2enc.so
LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

LoadModule auth_openidc_module modules/mod_auth_openidc.so

<VirtualHost *:80>
    ServerAdmin deringo@github.com
    DocumentRoot "/usr/local/apache2/htdocs"
    ServerName localhost
  
    ## mod_auth_openidc
    ## https://github.com/zmartzone/mod_auth_openidc
    
    #this is required by mod_auth_openidc
    OIDCCryptoPassphrase a-random-secret-used-by-apache-oidc-and-balancer

    OIDCProviderMetadataURL https://deringo-dev.onelogin.com/oidc/2/.well-known/openid-configuration

    OIDCClientID geheim-a91c-013a-175a-02471d082b0b208817
    OIDCClientSecret wirklich-ganz-geheim
    # OIDCRedirectURI is a vanity URL that must point to a path protected by this module but must NOT point to any content
    OIDCRedirectURI http://localhost/private/redirect_uri

    # maps the email/prefered_username claim to the REMOTE_USER environment variable
    OIDCRemoteUserClaim email
    #OIDCRemoteUserClaim preferred_username

	<Location /private>
        AuthType openid-connect
        Require valid-user
    </Location>


    # showheaders block
    ProxyPass        /showheaders   http://showheaders:8080/
    ProxyPassReverse /showheaders   http://showheaders:8080/

    <Location /showheaders>
        AuthType openid-connect
        Require valid-user
    </Location>

</VirtualHost>

Die Startseite wurde um einen Link zu ShowHeaders erweitert:

Zuerst der OneLogin Login:

Es werden alle übertragenen Header angezeigt:

Headers:

host
	showheaders:8080
upgrade-insecure-requests
	1
user-agent
	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.54 Safari/537.36
accept
	text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
sec-fetch-site
	cross-site
sec-fetch-mode
	navigate
sec-fetch-user
	?1
sec-fetch-dest
	document
sec-ch-ua
	" Not A;Brand";v="99", "Chromium";v="101", "Google Chrome";v="101"
sec-ch-ua-mobile
	?0
sec-ch-ua-platform
	"Windows"
accept-encoding
	gzip, deflate, br
accept-language
	de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
cookie
	mod_auth_openidc_session=13dc8a76-10b9-479f-94b1-53d7ddb760e2
oidc_claim_sub
	175995661
oidc_claim_email
	Max@Mustermann.de
oidc_claim_preferred_username
	Max@Mustermann.de
oidc_claim_name
	Max Mustermann
oidc_claim_nonce
	mXShr6JxWX49umdsGUDe2l1zmkB0eYs9Vx7Jm1We38Q
oidc_claim_at_hash
	RBPJPDQuzxFJUembbLFdLg
oidc_claim_sid
	24f09d55-0a19-4a15-9446-010c84ff4461
oidc_claim_aud
	22a153c0-a91c-013a-175a-02471d082b0b208817
oidc_claim_exp
	1652179601
oidc_claim_iat
	1652172401
oidc_claim_iss
	https://deringo-dev.onelogin.com/oidc/2
oidc_access_token
	eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVcIsIMtpZCI6IkpSY080bnhzNWpnYzhZZE43STJoTE80Vl9xbDFiZG9pTVhtY1lnSG00SHMifQ.eyJqdGkiOiJHWlJac0YyVVhrd0xrZEl3WGplNEoiLCJzdWIiOiIxNzU5OTU2NjEiLCJpc3MiOiJodHRwczovL2RlcmluZ28tZGV2Lm9uZWxvZ2luLmNvbS9vaWRjLzIiLCJpYXQiOjE2NTIxNzI0MDEsImV4cCI6MTY1MjE3NjAwMSwic2NvcGUiOiJvcGVuaWQiLCJhdWQiOiIyMmExNTNjMC1hOTFjLTAxM2EtMTc1YS0wMjQ3MWQwODJiMGIyMDg4MTcifQ.barxBngs7jirZS3nAsYMpsqBdwybrmuqzCtP1dTiwJxEkbQsRe77Z0xqdGRmXWG8sr6s65omAcyF8ZaacY51OMQiVmEriL9MUxBTG3Z4-noO9C0nq6wmMrwHBls5CG9BPhnoc-rWMB_fvsFELiP0WZk5FM4iV-POqUkJgCNTKLbyBjpkm4y6Q4IUBgCpqmuRCtgfq0jMDrXpxLkiKkya7UymtGref2pL6UurD5r0VLwvU75lV927SUyxCKnUIDOY7Mdv05BzBfrCg6KBibWunGuY9wh6xs9WWreBlu21JcZxdgYL8Vx_MPfXrTjfU-0sjhACaqn5h0nnCrwcLoK8Hw
oidc_access_token_expires
	1652176004
x-forwarded-for
	172.24.0.1
x-forwarded-host
	localhost
x-forwarded-server
	localhost
connection
	Keep-Alive

Auffälligkeit

Die OIDCRemoteUserClaim-Konfiguration scheint keinen Einfluss zu haben:

    # maps the email/prefered_username claim to the REMOTE_USER environment variable
    OIDCRemoteUserClaim email
    #OIDCRemoteUserClaim preferred_username

Auf der ShowHeaders-Seite werden oidc_claim_email und oidc_claim_preferred_username angezeigt. Hingegen wird keine Header REMOTE_USER angezeigt.

Das Entfernen der OIDCRemoteUserClaim-Konfiguration hat auch keinen Einfluss auf die angezeigten Header.

Anscheinend macht diese Konfiguration nicht das, was ich erwartet hatte, daher entferne ich sie wieder. Weitere Recherchen dazu sind für diesen Test nicht notwendig, daher belasse ich es dabei.

Weitere Informationen zur Konfiguration des Mod Auth OpenIDC finden sich in der kommentierten Beispielkonfiguration auf GitHub.

GitHub

Die Dateien zu diesem Post sind im OneLogin-GitHub-Projekt unter version1 und version2 zu finden.

Version1 ist ohne, Version2 ist mit ShowHeaders.