Authentifizierung mit OpenShift-OAuth-Server

Die Funktion "Social Login" verfügt über mehrere vorkonfigurierte Anbieter (wie Google, GitHub, oder Facebook), aber Sie können auch zusätzliche Anbieter konfigurieren (z. B. Instagram, den OAuth-Server Red Hat OpenShift und den OAuth-Proxy-Sidecar). Der erste ist ein Standardablauf für OAuth-Berechtigungscode, bei dem ein Web-Browser, der auf eine in Liberty ausgeführte App zugreift, zur Authentifizierung an den Red Hat OpenShift OAuth-Server umgeleitet wird. Die zweite Methode akzeptiert ein eingehendes Token aus dem Red Hat OpenShift OAuth-Proxy-Sidecar oder aus einem Red Hat OpenShift -API-Aufruf. Für diesen Ansatz ist eine weniger clusterspezifische Konfiguration erforderlich.

Sie können Liberty in einem Pod ausführen, aber im Berechtigungscodeablauf kann Liberty außerhalb des Red Hat OpenShift -Clusters ausgeführt werden. In beiden Modi kann ein optionales JWT für die Weitergabe an nachgelagerte Services erstellt werden.

Die Verwendung von Red Hat OpenShift als Provider unterscheidet sich geringfügig von anderen OAuth-Providern, da ein Servicekontotoken erforderlich ist, um Informationen zu den OAuth-Tokens abzurufen. Nachdem die Client-ID, der geheime Schlüssel und das Token von Red Hat OpenShiftabgerufen wurden, kann Liberty wie folgt konfiguriert werden:

Wollen Sie das Feature aktivieren, fügen Sie es der Datei server.xml hinzu.

Sehen Sie sich die folgende Beispielserverkonfiguration für die Verwendung des Red Hat OpenShift -OAuth-Servers an.

<server description="social">

  <!-- Enable features -->
  <featureManager>
    <feature>appSecurity-3.0</feature>
    <feature>socialLogin-1.0</feature>
  </featureManager>

<logging traceSpecification="com.ibm.ws.security.*=all=enabled" maxFiles="8" maxFileSize="200"/>

<httpEndpoint  id="defaultHttpEndpoint" host="*" httpPort="8941" httpsPort="8946" > <tcpOptions soReuseAddr="true" /> </httpEndpoint>


  <!-- specify your clientId, clientSecret and userApiToken as liberty variables or environment variables -->
  <oauth2Login id="openshiftLogin"
    scope="user:full"
    clientId="${myclientId}"
    clientSecret="${myclientSecret}"
    authorizationEndpoint="https://oauth-openshift.apps.papains.os.example.com/oauth/authorize"
    tokenEndpoint="https://oauth-openshift.apps.papains.os.example.com/oauth/token"
    userNameAttribute="username"
    groupNameAttribute="groups"
    userApiToken="${serviceAccountToken}"
    userApiType="kube"
    userApi="https://api.papains.os.example.com:6443/apis/authentication.k8s.io/v1/tokenreviews">
  </oauth2Login>

  <keyStore id="defaultKeyStore" password="keyspass" />

  <!-- more application config would go here -->

</server>

Im Sidecar-Szenario ändert sich die Konfiguration, um ein eingehendes Token vom Sidecar zu akzeptieren. Sehen Sie sich die folgende Beispielserverkonfiguration für die Verwendung des OAuth-Proxy-Sidecar an:

<!-- specify your userApiToken as a liberty variable or environment variable -->
  <!-- note that no clientId or clientSecret are needed -->
  <oauth2Login id="openshiftLogin"
    scope="user:full"
    userNameAttribute="username"
    groupNameAttribute="groups"
    userApiToken="${serviceAccountToken}"
    userApiType="kube"
    accessTokenHeaderName="X-Forwarded-Access-Token"
    accessTokenRequired="true"
    userApi="https://kubernetes.default.svc/apis/authentication.k8s.io/v1/tokenreviews">
  </oauth2Login>

Soll die HTTPS-Kommunikation verwendet werden, muss entweder der Server über einen von einer bekannten Zertifizierungsstelle signierten Schlüssel verfügen, dem Liberty automatisch vertrauen kann, oder der öffentliche Schlüssel des Servers muss dem Liberty-Truststore hinzugefügt werden. Red Hat OpenShift stellt standardmäßig keine CA-signierten Schlüssel bereit. Daher muss der öffentliche Schlüssel vom Red Hat OpenShift OAuth-Server hinzugefügt werden. Soll der öffentliche Schlüssel hinzugefügt werden, können Sie eine Umgebungsvariable in der Datei server.env angeben. Diese Einstellung identifiziert die Datei, die den öffentlichen Schlüssel im PEM-Format enthält. Liberty liest die Datei und fügt den Schlüssel zu seinem Truststore hinzu.

# server.env

# OAuth sidecar scenario: causes the Kubernetes default certificate that is pre-installed in pods to be added to Liberty trust store.
cert_defaultKeyStore=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# OAuth server scenario: causes the public keys from /tmp/trustedcert.pem (obtained separately) to be added to Liberty trust store.
cert_defaultKeyStore=/tmp/trustedcert.pem