Categories
Development Linux

Man In The Middle (ZScaler)

Version 2 aus dem Beispiel Reverse Proxy mit OneLogin soll zu Testzwecken in der Cloud zum Laufen gebracht werden.

Bei dem PoC handelt es sich um einen Apache HTTP-Server mit simpler Public Page und OneLogin Authentifizierung für den Zugriff auf die Private Page: der ShowHeaders Anwendung in einem Apache Tomcat-Server. Beide Server laufen in Docker Containern, die über Docker Compose gestartet werden.

Cloud Server einrichten

Auf dem Server muss Docker etc. eingerichtet werden:

sudo su

yum install docker -y
systemctl umask docker
systemctl start docker
docker version

curl -L https://github.com/docker/compose/releases/download/v2.2.3/docker-compose-`uname -s`-`uname -m` -o /usr/bin/docker-compose
chmod +x /usr/bin/docker-compose
docker-compose --version
# # Output:
# Docker Compose version v2.2.3

yum install git -y
mkdir /app
cd /app
git clone https://github.com/DerIngo/DockerOneLoginApacheSample.git

vim /app/DockerOneLoginApacheSample/version2/reverseproxy/conf/reverseproxy.conf

Fehler

Auf dem lokalen Entwicklerlaptop läuft der PoC und entsprechend soll er auch in der Cloud gestartet werden:

sudo su
cd /app/DockerOneLoginApacheSample/version2
docker-compose up

Zuerst sieht alles wie gewohnt aus, bis Maven ShowHeaders bauen soll:

root@showheaders:/usr/local/tomcat/ShowHeaders# mvn package
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------< deringo:ShowHeaders >-------------------------
[INFO] Building ShowHeaders 0.0.1-SNAPSHOT
[INFO] --------------------------------[ war ]---------------------------------
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/tomcat/tomcat-catalina/8.5.53/tomcat-catalina-8.5.53.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.956 s
[INFO] Finished at: 2022-06-07T12:28:46Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project ShowHeaders: Could not resolve dependencies for project deringo:ShowHeaders:war:0.0.1-SNAPSHOT: Failed to collect dependencies at org.apache.tomcat:tomcat-catalina:jar:8.5.53: Failed to read artifact descriptor for org.apache.tomcat:tomcat-catalina:jar:8.5.53: Could not transfer artifact org.apache.tomcat:tomcat-catalina:pom:8.5.53 from/to central (https://repo.maven.apache.org/maven2): Transfer failed for https://repo.maven.apache.org/maven2/org/apache/tomcat/tomcat-catalina/8.5.53/tomcat-catalina-8.5.53.pom: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Es kann eine Dependency nicht aufgelöst werden und im Text findet sich dieser Satz: "PKIX path building failed". Also irgendwas mit Zertifikaten, wie mir die Erfahrung sagt.

Nach einer Recherche ist klar: In dem Cloud Setup wird der ausgehende Traffic durch einen Proxy geleitet und dessen Zertifikate sind nicht in den Standard-Zertifikaten enthalten.

Simple Lösung: Validierung aushebeln

Die schnellste Lösung: Einfach auf jedwede Validierung verzichten.

Aus Stackoverflow:

You can disable SSL certificate checking by adding one or more of these command line parameters:

  • -Dmaven.wagon.http.ssl.insecure=true - enable use of relaxed SSL check for user generated certificates.
  • -Dmaven.wagon.http.ssl.allowall=true - enable match of the server's X.509 certificate with hostname. If disabled, a browser like check will be used.
  • -Dmaven.wagon.http.ssl.ignore.validity.dates=true - ignore issues with certificate dates.

Official documentation: http://maven.apache.org/wagon/wagon-providers/wagon-http/

Here's the oneliner for an easy copy-and-paste:

-Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true -Dmaven.wagon.http.ssl.ignore.validity.dates=true

Umsetzung

In dem Dockerfile von ShowHeaders wird der Maven Aufruf um obige Parameter ergänzt:

WORKDIR ShowHeaders
# aus
    RUN mvn package
# wird
    RUN mvn package -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true -Dmaven.wagon.http.ssl.ignore.validity.dates=true

und schon kann das Image wieder erfolgreich gebaut werden.

Der gleiche Fehler

Die Images werden gebaut, die Container starten und die Public Page wird korrekt angezeigt auf http://localhost:80/public

Aber: die Private Page auf http://localhost:80/private wird nicht angezeigt, bzw. wird nicht mal das OneLogin Login angezeigt.

Das Problem findet sich in der OpenID Konfiguration für OneLogin:

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

Per HTTPS soll die Außenwelt erreicht werden, doch auch hier ist wieder der Proxy dazwischen.

Der Aufruf mittels http wird direkt auf https umgeleitet.

Die Validierung kann hier nicht so einfach ausgehebelt werden, falls überhaupt.

Lösung: Zertifikat(e) hinzufügen

Lösungsansatz: Zertifikatskette herunterladen und dem Truststore hinzufügen.

Der erste Ansatz, wie an die Zertifikate gelangt werden kann fand sich auf StackExchange:

openssl s_client -showcerts -servername deringo-dev.onelogin.com -connect deringo-dev.onelogin.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > mycert.pem

Das funktioniert prinzipiell, dauert aber sehr lange. Außerdem wird in einem ausführlichen Kommentar darauf hingewiesen, dass die Intermediate Certificates so nicht gezogen würden.

Eine ausführliche Anleitung findet sich auf Baeldung, deren Ansatz ist wesentlich schneller (von mir nicht auf Intermediate C. getestet):

openssl s_client -connect deringo-dev.onelogin.com:443 -showcerts </dev/null | openssl x509 -outform pem > mycert.pem

Den Inhalt der heruntergeladenen Zertifikatsdatei in Plain Text anzeigen lassen:

openssl x509 -in mycert.pem -noout -text

Auf der Seite sind noch viele weitere Beispiele.

Die Zertifikate importieren:

cp mycert.pem /usr/local/share/ca-certificates/mycert.crt
update-ca-certificates

Umsetzung

Das Dockerfile des Reverse Proxies:

FROM httpd:2.4
RUN apt update && apt install -y \
        libapache2-mod-auth-openidc \
        ca-certificates
RUN openssl s_client -connect deringo-dev.onelogin.com:443 -showcerts </dev/null | openssl x509 -outform pem > mycert.pem && \
    cp mycert.pem /usr/local/share/ca-certificates/mycert.crt && \
    update-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"]

Anschließend das Image neu bauen:

docker-compose build reverseproxy

Test

Leider kann momentan nur auf der Konsole getestet werden:

curl localhost/private/

Aber der Docker Output sieht nicht gut aus: "SSL certificate problem: unable to get local issuer certificate":

version2-reverseproxy-1  | [Tue Jun 07 13:48:25.115383 2022] [auth_openidc:error] [pid 9:tid 140428228966144] [client 172.21.0.1:57644] oidc_util_http_call: curl_easy_perform() failed on: https://deringo-dev.onelogin.com/oidc/2/.well-known/openid-configuration (SSL certificate problem: unable to get local issuer certificate)
version2-reverseproxy-1  | [Tue Jun 07 13:48:25.115513 2022] [auth_openidc:error] [pid 9:tid 140428228966144] [client 172.21.0.1:57644] oidc_provider_static_config: could not retrieve metadata from url: https://deringo-dev.onelogin.com/oidc/2/.well-known/openid-configurationversion2-reverseproxy-1  | 172.21.0.1 - - [07/Jun/2022:13:48:25 +0000] "GET /private/ HTTP/1.1" 500 531
version2-reverseproxy-1  | 172.21.0.1 - - [07/Jun/2022:13:48:27 +0000] "GET /private/ HTTP/1.1" 302 478

Allerdings, nach einem Neustart sieht es doch gut aus in der Konsole:

 curl localhost/private/
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1><p>The document has moved <a href="https://deringo-dev.onelogin.com/oidc/2/auth?response_type=code&amp;scope=openid&amp;client_id=781a5c80-a77f-013a-c94a-020f214c554637671&amp;state=4RRlolG4XrN45Q3yCOc15Hf_6Ns&amp;redirect_uri=http%%3A%%2F%%2Flocalhost%%2Fprivate%%2Fredirect_uri&amp;nonce=B-PSe0ZSm6ZIoHebvpVtNQnv_JHqQLeSMpkI5tuoEi0">here</a>.</p>
</body></html>

Anschließend wieder gestoppt, Reverse Proxy Image neu bauen lassen, Container wieder gestartet: Beim ersten curl kommt der "SSL certificate problem: unable to get local issuer certificate"-Fehler, bei weiteren curls der "The document has moved"-Hinweis.

Schauen wir mal, wie das im Container aussieht:

Vorbereitung:

# frisch starten:
docker-compose down -v
docker-compose build reverseproxy
docker-compose up
# vor dem ersten Aufruf: Ab in den Container:
docker exec -it version2-reverseproxy-1 bash

Im Container:

# Im Container:
apt install curl

# 1. Aufruf
curl https://deringo-dev.onelogin.com/oidc/2/.well-known/openid-configuration
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

# 2. Aufruf
curl https://deringo-dev.onelogin.com/oidc/2/.well-known/openid-configuration
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

# 3. Aufruf
curl https://deringo-dev.onelogin.com/oidc/2/.well-known/openid-configuration
{"acr_values_supported":["onelogin:nist:level:1:re-auth"],"authorization_endpoint":"https://deringo-dev.onelogin.com/oidc/2/auth","claims_parameter_suppor[...]

Ich habe es noch ein paar mal ausprobiert, ungefähr jedes zweite bis dritte Mal hat es funktioniert.

Offensichtlich ist da noch ein LoadBalancer zwischen. 🤦‍♂️🤦‍♂️🤦‍♂️

Recherche

Im Container:

apt install iputils-ping

ping deringo-dev.onelogin.com

Mehrmaliges pingen gab zwei verschiedene IPs zurück.

apt install nmap

nmap deringo-dev.onelogin.com
Starting Nmap 7.80 ( https://nmap.org ) at 2022-06-07 14:18 UTC
Nmap scan report for deringo-dev.onelogin.com (52.29.255.229)
Host is up (0.0052s latency).
Other addresses for deringo-dev.onelogin.com (not scanned): 52.29.255.230
rDNS record for 52.29.255.229: ec2-52-29-255-229.eu-central-1.compute.amazonaws.com
Not shown: 994 filtered ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
443/tcp  open  https
554/tcp  open  rtsp
1723/tcp open  pptp

Aha! Es gibt zwei IPs zu dem Domainnamen und anscheinend ist OneLogin in den AWS.

Nochmal ein anderer Test; Wie ist das denn, wenn ich nicht im Container, sondern direkt vom Host curle:

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

Und siehe da: Auf dem Host funktioniert jeder Aufruf!

Mal schauen, ob wir die Certs finden:

locate *.crt
unter Anderen:
/etc/pki/ca-trust/source/anchors/ZscalerCloudChain.crt

Ab in den Container damit:

docker cp /etc/pki/ca-trust/source/anchors/ZscalerCloudChain.crt version2-reverseproxy-1:/tmp

im Container hinzufügen & testen:

cp /tmp/ZscalerCloudChain.crt /usr/local/share/ca-certificates/ZscalerCloudChain.crt
update-ca-certificates

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

Jeder Aufruf funktioniert, diesmal sieht es wirklich gut aus.

Umsetzung

Das Dockerfile des Reverse Proxies:

FROM httpd:2.4
RUN apt update && apt install -y \
        libapache2-mod-auth-openidc \
        ca-certificates
COPY /etc/pki/ca-trust/source/anchors/ZscalerCloudChain.crt /usr/local/share/ca-certificates/ZscalerCloudChain.crt
RUN update-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"]

Anschließend das Image neu bauen:

docker-compose build reverseproxy

Ich fasse es nicht:

Step 3/6 : COPY /etc/pki/ca-trust/source/anchors/ZscalerCloudChain.crt /usr/local/share/ca-certificates/ZscalerCloudChain.crt
1 error occurred:
        * Status: COPY failed: file not found in build context or excluded by .dockerignore: stat etc/pki/ca-trust/source/anchors/ZscalerCloudChain.crt: filedoes not exist, Code: 1

"you can only use files in your Dockerfile that are within the build context. Usually, this is ., so the Dockerfile's directory. " Copy file with absolute path to Docker Container using a Dockerfile - Stack Overflow

Nächster Versuch:

FROM httpd:2.4
RUN apt update && apt install -y \
        libapache2-mod-auth-openidc \
        ca-certificates
COPY ./ZscalerCloudChain.crt /usr/local/share/ca-certificates/ZscalerCloudChain.crt
RUN update-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"]
cp /etc/pki/ca-trust/source/anchors/ZscalerCloudChain.crt /app/DockerOneLoginApacheSample/version2/reverseproxy/ZscalerCloudChain.crt
docker-compose build reverseproxy
docker-compose up

Test

curl localhost/private/

Keine Fehler im Log! 🎉

Test im Browser mit Login

Steht noch aus, aktuell ist der Server nur über Console zu erreichen.

UPDATE: Inzwischen wurde der Zugriff per Browser auf den Server freigeschaltet (bzw. eine fehlerhafte Netzwerkkonfiguration gefixt) und die Public Seiten sind zugänglich.

Bei Aufruf der Private Seiten kommt allerdings eine Fehlermeldung:

Die Lösung wird im nächsten Post erarbeitet.

Categories
Development Java

OneLogin AccessFilter

Wir wollen unsere Anwendung durch einen Filter schützen, der nur Anfragen von eingeloggten Benutzern mit der richtigen Rolle hindurch lässt.

Für diesen PoC bauen wir einen Reverse Proxy für den Login und einen Anwendungsserver für den Filter. Der Anwendungsserver bekommt einen Zugang über den RP und einen Zugang ohne RP, um so zu zeigen, dass nur über den RP auf die Anwendung zugegriffen werden kann.

In produktiven Umgebungen darf es den Zugang ohne RP so ungeschützt nicht geben, da es sehr einfach ist, zB über ein Browser-Plugin, den RP mittels selbstgesetzter Header zu faken.

Reverse Proxy

Der Reverse Proxy bekommt grundsätzlich die gleiche Konfiguration wie in den Beispielen zuvor.

Hier müssen wir aber noch den Scope params hinzufügen, um so die OneLogin-Rollen des Benutzers zu übertragen:

## OIDCScope params
## to put params including roles into header
OIDCScope "openid email profile groups params"

Im Header sieht das dann beispielsweise so aus:

oidc_claim_params
	{"post_logout_redirect_uri": "http://localhost", "roles": "user;admin"}

ACHTUNG

Das die Rollen als Parameter übertragen werden, funktioniert nur, wenn man explizit angibt, dass diese als Parameter übergeben werden sollen!

Dazu muss die Application in OneLogin entsprechend konfiguriert werden:

Applications -> Applications -> select Application -> Parameters -> "+"-Button:

Im nächsten Fenster des Dialoges die Value ("User Roles") setzen:

Access Filter

Der Access Filter prüft, ob eine UserID vorhanden ist. Das ist in unserem Beispiel die Email, es könnte aber auch der Preferred Username genommen werden.

Des weiteren prüft der Access Filter, ob der Benutzer die erforderliche Rolle user hat.

Sind beide Bedingungen erfüllt, kann auf die Anwendung zugegriffen werden, ansonsten wird lediglich "Access denied" angezeigt.

package deringo.oneloginjavaappsample;

import java.io.IOException;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;

import org.apache.commons.lang3.StringUtils;
import org.json.JSONObject;


@WebFilter("/*")
public class AccessFilter implements Filter {

	@Override
	public void init(FilterConfig filterConfig) throws ServletException {
		System.out.println("AccessFilter init");
	}

	@Override
	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
			throws IOException, ServletException {
		System.out.println("AccessFilter doFilter");
		
		HttpServletRequest httpRequest = (HttpServletRequest) request;
		
		String oidc_claim_email = httpRequest.getHeader("oidc_claim_email");
		String oidc_claim_preferred_username = httpRequest.getHeader("oidc_claim_preferred_username");
		String userid = oidc_claim_email;
		
		String oidc_claim_params = httpRequest.getHeader("oidc_claim_params");
		List<String> roles = getRoles(oidc_claim_params);
		boolean hasRequiredRole = roles.contains("user");
		
		if (!StringUtils.isBlank(userid) && hasRequiredRole) {
			// Grant access
			chain.doFilter(request, response);
		} else {
			response.getWriter().println("Access denied");
			response.getWriter().close();
		}
	}

	@Override
	public void destroy() {
		System.out.println("AccessFilter destroy");
	}

	private static List<String> getRoles(String oidc_claim_params) {
		List<String> rolesList = new ArrayList<>();
		try {
			JSONObject o = new JSONObject(oidc_claim_params);
			String rolesS = o.get("roles").toString();
			String[] roles = StringUtils.split(rolesS, ";");
			rolesList = Arrays.asList(roles);
		} catch (Exception e) {
			e.printStackTrace();
		}
		return rolesList;
	}
}

Docker

Über Docker Compose werden beide Server gestartet.

Über Port 80 ist der Reverse Proxy erreichbar, über Port 8080 direkt der Anwendungsserver.

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
      
   sampleapp:
      build: ./oneloginjavaappsample
      hostname: sampleapp
      ports:
        - 8080:8080

Im Docker File des Anwendungsservers kopieren wir erst nur das Maven POM, lassen dann Maven bauen, um so die Abhängigkeiten herunterzuladen. Erst danach kopieren wir das gesamte Projekt in den Container und lassen die Anwendung bauen. So wird nach Code Änderungen, ohne Anpassungen in Maven, der Bau des Images beschleunigt, da nicht jedes Mal die Bibliotheken heruntergeladen werden müssen.

   FROM tomcat:8.5-jdk8-openjdk-slim
    RUN apt update && apt install -y \
        maven
   COPY pom.xml /app/pom.xml
WORKDIR /app
    RUN mvn package
   COPY . /app
    RUN mvn package
WORKDIR $CATALINA_HOME
    RUN mv /app/target/ROOT.war webapps
 EXPOSE 8080
    CMD ["catalina.sh", "run"]

Test

Zugriff auf den Anwendungsserver über den Reverse Proxy nach Anmeldung:

http://localhost/private/test.html

Direkter Zugriff auf den Anwendungsserver ohne Anmeldung:

http://localhost:8080/index.html

GitHub

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

Categories
Development Java

OneLogin API-Zugriff mit Java

Im vorherigen Post haben wir gesehen, dass ein neuer Benutzer sich selbst registrieren kann, aber um den Zugang zur Anwendung zu erhalten, er noch durch einen User-Admin freigeschaltet/der Anwendung hinzugefügt werden muss.

Das Hinzufügen des Benutzers erfolgt in OneLogin, so dass der User-Admin auch in diesem Tool geschult werden müsste.

Um den Schulungsaufwand zu vermeiden und ein flüssigeres Arbeiten, ohne Wechsel der Anwendungen, zu ermöglichen, wollen wir einige Funktionalität von OneLogin in unserer Anwendung ermöglichen. Dazu gibt es in OneLogin eine API-Schnittstelle, die wir mit einem Java-Client ansteuern werden.

Der Java-Client logt sich einmalig mit Client ID und Secret (API Credentials! siehe unten) ein und erhält so ein Access Token, mit dem die weiteren API-Funktionen ausgeführt werden können.

Die API-Dokumentation, für Version 2, findet sich hier: https://developers.onelogin.com/api-docs/2/getting-started/dev-overview

Vorbereitung / Daten sammeln

API-Subdomain

Die API-Domain des Testprojekt ist: deringo-dev.onelogin.com

Die API-Sub-Domain lautet foglich: deringo-dev

API ID & Secret

Für die Benutzung der API wird Client ID und Client Secret benötigt. Das kennen wir schon aus einem vorherigen Post zu OneLogin:

Für den Zugriff über die API benötigen wir aber ein anderes Client ID & Secret Paar! Dieses findet sich in dem Developers-Tab unter API Credentials.

Dort ist ein entsprechender Zugang einzurichten, für das Test-Projekt haben wir mit Manage All eingerichtet:

OneLogin App ID

Die ID unserer Test-Anwendung findet sich in der URL nachdem man auf Applications -> Applications die App auswählt, in unserem Beispiel "1739301":

Java Programm aufsetzen

Abhängigkeiten

Das Projekt wird für Java 8 aufgesetzt und benötigt Apache HttpClient 4.5 und Json:

<properties>
  <maven.compiler.source>8</maven.compiler.source>
  <maven.compiler.target>8</maven.compiler.target>
</properties>

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

Programm Rumpf

Zum Testen der API-Funktionen wird eine Test-Klasse mit den oben gesammelten Informationen angelegt und dann jeweils eine eigene Methode in der Klasse verwendet.

public class TestMain {

	private static final String ONELOGIN_SUBDOMAIN = "deringo-dev";
	
	// OneLogin Administration -> Applications -> select Application, get ID from URL
	private static final String ONELOGIN_APP_ID = "1739301";
	
	// OneLogin Administration -> Developers -> API Credentials
	private static final String ONELOGIN_CLIENT_ID = "12345<geheim>67890";
	private static final String ONELOGIN_CLIENT_SECRET = "12345<geheim>67890";
	
	
	public static void main(String[] args) {
		TestMain main = new TestMain();

		main.sayHello();
	}

	private void sayHello() {
		System.out.println("Hello World!");
	}
}

Access Token

Für die API Calls wird ein Access Token benötigt, wie dieser zu bekommen ist ist hier beschrieben: Generate OAuth 2.0 Tokens v2| OneLogin Developers

private String getAccessToken() {

  CloseableHttpClient client = HttpClientBuilder.create().build();

  HttpPost request = new HttpPost(String.format("https://%%s.onelogin.com/auth/oauth2/v2/token", ONELOGIN_SUBDOMAIN));

  String credentials = String.format("%%s:%%s", ONELOGIN_CLIENT_ID, ONELOGIN_CLIENT_SECRET);
  byte[] encodedAuth = Base64.getEncoder().encode(credentials.getBytes());
  String authHeader = "Basic " + new String(encodedAuth);

  request.setHeader("Authorization", authHeader);
  request.addHeader("Content-Type", "application/json");
  request.setEntity(new StringEntity("{ \"grant_type\": \"client_credentials\" }", "UTF-8"));

  try {
    CloseableHttpResponse reponse = client.execute(request);

    String content = EntityUtils.toString(reponse.getEntity());

    JSONObject json = new JSONObject(content);

    String accessToken = json.getString("access_token");
    return accessToken;

  } catch (IOException e) {
    e.printStackTrace();
    return null;
  }
}

List App Users

Use this API to return a list of users that are assigned to an App.

Doku: List App Users - OneLogin API

Sample Code:

private void listAppUsers() {
  String resourceURL = String.format("https://%%s.onelogin.com/api/2/apps/%%s/users", ONELOGIN_SUBDOMAIN, ONELOGIN_APP_ID);

  CloseableHttpClient client = HttpClientBuilder.create().build();

  HttpGet request = new HttpGet(resourceURL);
  request.setHeader("Authorization", "bearer " + getAccessToken());
  request.addHeader("Content-Type", "application/json");

  try {
    CloseableHttpResponse reponse = client.execute(request);

    String content = EntityUtils.toString(reponse.getEntity());

    JSONArray jsonArray = new JSONArray(content);
    jsonArray.forEach(o -> System.out.println(o));

  } catch (IOException e) {
    e.printStackTrace();
  }
}

List Roles

Use this API to return a list of roles.
This endpoint supports pagination and sorting.

Doku: List Roles (onelogin.com)

private void listRoles() {
  String resourceURL = String.format("https://%%s.onelogin.com/api/2/roles", ONELOGIN_SUBDOMAIN);

  CloseableHttpClient client = HttpClientBuilder.create().build();

  HttpGet request = new HttpGet(resourceURL);
  request.setHeader("Authorization", "bearer " + getAccessToken());
  request.addHeader("Content-Type", "application/json");

  try {
    CloseableHttpResponse reponse = client.execute(request);

    String content = EntityUtils.toString(reponse.getEntity());

    JSONArray jsonArray = new JSONArray(content);
    jsonArray.forEach(o -> System.out.println(o));

  } catch (IOException e) {
    e.printStackTrace();
  }
}

Wenn zB nur die Rollen für unsere Test-App angezeigt werden sollen und der Rollen Name ein "u" enthalten muss, setzt sich der resourceURL-String wie folgt zusammen:

String resourceURL = String.format("https://%%s.onelogin.com/api/2/roles?app_id=%%s&name=u", ONELOGIN_SUBDOMAIN, ONELOGIN_APP_ID);

Query Parameter

Es gibt Query Parameter, die anscheinend von vielen Funktionen unterstützt werden: Fields, Search, Pagination & Sort

Doku: Using Query Parameters - OneLogin Developers

Als Beispiel erweitern wir das List App Users Beispiel indem wir lediglich die resourceURL anpassen und für die Query Parameter vorbereiten:

String queryParameter = "";
String resourceURL = String.format("https://%%s.onelogin.com/api/2/apps/%%s/users%%s", ONELOGIN_SUBDOMAIN, ONELOGIN_APP_ID, queryParameter);

Wollen wir uns anstelle der gesamten User-Information lediglich Vor- und Nachname zurückgeben lassen, neben der ID, dann brauchen wir lediglich den Query Parameter anpassen:

String queryParameter = "?fields=firstname,lastname";

Suche nach allen Benutzern mit dem Nachnamen "Mustermann":

String queryParameter = "?lastname=Mustermann";

Was NICHT funktioniert: Suche nach allen Benutzern mit dem Nachnamen "Mustermann" und dem Vornamen "Erika":

// funktioniert NICHT:
String queryParameter = "?lastname=Mustermann,firstname=Erika";

Ups, eigene Dummheit, wenn man es richtig macht, dann geht es; Die Parameter werden natürlich mit einem "&" concatiniert und nicht mit einem ",":

// funktioniert NICHT:
String queryParameter = "?lastname=Mustermann&firstname=Erika";

Alle Benutzer mit Vorname "Erika", der Nachname soll mit "Muster" anfangen und wir brauchen nur Vor- und Nachname:

String queryParameter = "?lastname=Muster*&firstname=Erika&fields=firstname,lastname";

Seite 1 alle Benutzer, absteigend sortiert nach Nachnamen, bei einer Seitengröße von 1:

String queryParameter = "?page=1&limit=1&sort=-lastname";

Seitenweises Vor- oder Zurückblättern ist möglich, dazu gibt es den Parameter "cursor". Im Header der ersten Paginierten Response gibt es, falls vorhanden, After-Curser und Before-Curser. Über diese Werte kann vor- und zurückgeblättert werden.

Beispielsweise um die erste Seite zu erhalten und anschließend eine Seite weiter blättern:

// erster Aufruf:
String queryParameter = "?page=1&limit=1";
[...]
String afterCursor = response.getFirstHeader("After-Cursor").getValue();
[...]

// zweiter Aufruf
queryParameter = "?cursor=" + afterCursor;

kleines User Management

Es soll zuerst ein neuer User angelegt werden. Anschließend bearbeitet, der Anwendung hinzugefügt und wieder entfernt und abschließend gelöscht werden.

Create User

Doku: Create User - OneLogin Developers

Erstmal ein minimales Beispiel:

private void createUser() throws Exception {
  String resourceURL = String.format("https://%%s.onelogin.com/api/2/users", ONELOGIN_SUBDOMAIN);

  CloseableHttpClient client = HttpClientBuilder.create().build();

  HttpPost request = new HttpPost(resourceURL);
  request.setHeader("Authorization", "bearer " + getAccessToken());
  request.addHeader("Content-Type", "application/json");

  String json = "{\"username\":\"min.requirements\"}";
  StringEntity entity = new StringEntity(json);
  request.setEntity(entity);

  try {
    CloseableHttpResponse response = client.execute(request);
    System.out.println(response.getStatusLine());
    String content = EntityUtils.toString(response.getEntity());
    System.out.println(content);
    JSONObject o = new JSONObject(content);
    System.out.println("new User ID: " + o.get("id"));
  } catch (IOException e) {
    e.printStackTrace();
  }
}

Consolen Ausgabe:

HTTP/1.1 201 Created
{"firstname":null,"updated_at":"2022-06-01T14:34:52.423Z","role_ids":[],"invitation_sent_at":null,"member_of":null,"distinguished_name":null,"email":null,"id":178924216,"password_changed_at":null,"manager_ad_id":null,"group_id":null,"invalid_login_attempts":0,"phone":null,"title":null,"preferred_locale_code":null,"department":null,"samaccountname":null,"lastname":null,"custom_attributes":{"my_role":null},"created_at":"2022-06-01T14:34:52.423Z","directory_id":null,"locked_until":null,"status":7,"company":null,"activated_at":null,"last_login":null,"trusted_idp_id":null,"manager_user_id":null,"username":"min.requirements","comment":null,"external_id":null,"state":1,"userprincipalname":null}
new User ID: 178924216

Nächstes Beispiel mit Vor-, Nach- und Usernamen, Passwort und schönerem JSON:

private void createUser() throws Exception {
  String resourceURL = String.format("https://%%s.onelogin.com/api/2/users", ONELOGIN_SUBDOMAIN);

  CloseableHttpClient client = HttpClientBuilder.create().build();

  HttpPost request = new HttpPost(resourceURL);
  request.setHeader("Authorization", "bearer " + getAccessToken());
  request.addHeader("Content-Type", "application/json");

  JSONObject json = new JSONObject()
    .put("firstname", "Happy")
    .put("lastname", "Gilmore")
    .put("username", "happy.gilmore")
    .put("password", "helloworld123")
    .put("password_confirmation", "helloworld123");
  StringEntity entity = new StringEntity(json.toString());
  request.setEntity(entity);

  try {
    CloseableHttpResponse response = client.execute(request);
    System.out.println(response.getStatusLine());
    String content = EntityUtils.toString(response.getEntity());
    System.out.println(content);
    JSONObject o = new JSONObject(content);
    System.out.println("new User ID: " + o.get("id"));
  } catch (IOException e) {
    e.printStackTrace();
  }
}
HTTP/1.1 201 Created
{"firstname":"Happy","updated_at":"2022-06-01T14:43:30.646Z","role_ids":[],"invitation_sent_at":null,"member_of":null,"distinguished_name":null,"email":null,"id":178924824,"password_changed_at":"2022-06-01T14:43:30.629Z","manager_ad_id":null,"group_id":null,"invalid_login_attempts":0,"phone":null,"title":null,"preferred_locale_code":null,"department":null,"samaccountname":null,"lastname":"Gilmore","custom_attributes":{"my_role":null},"created_at":"2022-06-01T14:43:30.646Z","directory_id":null,"locked_until":null,"status":1,"company":null,"activated_at":"2022-06-01T14:43:30.644Z","last_login":null,"trusted_idp_id":null,"manager_user_id":null,"username":"happy.gilmore","comment":null,"external_id":null,"state":1,"userprincipalname":null}
new User ID: 178924824

Unser neuer User Happy Gilmore ist angelegt und kann sich mit seinem Username & Passwort auch anmelden, kommt aber, wie erwartet, noch nicht auf die Anwendung, da er ihr noch nicht zugewiesen wurde:

Update User

Doku: Update User - OneLogin Developers

private void updateUser(Integer id) throws Exception {
  String resourceURL = String.format("https://%%s.onelogin.com/api/2/users/%%d", ONELOGIN_SUBDOMAIN, id);

  CloseableHttpClient client = HttpClientBuilder.create().build();

  HttpPut request = new HttpPut(resourceURL);
  request.setHeader("Authorization", "bearer " + getAccessToken());
  request.addHeader("Content-Type", "application/json");

  JSONObject json = new JSONObject()
    .put("firstname", "Very Happy");
  StringEntity entity = new StringEntity(json.toString());
  request.setEntity(entity);

  try {
    CloseableHttpResponse response = client.execute(request);
    System.out.println(response.getStatusLine());
    String content = EntityUtils.toString(response.getEntity());
    System.out.println(content);
    JSONObject o = new JSONObject(content);
    System.out.println("User ID: " + o.get("id"));
    System.out.println("Firstname: " + o.get("firstname"));
  } catch (IOException e) {
    e.printStackTrace();
  }
}
HTTP/1.1 200 OK
{"firstname":"Very Happy","state":1,"manager_user_id":null,"department":null,"comment":null,"created_at":"2022-06-01T14:43:30.646Z","email":null,"last_login":"2022-06-01T14:46:10.795Z","lastname":"Gilmore","activated_at":"2022-06-01T14:43:30.644Z","directory_id":null,"updated_at":"2022-06-01T14:57:22.656Z","group_id":null,"samaccountname":null,"status":1,"userprincipalname":null,"trusted_idp_id":null,"title":null,"manager_ad_id":null,"invalid_login_attempts":0,"locked_until":null,"phone":null,"role_ids":[],"invitation_sent_at":null,"company":null,"distinguished_name":null,"external_id":null,"password_changed_at":"2022-06-01T14:43:30.629Z","preferred_locale_code":null,"id":178924824,"member_of":null,"username":"happy.gilmore","custom_attributes":{"my_role":null}}
User ID: 178924824
Firstname: Very Happy

User einer Anwendung hinzufügen

Als nächstes sollte der User einer Anwendung hinzugefügt werden, um so den Zugang zu gewähren.

Überraschenderweise gibt es aber keine API, um einer App einen User hinzuzufügen. irgendwie ist das nicht ganz nachzuvollziehen, da dies über die OneLogin-Webseite möglich ist und es einen API Call gibt, um alle User einer App anzeigen zu lassen (List App Users - OneLogin API).

Ein Erklärungs- und somit Lösungsansatz lautet:

The proper way to do this is to assign applications to a Role in the admin console and then use the APIs to set the roles for the user.

This, in turn grants the user access to the application assigned to the role.

java - Onelogin API to add applications to user - Stack Overflow

Wir haben ja noch die Rolle "user", der die App zugeordnet ist, aus einem vorhergehendem Versuch. Die sollten wir nehmen können.

Man kann es im Screenshot nicht sehen, aber in der URL ist die ID der Rolle enthalten: 546920

Add User to Role

Doku: Add Role Users - OneLogin API

private void addUserToRole(Integer roleId, Integer userId) throws Exception {
  String resourceURL = String.format("https://%%s.onelogin.com/api/2/roles/%%d/users", ONELOGIN_SUBDOMAIN, roleId);

  CloseableHttpClient client = HttpClientBuilder.create().build();

  HttpPost request = new HttpPost(resourceURL);
  request.setHeader("Authorization", "bearer " + getAccessToken());
  request.addHeader("Content-Type", "application/json");

  StringEntity entity = new StringEntity("[" + userId + "]");
  request.setEntity(entity);

  try {
    CloseableHttpResponse response = client.execute(request);
    System.out.println(response.getStatusLine());
    String content = EntityUtils.toString(response.getEntity());
    System.out.println(content);
  } catch (IOException e) {
    e.printStackTrace();
  }
}
HTTP/1.1 200 OK
[{"id":178924824}

Die Überprüfung in der OneLogin Webseite ergibt, dass der User in der Tat hinzugefügt wurde, und es wurden auch keine vorhandenen User aus der Rolle entfernt, die nicht in dem Array enthalten waren.

Unser neuer User Happy Gilmore ist angelegt und kann sich mit seinem Username & Passwort auch anmelden, kommt jetzt auf die Anwendung, da er ihr über die Rolle "user" zugewiesen wurde:

Remove User from Role

Doku: Remove Role Users - OneLogin API

private void removeUserFromRole(Integer roleId, Integer userId) throws Exception {
  String resourceURL = String.format("https://%%s.onelogin.com/api/2/roles/%%d/users", ONELOGIN_SUBDOMAIN, roleId);

  CloseableHttpClient client = HttpClientBuilder.create().build();

  HttpPost request = new HttpPost(resourceURL) {
    @Override
    public String getMethod() {
      return "DELETE";
    }
  };
  request.setHeader("Authorization", "bearer " + getAccessToken());
  request.addHeader("Content-Type", "application/json");

  StringEntity entity = new StringEntity("[" + userId + "]");
  request.setEntity(entity);

  try {
    CloseableHttpResponse response = client.execute(request);
    System.out.println(response.getStatusLine());
  } catch (IOException e) {
    e.printStackTrace();
  }
}
HTTP/1.1 204 No Content

Die Überprüfung in der OneLogin Webseite ergibt, dass der User aus der Rolle entfernt wurde.

Interessant ist an dem Code, dass die Klasse HttpDelete des Apache HttpClients keinen Content im Body vorsieht.

Um trotzdem ein DELETE mit Body absenden zu können, war der einfachste Weg, ein HttpPost zu nehmen und dessen Methode zu überschreiben:

HttpPost request = new HttpPost(resourceURL) {
  @Override
  public String getMethod() {
    return "DELETE";
  }
};
[...]
request.setEntity(entity);

Delete User

Doku: Delete User - OneLogin Developers

private void deleteUser(Integer userId) throws Exception {
  String resourceURL = String.format("https://%%s.onelogin.com/api/2/users/%%d", ONELOGIN_SUBDOMAIN, userId);

  CloseableHttpClient client = HttpClientBuilder.create().build();

  HttpDelete request = new HttpDelete(resourceURL);
  request.setHeader("Authorization", "bearer " + getAccessToken());
  request.addHeader("Content-Type", "application/json");

  try {
    CloseableHttpResponse response = client.execute(request);
    System.out.println(response.getStatusLine());
  } catch (IOException e) {
    e.printStackTrace();
  }
}
HTTP/1.1 204 No Content

Damit ist Happy Gilmore Geschichte und auch in der Überprüfung auf der OneLogin Webseite nicht mehr zu finden.

GitHub

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

Categories
Development

OneLogin Self Registration

Konfiguration

Users -> Self Registration

New Profile

Profil Name vergeben: DemoSelfRegistrationProfile

Configuration auf Enabled setzen.

URL setzen auf: http://localhost

Registrierung

Die Registrierung ist erreichbar unter: https://deringo-dev.onelogin.com/self-registration2?name=http://localhost

Die Email:

Nach klicken auf den Link erscheint folgender Text:

Es wird auf einen Login-Screen weitergeleitet. Allerdings wurde noch kein Passwort vergeben.

Währenddessen wurde die Mail zum Setzen des Passworts geschickt:

Über den Link wird das Passwort gesetzt und anschließend kann man sich einloggen in OneLogin:

Zugang in die Anwendung - 1. Versuch

Der Zugang zur Anwendung wird verwehrt:

Die Benutzerin Erika Mustermann konnte authentifiziert werden, ist aber für die Anwendung nicht authorisiert.

Benutzer Zugang zur Anwendung gewähren

Übersicht der Users:

Email Adressen sind unkenntlich gemacht

Erika Mustermann auswählen und auf Applications gehen:

Dort wird sie der Applikation hinzugefügt.

Zugang in die Anwendung - 2. Versuch

Der Zugang zur Anwendung wird jetzt gewährt:

Admin benachrichtigen

Um den Workflow rund zu machen, benötigen wir noch eine Benachrichtigung an die User-Admins, sobald sich ein neuer Benutzer registriert hat.

Den Reiter Activity -> Notifications auswählen.

Eine neue Notification anlegen.

In Conditions als Event Self registration created (203) auswählen. Es gibt mehrere Events mit Self registration, da mir nicht klar ist, wann genau welcher Event ausgelöst wird, habe ich den 203 gewählt, der klingt so, als ob er getriggert wird, sobald die SR vollendet ist.

Als Action Email user mit Custom Field, so können wir die Email-Adresse selbst bestimmen, zB für einen Support-Postkorb.

Oben kann man der Notification Regel auch noch einen Titel vergeben, dort, wo im Screenshot Untitled steht

Nach dem Speichern der Notification hat ein neuer Benutzer Happy Gilmore den Registrierungsprozess durchlaufen. Dabei wurde aber keine Email verschickt.

Über Activity -> Events kann man die Events sehen, die dabei ausgelöst wurden:

In der Notification wird der Event auf Self registration approved (101) geändert, dann der neue Benutzer gelöscht, so dass er sich wieder neu registrieren kann.

Nachdem der Benutzer sich erneut registriert hat, wird diesmal eine Email verschickt:

Die Mail enthält den Text (Subject & Body), der vorher in der Notification hinterlegt wurde. Leider gibt es keinen Hinweis, welcher User sich registriert hat.

Ein Blick in die bereits vordefinierten Notifications zeigt, dass es Variablen gibt und diese in doppelten geschweiften Klammern gesetzt sind.

Getestet wurden folgende Ausdrücke:

{{user.name}}
{{user.email}}
{{user}}
{{user.id}}
{{user.unbekanntesAttribut}}

In der Email standen dann folgende Werte:

Happy Gilmore
happy.gilmore@mymail.de
{{unknown_tag:user}}
{{unknown_tag:user.id}}
{{unknown_tag:user.unbekanntesAttribut}}

Über Name und Email lässt sich der User gezielt suchen.

Eine Dokumentation verfügbarer Variablen findet sich: <TBD, noch nicht gefunden.>

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.

Categories
Development

OneLogin

Ich setzte mich mit der cloudbasierten IAM Lösung OneLogin auseinander und möchte zum Einstieg deren simpelste Beispiel-Anwendung zum laufen bringen.

Die Entwicklerseite von OneLogin: OneLogin Developers: APIs, Documentation & Tutorials

OneLogin Developer Account erstellen

Auch für das einfachste Beispiel wird ein Account benötigt, hierzu kann ein kostenfreier Entwickler Account angelegt werden.

Ich habe mich dabei für den Domain Namen deringo-dev.onelogin.com entschieden.

Beispielanwendung

Am einfachsten scheint mir eine OpenID Connect basierte Javascript Anwendung zu sein, daher wähle ich aus den Samples die Single Page App heraus.

Zuerst Node.js updaten.

Projekt clonen und ausführen:

mkdir test
cd test
git clone https://github.com/onelogin/onelogin-oidc-node.git
cd '.\onelogin-oidc-node\2. Implicit Flow\'
npm install
--> npm ERR! Unexpected token '.'

Das fängt ja mal wieder gut an 🙁

nvm use 14.17.3
npm install

Mit der alten Version hat es dann funktioniert. 🙂

npm start

Die Anwendung lässt sich jetzt über http://localhost:3000/ aufrufen.

Es kommt natürlich ein Fehler, da die Anwendung noch nicht konfiguriert ist:

Application in OneLogin anlegen

Auf der OneLogin Seite (https://deringo-dev.onelogin.com/) unter Applications auf Add gehen und eine OpenId Connect App anlegen.

Name, Beschreibung und (schnell gemaltes) Square Icon vergeben und speichern.

Im darauf folgenden Screen ist mein Square Icon leider nicht mehr vorhanden. Dafür steht dort aber ein Feld Tab, in dem etwas steht, was dort definitiv nicht stehen sollte (Name eines Kunden, woher kommt das denn??)

Ich ignoriere das erstmal und notiere mir die Client ID unter SSO.

Ich muss noch die Redirect URI zu meiner App (http://localhost:3000) eintragen:

Anwendung konfigurieren

Die Client ID und meine OneLogin-Subdomain (deringo-dev) trage ich in der main.js ein.

//
// OIDC Client Configuration
//
const ONELOGIN_CLIENT_ID = 'geheim-a91c-013a-175a-02471d082b0b208817';
const ONELOGIN_SUBDOMAIN = 'deringo-dev';

Die Anwendung lässt sich über http://localhost:3000/ aufrufen:

Jetzt erscheint eine Login-Seite:

Ich kann mich mit meinen OneLogin-Developer-Zugangsdaten einloggen.

Das Ausloggen gestaltet sich bisher als unmöglich: Weder der Neustart des Servers, noch das Löschen des Local, bzw. Session Storages führt zum erneuten Login. Cookies sind keine gesetzt und können daher nicht gelöscht werden.

Über ein neues, anonymes Browserfenster lässt sich ein erneuter Login erzwingen.

Neuer User für die Beispielanwendung

Auf der OneLogin Seite (https://deringo-dev.onelogin.com/) unter Users auf New User gehen und einen neuen Benutzer anlegen.

First-, Last-, Username eingetragen.
Beispiel-App (SinglePageApp) hinzugefügt.

Ein Passwort lässt sich anscheinend nicht über die OneLogin Seite für den Benutzer setzen. Für die Passwort-Wiederherstellung wird eine Email-Adresse benötigt, das ist zumindest der einzig wählbare Authentifizierungsfaktor. Ich muss meinem neuen Benutzer auch eine Email Adresse vergeben.

Das nachträgliche setzen der Email Adresse hat nicht funktioniert. Ich habe dann einen weiteren neuen Benutzer angelegt, diesmal ohne Username, dafür aber mit Email Adresse.
Mit diesem Benutzer konnte ich dann das Passwort "Zurück"setzen lassen und mich anschließend einloggen.

Beispielanwendung 2

Nach dem Implicit flow, der nicht mehr empfohlen ist, schaue ich mir den Auth Code Flow + PKCE an, der als Best Practice gilt.

Aus dem bereits geclonten Git Repository ist das das 4. Projekt.

cd '.\4. Auth Flow - PKCE\'
npm install
npm start

Die Client ID und meine OneLogin-Subdomain (deringo-dev) trage ich in der main.js ein.

//
// OIDC Client Configuration
//
const ONELOGIN_CLIENT_ID = 'geheim-a91c-013a-175a-02471d082b0b208817';
const ONELOGIN_SUBDOMAIN = 'deringo-dev';

Die Anwendung lässt sich über http://localhost:3000/ aufrufen:

Der Login mit meinem Benutzer funktionierte problemlos.

Allerdings wurden anschließend auf der Sample Seite NICHT die Benutzer Daten angezeigt.

Ein Blick in die Console des Browsers zeigt den Fehler:

Da die minified Version des oidc-client.js nicht sonderlich leserlich ist, lade ich die nicht-minified Version herunter und speichere sie neben der minified Version im Projekt ab.

In der Datei index.hbs wird das oidc-client Script importiert, also passe ich dort die Referenz an.

Aber auch das debuggen mit der nicht-minified Version brachte keinen weiteren Erkenntnisgewinn.

Die Lösung fand sich schließlich in der OneLogin Konfiguration: Im SSO Teil der Applikation musste der Token Endpoint auf "None (PKCE)" umgestellt werden.

Categories
AWS Development

Domainname für EC2

Auf die zuvor erstellten EC2 Instanz soll ein "menschenlesbarer" Domainname den Zugang erleichtern.

Ich möchte im AWS Ökosystem bleiben und daher die Domain über Amazon Route 53 registrieren. Ansonsten hätte ich vielleicht einen anderen Anbieter gewählt, wie ich es schon für eine günstige Website gemacht hatte.

Wahl des Domainnamens

Das Projekt wird, zumindest auf meiner Infrastruktur, mutmaßlich nicht allzulange bestehen bleiben. Eine große Marktrecherche für einen tollen Namen brauche ich daher nicht, nur einprägsam sollte er sein.

Die wichtigste Anforderung ist ein günstiger Preis.

Die Preisübersicht auf der AWS Seite ist nicht sonderlich übersichtlich, eine "route 53 cheapest domain" zu googeln brachte aber auch nur den Link auf ein PDF zu Tage. In dem steht uA der "Registration and Renewal Price" und der ist für den TLD Namen "click" mit 3 Dollar am günstigsten.

Allerdings ist "click" nicht der beste Name im deutschsprachigen Raum: "Hey, besuch doch mal meine Seite meineApp.click" "Ich kann meineApp.klick nicht finden".

Der zweitgünstigste TLD Name mit 5 Dollar ist "link". "link" ist mir lieber als "click" und ist von der Preisdifferenz vertretbar.

Nach kurzem Brainstorming habe ich mich dann für den Namen "freigabe" und der TLD "link", also http://freigabe.link entschieden.

Domainname registrieren

Auf die Seite des Dienstes Route 53 gehen und dort die "Domain registration" aufrufen und die gewünschte Domain eingeben:

Ab in den Shopping cart und ... im nächsten Schritt muss ich meine Daten eingeben? Hey Amazon, die habt ihr doch schon!

Anschließend wird die Domain auf mich registriert, was leider bis drei Tage dauern kann.

Bis zum Abschluss der Registrierung wird hier pausiert, anschließend geht es weiter mit der

Anbindung Domain Name an EC2

Die Registrierung der Domain war zum Glück bereits nach drei Stunden abgeschlossen und nicht erst nach drei Tagen. Negativ ist zu erwähnen, dass die 5 Dollar für den Domain Namen netto sind, also noch mal 19% USt hinzu kommen.

Auf der Route 53 Seite über Domains > Registered domains die Domain freigabe.link auswählen:

Über Manage DNS geht es in die Hosted zone der Domain:

Über Create record wird der Eintrag gesetzt, dass der Domain Name auf die Public IP des EC2-Servers zeigen soll:

Nachdem ich den Web-Server gestartet hatte, funktionierte es auch sofort.

Der Web-Server war heruntergefahren. Ob ich das gestern noch gemacht hatte, weiß ich nicht mehr 100%ig.
In dem Catalina Log vom Tomcat fand sich uA folgender Eintrag:

Invalid character found in the request target [/index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21 ]. The valid characters are defined in RFC 7230 and RFC 3986

Vielleicht gab es zu viele dieser Hacking Versuche?

Als nächstes kommt noch ein Reverse Proxy davor, der kann noch etwas Traffic vom Tomcat fern halten.
Vielleicht werde ich aber auch noch eine WAF vor den Server setzen? Eine kurze Recherche zu dem Thema ergab allerdings, dass das nicht direkt möglich ist, sondern ein Application Load Balancer oder CloudFront zwischengeschaltet werden muss.

EMail

Ein Nebenschauplatz ist das Thema email, so dass ich Mails an diese Domain empfangen bzw. versenden kann.

Das Thema ist leider nicht ganz so simpel gelöst, wie ich es mir erhofft hatte. Einen simplen "AWS Mail Service", den man über Route 53 konfigurieren kann, gibt es nicht. Es gibt mit Amazon Workmail eine SaaS Lösung mit Focus auf Unternehmen und entsprechender Kostenstruktur.

Weiterhin wird Google Apps verschiedentlich empfohlen, aber auch das ist mit Kosten verbunden und wird nicht über die kostenfreien Angebote abgedeckt.

Eine SES / S3 Lösung deckt nur rudimentär den Bedarf, zB werden die Mails als Dateien auf einem S3 Bucket gespeichert. Da scheinen auch noch andere Konstellationen möglich zu sein, aber keine, die überzeugt.

Als kostenfreie WebMail-Lösung wird zB Zoho empfohlen. Eine Anleitung findet sich zB hier.

Es wäre natürlich auch möglich, einen eigenen WebMail-Server auf einem eigenen EC2 Server zu betreiben.

Als Mittelweg wäre auch ein weiter Docker Container auf dem vorhandenen EC2 Server möglich.

Komplettlösungen als Mailserver wären zB Mailcow, Mailu oder Kopano.

Jede Lösung ist mit mehr oder weniger Aufwand realisierbar, aber jede Lösung ist aufwändiger als meine momentane Motivation, oder aktueller Bedarf, und so setzte ich das erstmal auf die "wenn mal Zeit ist"-Liste.