OpenShift OAuth サーバーでの認証

ソーシャルログイン機能には、あらかじめ設定済みのプロバイダ Google GitHub,、Facebookなど）がいくつか用意されていますが、追加のプロバイダ（Instagram、 Red Hat OpenShift OAuthサーバー、OAuth Proxyサイドカーなど）を設定することもできます。 1 つは標準の OAuth 許可コード・フローです。このフローでは、Liberty で実行されているアプリケーションにアクセスする Web ブラウザーが、認証のために Red Hat OpenShift OAuth サーバーにリダイレクトされます。 2 番目のトークンは、 Red Hat OpenShift OAuth プロキシー・サイドカーからのインバウンド・トークン、または Red Hat OpenShift API 呼び出しから取得されたインバウンド・トークンを受け入れます。 この方法は、クラスター固有の構成をそれほど必要としません。

Liberty はポッドで実行できますが、許可コード・フローでは、Liberty は Red Hat OpenShift クラスターの外部で実行できます。 どちらのモードでも、オプションの JWT を作成してダウンストリーム・サービスへの伝搬を行うことができます。

Red Hat OpenShift をプロバイダーとして使用する場合は、OAuth トークンに関する情報を取得するためにサービス・アカウント・トークンが必要になるため、他の OAuth プロバイダーとは若干異なります。 クライアント ID、秘密鍵、およびトークンを Red Hat OpenShiftから取得したら、以下に示すように Liberty を構成できます。

このフィーチャーを有効にするには、server.xml ファイルにこのフィーチャーを追加します。

Red Hat OpenShift OAuth サーバーを使用するためのサーバー構成の例を以下に示します。

<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>

サイドカーのシナリオでは、サイドカーからのインバウンド・トークンを受け入れるように構成が変更されます。 OAuth プロキシー・サイドカーを使用するためのサーバー構成の例を以下に示します。

<!-- 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>

HTTPS 通信を使用するには、既知の認証局が署名した鍵 (Liberty が自動的に信頼) をサーバーが持っていること、またはサーバーの公開鍵を Liberty のトラストストアに追加することが必要です。 Red Hat OpenShift は、デフォルトでは CA 署名鍵を提供しないため、 Red Hat OpenShift OAuth サーバーからの公開鍵を追加する必要があります。 公開鍵を追加するには、server.env ファイルで環境変数を指定します。 以下の設定は、PEM 形式の公開鍵が含まれているファイルを特定しています。 Liberty はこのファイルを読み取って、トラストストアに鍵を追加します。

# 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