すべての UI 画面は、Red Hat Single Sign-On で国際化されています。デフォルトの言語は英語ですが、Theme タブで Internationalization スイッチをオンにする場合は、サポートするロケールとデフォルトのロケールを選択できます。ユーザーが次にログイン時に、ログイン画面、ユーザーアカウント管理 UI、および管理コンソールに使用するログインページで言語を選択できます。『サーバー開発者ガイド』では、追加の言語を提供する方法を説明します。

ユーザーにパスワードがない場合や、パスワードが削除されると、ページに Set Password セクションが表示されます。

ユーザーのパスワードを作成するには、新しいパスワードを入力します。すべて入力後に Set Password ボタンをクリックします。Temporary スイッチがオンの場合、この新しいパスワードは一度だけ使用でき、ログインした後にパスワードの変更が要求されます。

ユーザーにパスワードがすでにある場合は、Reset Password セクションでリセットできます。

また、email をセットアップした場合は、ユーザーに電子メールを送信すると、パスワードのリセットを求められます。Reset Actions リストから Update Password を選択し、Send Email をクリックします。任意で、メールリンクの有効性を設定できます。このリンクは、レルム設定の Tokens タブにデフォルトで設定されます。送信されたメールには、ユーザーがパスワードの更新画面に追加するリンクが含まれます。

ユーザーは、タイプパスワードを 1 つだけ持つことができます。

管理コンソール内で、特定ユーザーの他の種類の認証情報を設定することはできません。これはユーザーの責任です。Credentials タブでユーザーの認証情報を削除できます。たとえば、ユーザーが OTP デバイスを失った場合や、認証情報が侵害されたりするなどの場合にのみ削除できます。

また、新規ユーザーの作成時にアカウントに追加する必要なアクション (Add User ボタンをクリックするとユーザー一覧画面、または ログインページの user registration リンクから) を指定することもできます。デフォルトの必須アクションを指定するには、左側のメニュー項目 Authentication に移動し、Required Actions タブをクリックします。

完全に新しいユーザーのログイン時に、実行する必要なアクションの Default Action コラムのチェックボックスをクリックするだけです。

多くの組織には、新規ユーザーの初回ログイン時に、Web サイトの契約条件に同意する必要があります。Red Hat Single Sign-On には、この機能は必要なアクションとして実装されていますが、いくつかの設定が必要です。いずれかとして、前述の Required Actions タブに移動し、Terms and Conditions アクションを有効にする必要があります。base ログインテーマで terms.ftl ファイルを編集する必要もあります。テーマの拡張および作成に関する詳細は、『サーバー開発者ガイド』を参照してください。

ボットから登録を保護するために、Red Hat Single Sign-On は Google reCAPTCHA と統合しています。これを有効にするには、最初に Google Recaptcha Website に移動し、reCAPTCHA サイトキーとシークレットを取得できるように API キーを作成する必要があります。(localhost はデフォルトで機能するため、ドメインを指定する必要はありません)。

次に、Red Hat Single Sign-On 管理コンソールで実行する必要がある手順がいくつかあります。左側のメニュー項目 Authentication をクリックし、Flows タブに移動します。このページのドロップダウンリストから Registration フローを選択します。

適切なラジオボタンをクリックして、Required に 'reCAPTCHA' 要件を設定します。これにより、画面で reCAPTCHA が有効になります。次に、Google reCAPTCHA Website で生成した reCAPTCHA サイトキーおよびシークレットを入力する必要があります。reCAPTCHA フローエントリーの右側にある 'Actions' ボタンをクリックし、"Config" リンクから、この設定ページで reCAPTCHA サイトキーとシークレットを入力します。

最後のステップは、Red Hat Single Sign-On セットのデフォルトの HTTP 応答ヘッダーを変更することです。Red Hat Single Sign-On は、Web サイトに iframe 内に任意のログインページを含めないようにする予定です。これは、クリックジャック攻撃を防ぐためです。Google が iframe 内の登録ページを使用するように承認する必要があります。左側のメニュー項目 Realm Settings に移動してから、Security Defenses タブに移動します。https://www.google.com を、X-Frame-Options ヘッダーおよび Content-Security-Policy ヘッダーの値に追加します。

これを行うと、登録ページに reCAPTCHA が表示されるはずです。ログインテーマで register.ftl を編集して、reCAPTCHA ボタンの配置およびスタイルで変更できます。テーマの拡張および作成に関する詳細は、『サーバー開発者ガイド』を参照してください。

以下は、各ポリシータイプについて説明します。

OTP ジェネレーターには、以下の 2 つのアルゴリズムを選択できます。時間ベース (TOTP) と番号ベースの (HOTP)TOTP の場合は、トークンジェネレーターが現在の時間と共有の秘密をハッシュ化します。サーバーは、特定の期間内のハッシュと送信された値を比較することで OTP を検証します。そのため、TAOTP は短期間 (通常は 30 秒) にのみ有効です。HOTP では、共有カウンターの現在の時間ではなく、共有カウンターが使用されます。サーバーは、成功した各 OTP ログインでカウンターをインクリメントします。したがって、有効な OTP は、ログインに成功してからしか変更しません。

TOTP は、HOTP の OTP は不確定な時間に対して有効であり、一致可能な OTP は短期間にのみ有効であるため、より安全であると考えられます。HOTP は、ユーザーが時間間隔を稼働する前に OTP に入力する必要がないため、より使いやすいユーザーです。Red Hat Single Sign-On が TOTP に実装されている方法により、この区別がほとんど発生しなくなります。HOTP では、サーバーがカウンターを増やすたびにデータベースを更新する必要があります。負荷が大きい場合、認証サーバーでパフォーマンスが低下する可能性があります。そのため、より効率的な代替機能を提供するために、使用されるパスワードを記憶しません。これにより DB の更新は必要ありませんが、不利な点は TOTP が有効な時間間隔で再度使用される可能性があります。Red Hat Single Sign-On の今後のバージョンでは、TOTP が時間間隔で古い OTP をチェックするかどうかが予定されています。

Red Hat Single Sign-On には、一定数のビルトインフローが含まれています。これらのフローを変更することはできませんが、ニーズに合わせて要件を変更できます。

本セクションでは、ビルトインのブラウザーログインフローの手順について説明します。左側のドロップダウンリストで、browser を選択し、以下の画面に移動します。

フロー選択リストに右にあるヒント (tiny question mark) にマウスをかざすと、フローの内容を説明することになります。

Auth Type コラムは、実行される認証またはアクションの名前です。認証がインデントされている場合、これはサブフローにあり、親の動作に応じて実行されないことがあります。Requirement 列は、アクションが実行されるかどうかを定義するラジオボタンのセットです。このコンテキストで各ラジオボタンが何をするか説明してください。

本セクションでは、フローの仕組みをより詳細に行う方法と、独自のフローを作成する方法を説明します。独自のフローを設計する際に、重要な機能とセキュリティー上の考慮事項があることに注意してください。適切に作成されたフローではログインをできないようにし、ユーザーには任意の設定よりも検証が少なくなるか、単にエラーの原因になります。

フローを作成するには、以下のいずれかを行います。

新しいフローを作成する場合、最上位のフローを作成する必要があります。

以下のオプションを使用します。

フローが作成されたら、New ボタンおよび Copy ボタンに加えて、Delete、Add execution、および Add flow の準備を行います。

最後のフローは、フローとサブフローの構造、これらのフローの実行、サブフローおよび実行に設定した要件によって決まります。

実行は Add execution ボタンで追加できます。リセットメールを OTP を検証するためのリセットメールの送信から、実行にはさまざまなアクションを使用できます。Provider の横にあるツールチップ (tiny question mark) にマウスをかざすと、実行内容が説明されています。

これらは 自動実行 と インタラクティブな実行 に分割できます。自動実行 は Cookie の実行と似ていますが、フローで問題が発生した場合にそれらのアクションが自動的に実行されます。インタラクティブな実行 は、通常は一部のユーザー入力を取得するためにフローを停止します。正常に実行されると、success な状態になります。これはフローが成功したかどうかの一部であるため、これは重要になります。たとえば、空の Browser フローでは、誰でもログインできなくなります。そのためには、正常に評価された 1 つ以上の実行が必要になります。たとえば、入力されて送信されるユーザー名パスワードフォームなどがあります。

サブフローは、Add flow ボタンを使用してトップレベルのフローに追加できます。これにより、Create Execution Flow ページと非常に似た Create Top Level Form ページが開きます。唯一の違いは、Flow Type は generic (前のように) または form のいずれかになります。form タイプは、組み込み Registration フローに対して行われる内容など、ユーザーの単一フォームを生成するサブフローを構築するために使用されます。サブフローは、実行に含まれる評価方法に応じて、正常に評価される特別な実行タイプです (これには、含まれるサブフローの評価が含まれます)。この評価のロジックは、各実行およびサブフローの要件によって異なります。

この内容の完全な理解には、フローの評価時に要件がどのように機能するかに関する詳細な説明が必要で、これはサブフローにも適用されます。詳細は、上記の実行要件セクションを参照してください。

実行を追加したら、Requirement が正しい値に設定されていることを確認します。必要が 1 つしかない場合でも、設定されない場合もあります。

フローの作成時に、フローに追加したすべての要素には、右側の Actions メニューが表示されます。フローに追加したすべての要素には、このメニューの Delete オプションがあり、フローからこれを削除します。Identity Provider Redirector の場合のように、実行に Config メニューオプションを含めることができます。Add execution および Add flow メニューオプションを使用して、サブフローの実行およびサブフローを追加することもできます。

最後に、実行の順序は重要であるため、名前の左側に設定されている上下ボタンで、実行とサブフローを各フロー内で上下に動かすことができます。

フローの作成については、このセクションでは、より高度なブラウザーログインフローの作成について説明します。このフローの目的は、WebAuthn を使用してパスワードなしの方法でログインと、パスワードと OTP を使用した二要素認証を選択することができます。作成するフローは標準のブラウザーログインと似ていますが、ユーザー名の選択に到達すると分岐します。ただし、フローをコピーする代わりに、最初からフローを作成します。

Username フォームは「Browser」フローのユーザー名フォームと似ていますが、ユーザーはパスワードなしのログインを実行できるように、ユーザー名のみを要求します。ただし、これにより Red Hat Single Sign-On サーバーでユーザーの列挙攻撃が可能になります。これは、利便性に避けられないセキュリティーリスクであるため、フローではユーザーが入力すべきパスワードに推測する必要はないはずです。

生成される最終フローは以下のとおりです。

ユーザー名の入力後、このフローが機能する仕組みは以下のようになります。

WebAuthn パスワードレス実行は、Required ではなく Alternative に設定されているため、このフローではユーザーに WebAuthn 認証情報を登録するように要求されることはありません。ユーザーに Webauthn 認証情報を取得するには、そのユーザーに管理者が必要なアクションを追加する必要があります。最初に、Webauthn Register Passwordless が必要なアクションがレルムで有効になっていることを確認した後 (WebAuthn ドキュメンテーションを参照)、ユーザーの Credentials 管理メニューの Credential Reset を使用して必要なアクションを設定します。

このような高度なフローを複数作成すると、副次的な影響があります。たとえば、ユーザーのパスワードをリセットできるようにする必要がある場合は、パスワードフォームからアクセスが可能になります。デフォルトの「Reset Credentials」フローでは、ユーザーは自分のユーザー名を入力する必要があります。「Browser Password-less」フローですでにユーザー名をすでに入力されているため、Red Hat Single Sign-On では必要がなく、ユーザーエクスペリエンスの面ではサブ最適となります。これを修正するには、以下が可能になります。

これはプラットフォームに依存します。正確な手順は、使用する OS および Kerberos ベンダーによって異なります。Kerberos サーバーの設定および設定方法は、Windows Active Directory、MIT Kerberos、および OS のドキュメントを参照してください。

少なくとも以下が必要です。

sudo kadmin.local

次に、以下のようなコマンドを使用して、HTTP プリンシパルを追加し、キーをキータブファイルにエクスポートします。

addprinc -randkey HTTP/www.mydomain.org@MYDOMAIN.ORG
ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG

Keytab ファイル /tmp/http.keytab は、Red Hat Single Sign-On サーバーが稼働しているホストでアクセスできる必要があります。

kerberos クライアントをマシンにインストールする必要があります。これはプラットフォームに依存します。Fedora、Ubuntu、または RHEL の場合は、Kerberos クライアントおよびその他のユーティリティーを含む freeipa-client パッケージをインストールできます。(Linux 上の /etc/krb5.conf ファイルにある) kerberos クライアントを設定します。Kerberos レルム と、サーバーが稼働している HTTP ドメインを少なくとも設定する必要があります。レルム MYDOMAIN.ORG の例では、以下のように domain_realm セクションを設定できます。

[domain_realm]
  .mydomain.org = MYDOMAIN.ORG
  mydomain.org = MYDOMAIN.ORG

次に、HTTP プリンシパルで keytab ファイルをエクスポートし、Red Hat Single Sign-On サーバーが実行しているプロセスでファイルにアクセスできることを確認する必要があります。実稼働環境では、このプロセスによってのみ読み取り可能であり、その他のユーザーが行うことは理想的です。上記の MIT Kerberos の例では、キータブを /tmp/http.keytab にすでにエクスポートしています。KDC と Red Hat Single Sign-On が同じホストで実行されている場合は、このファイルがすでに利用可能な状態である。

クライアントは上記のように kerberos クライアントをインストールし、krb5.conf を設定する必要があります。さらに、ブラウザーで SPNEGO ログインサポートを有効にする必要があります。ブラウザーを使用している場合は、「Kerberos 用 Firefox の設定」を参照してください。URI .mydomain.org は、network.negotiate-auth.trusted-uris 設定オプションで許可される必要があります。

Windows ドメインでは、クライアントは通常、IE はすでに Windows ドメインの SPNEGO 認証に参加できるため、特別な設定を必要としません。

Kerberos 5 は、認証情報の委譲の概念をサポートしています。このシナリオでは、アプリケーションを使用して Kerberos チケットを再使用して、Kerberos が保護された他のサービスと相互作用できるようになります。SPNEGO プロトコルは Red Hat Single Sign-On サーバーで処理されるため、GSS 認証情報を OpenID Connect トークンクレーム 内のアプリケーションまたは Red Hat Single Sign-On サーバーからアプリケーションに送信される SAML アサーション属性のいずれかに伝播する必要があります。この要求をトークンまたはアサーションに挿入するには、各アプリケーションは gss 委任認証情報 と呼ばれる組み込みプロトコルマッパーを有効にする必要があります。これは、アプリケーションのクライアントページの Mappers タブで有効にされます。詳細は、「プロトコルマッパー」の章を参照してください。

アプリケーションは、Red Hat Single Sign-On を使用して他のサービスに対して GSS 呼び出しを行う前に、受信する要求を Red Hat Single Sign-On からデシリアライズする必要があります。アクセストークンから GSSCredential オブジェクトに認証情報をデシリアライズしたら、以下のように GSSContext が GSSManager.createContext メソッドに渡される状態で作成される必要があります。

// Obtain accessToken in your application.
KeycloakPrincipal keycloakPrincipal = (KeycloakPrincipal) servletReq.getUserPrincipal();
AccessToken accessToken = keycloakPrincipal.getKeycloakSecurityContext().getToken();

// Retrieve kerberos credential from accessToken and deserialize it
String serializedGssCredential = (String) accessToken.getOtherClaims().
    get(org.keycloak.common.constants.KerberosConstants.GSS_DELEGATION_CREDENTIAL);

GSSCredential deserializedGssCredential = org.keycloak.common.util.KerberosSerializationUtils.
    deserializeCredential(serializedGssCredential);

// Create GSSContext to call other kerberos-secured services
GSSContext context = gssManager.createContext(serviceName, krb5Oid,
    deserializedGssCredential, GSSContext.DEFAULT_LIFETIME);

krb5.conf ファイルで 転送可能 な kerberos チケットを設定し、委譲された認証情報のサポートをブラウザーに追加する必要があることに注意してください。

Kerberos V5 プロトコルでは、レルム は Kerberos データベース (通常は LDAP サーバー) で定義される Kerberos プリンシパルのセットです。Kerberos プロトコルには、レルム間の信頼の概念があります。たとえば、2 つの Kerberos レルム A および B がある場合、クロスレルム信頼は、レルム A からのユーザーがレルム B のリソース (サービス) にアクセスできるようにします。これは、レルム B がレルム A を信頼することを意味します。

Red Hat Single Sign-On サーバーは、クロスレルム信頼のサポートを持ちます。そのためには、いくつかのことが必要になります。

問題が発生した場合には、追加のロギングを有効にして問題をデバッグすることが推奨されます。

emailAddress=(.*?)(?:,|$)

正規表現のフィルターは、Identity Source が、Match SubjectDN using regular expression または Match IssuerDN using regular expression のいずれかに設定されている場合にのみ適用されます。

ここでは、JBoss EAP/Undertow および Red Hat Single Sign-On Server を設定して、X.509 クライアント証明書認証を有効にする方法を説明します。

<security-realms>
    <security-realm name="ssl-realm">
        <server-identities>
            <ssl>
                <keystore path="servercert.jks"
                          relative-to="jboss.server.config.dir"
                          keystore-password="servercert password"/>
            </ssl>
        </server-identities>
        <authentication>
            <truststore path="truststore.jks"
                        relative-to="jboss.server.config.dir"
                        keystore-password="truststore password"/>
        </authentication>
    </security-realm>
</security-realms>

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
	....
    <server name="default-server">
	    <https-listener name="default"
                        socket-binding="https"
                        security-realm="ssl-realm"
                        verify-client="REQUESTED"/>
    </server>
</subsystem>

HTTP リクエストが Red Hat Single Sign-On サーバーに直接送信されると、JBoss EAP undertow サブシステムは SSL ハンドシェイクを確立し、クライアント証明書を展開します。その後、クライアント証明書はサーブレット仕様で指定されるように HTTP リクエストの javax.servlet.request.X509Certificate 属性に保存されます。Red Hat Single Sign-On X509 オーセンティケーターは、この属性から証明書をルックアップできます。

ただし、Red Hat Single Sign-On サーバーがロードバランサーまたはリバースプロキシーの背後で HTTP 要求をリッスンする場合は、クライアント証明書を抽出し、相互 SSL 接続を確立するプロキシーサーバーである可能性があります。リバースプロキシーは通常、認証されたクライアント証明書を基盤のリクエストの HTTP ヘッダーに配置し、バックエンド Red Hat Single Sign-On サーバーに転送します。この場合、Undertow に対するため、Red Hat Single Sign-On は、HTTP リクエストの属性ではなく、HTTP ヘッダーから X.509 証明書チェーンを検索できる必要があります。

Red Hat Single Sign-On がリバースプロキシーの背後にある場合は、通常 RHSSO_HOME/standalone/configuration/standalone.xml で x509cert-lookup SPI の代替プロバイダーを設定する必要があります。HTTP ヘッダーから証明書を検索する default プロバイダーとともに、haproxy と apache の 2 つの組み込みプロバイダーもあります。これについては、以下で説明します。

<spi name="x509cert-lookup">
    <default-provider>haproxy</default-provider>
    <provider name="haproxy" enabled="true">
        <properties>
            <property name="sslClientCert" value="SSL_CLIENT_CERT"/>
            <property name="sslCertChainPrefix" value="CERT_CHAIN"/>
            <property name="certificateChainLength" value="10"/>
        </properties>
    </provider>
</spi>

<spi name="x509cert-lookup">
    <default-provider>apache</default-provider>
    <provider name="apache" enabled="true">
        <properties>
            <property name="sslClientCert" value="SSL_CLIENT_CERT"/>
            <property name="sslCertChainPrefix" value="CERT_CHAIN"/>
            <property name="certificateChainLength" value="10"/>
        </properties>
    </provider>
</spi>

<spi name="x509cert-lookup">
    <default-provider>nginx</default-provider>
    <provider name="nginx" enabled="true">
        <properties>
            <property name="sslClientCert" value="ssl-client-cert"/>
            <property name="sslCertChainPrefix" value="USELESS"/>
            <property name="certificateChainLength" value="2"/>
        </properties>
    </provider>
</spi>

 ...
 server {
    ...
    ssl_client_certificate                  trusted-ca-list-for-client-auth.pem;
    ssl_verify_client                       optional_no_ca;
    ssl_verify_depth                        2;
    ...
    location / {
      ...
      proxy_set_header ssl-client-cert        $ssl_client_escaped_cert;
      ...
    }
    ...
}

...
    <profile>
        <subsystem xmlns="urn:jboss:domain:logging:3.0">
...
            <logger category="org.keycloak.authentication.authenticators.x509">
                <level name="TRACE"/>
            </logger>
            <logger category="org.keycloak.services.x509">
                <level name="TRACE"/>
            </logger>

WARNING: Don't use RequestDumpingHandler or TRACE logging in production.

$ curl https://[host][:port]/auth/realms/master/protocol/openid-connect/token \
       --insecure \
       --data "grant_type=password&scope=openid profile&username=&password=&client_id=CLIENT_ID&client_secret=CLIENT_SECRET" \
       -E /path/to/client_cert.crt \
       --key /path/to/client_cert.key

2FA の WebAuthn サポートの設定手順は、以下のようになります。

WebAuthn オーセンティケーターを登録した後、ユーザーは WebAuthn Authenticator を使用して条件付きサブフローで上記の認証フロー設定が使用されていることを前提としています。

WebAuthn オーセンティケーターを登録すると、Red Hat Single Sign-On は、この WebAuthn オーセンティケーターが生成した証明ステートメントを検証します。この検証プロセスでは、Red Hat Single Sign-On はこれをテストステートメントを信頼し、これを検証します。トラストアンカーの証明書が必要です。Red Hat Single Sign-On は Keycloak トラストストア を使用するため、事前にこれらの証明書をインポートする必要があります。

attestation statement trustworthiness 検証を省略する場合は、このトラストストアを無効にするか、WebAuthn ポリシーの設定アイテム "Attestation Conveyance Preference" を "none" に設定してください。

WebAuthn は頻繁に 2 要素認証に使用されますが、ファクター認証として使用することもできます。この場合、パスワードなし の WebAuthn 認証情報を持つユーザーは、パスワードなしで Red Hat Single Sign-On に対して認証できます。Red Hat Single Sign-Onでは、単一のレルムのコンテキストで、さらには単一の認証フローのコンテキストでも、パスワードなしおよび2 要素の認証メカニズムとして WebAuthn を使用できます。

管理者は、通常、WebAuthn パスワードレス認証でユーザーが登録するセキュリティーキーが異なる (通常はより強力な) 要件を満たす必要があることがあります。たとえば、そのセキュリティー鍵では、PIN を使用してそのセキュリティーキーに対する認証が必要になることがあり、セキュリティーキーは強力な認証局でテストする必要があります。

このような状況では、Red Hat Single Sign-On により、管理者は個別の WebAuthn パスワードレスポリシー を設定できます。別の認証タイプ WebAuthn Passwordless Authenticator と、別の必須アクションのタイプWebauthn Register Passwordless があります。

OIDC は、クライアントまたはアプリケーションがユーザーを認証し、アイデンティティー および アクセス トークンを受け取る方法は異なります。使用するパスは、アクセスを要求するアプリケーションまたはクライアントのタイプに大きく依存します。これらのフローはすべて OIDC および OAuth 2.0 仕様 に説明されるため、ここでは簡単な概要のみが提供されます。

以下は、Red Hat Single Sign-On がパブリッシュする OIDC エンドポイントの一覧です。これらの URL は、Red Hat Single Sign-On 以外のクライアントアダプターを使用して、認証サーバーと OIDC と通信させる場合に便利です。これらはすべて相対 URL と HTTP(S) プロトコル、hostname、通常は /auth で始まるパスである URL のルートです (例: https://localhost:8080/auth)。

これらはすべて、 {realm-name} をレルムの名前に置き換えます。

SAML は、認証プロトコルの実行時に XML ドキュメントを交換するさまざまな方法を定義します。Redirect および Post のバインディングはブラウザーベースのアプリケーションに対応します。ECP バインディングは、REST 呼び出しに対応します。他のバインディングタイプがありますが、Red Hat Single Sign-On はこれら 3 つのみをサポートします。

Red Hat Single Sign-On には、すべての SAML 要求に対してエンドポイントは 1 つしかありません。

http(s)://authserver.host/auth/realms/{realm-name}/protocol/saml

すべてのバインディングはこのエンドポイントを使用します。

Docker API ドキュメントの概要は、このプロセスについて説明していますが、Red Hat Single Sign-On 認証サーバーの視点では、簡単な概要が提供されます。

Red Hat Single Sign-On には、すべての Docker auth v2 要求に対してエンドポイントは 1 つしかありません。

http(s)://authserver.host/auth/realms/{realm-name}/protocol/docker-v2

OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled

相互 TLS は、TLS ハンドシェイク時に交換されるクライアント証明書でアクセストークンおよび更新トークンをバインドします。これにより、これらのトークンを盗む方法を見つけた攻撃者がトークンを取得することができなくなります。この種類のトークンは holder-of-key トークンと呼ばれます。ベアラートークンとは異なり、holder-of-key トークンの受信側は、トークンの送信側が正当であるかどうかを検証できます。

トークンリクエストで以下の条件が満たされると、Red Hat Single Sign-On はアクセストークンをバインドし、クライアント証明書で更新トークンを取得し、それらを holder-of-key トークンとして発行します。すべての条件が満たされないと、Red Hat Single Sign-On はトークンリクエストを拒否します。

Red Hat Single Sign-On で相互 TLS を有効にするには、「WildFly で相互 SSL の有効化」を参照してください。

以下の場合には、Red Hat Single Sign-On はアクセストークンまたは更新トークンを送信するクライアントを検証します。検証に失敗すると、Red Hat Single Sign-On はトークンを拒否します。

詳細は、OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens の「Mutual TLS Client Certificate Bound Access Tokens」を参照してください。

Proof Key for Code Exchange (PKCE)

攻撃者が正当なクライアントに発行した認可コードを盗むと、PKCE は攻撃者がそのコードに適用されるトークンを受信するのを防ぎます。

管理者は以下の 3 つのオプションを選択できます。

Proof Key for Code Exchange Code Challenge Method

詳細は、OAuth パブリッククライアントによるコード Exchange の RFC 7636 Proof キー を参照してください。

Signed and Encrypted ID Token Support

Red Hat Single Sign-On は、Json Web Encryption (JWE) 仕様に従って ID トークンを暗号化できます。管理者は、クライアントごとに ID トークンの暗号化を行うかどうかを決定できます。この機能は、デフォルトでは無効になっています。

ID トークンを暗号化するキーは、コンテンツ暗号化キー (CEK) と呼ばれます。Red Hat Single Sign-On およびクライアントは、どの CEK が使用されるかと、その配信方法をネゴシエートする必要があります。これを行うには Key Management Mode と呼ばれます。

JWE 仕様は、キー管理モード の 5 種類のキー管理モードを決定します。Red Hat Single Sign-On は、その中における鍵暗号化をサポートします。

Key Encryption では、クライアントは非対称暗号のペアを生成します。公開鍵は CEK の暗号化に使用されます。Red Hat Single Sign-On は、ID トークンごとに CEK を生成し、この生成された CEK で ID トークンを暗号化し、このクライアントの公開鍵でこの CEK を暗号化します。クライアントはこの暗号化された CEK を秘密鍵で復号化し、CEK を復号化して ID トークンを復号化します。そのため、クライアント以外のユーザーは ID トークンを復号化できません。

クライアントは、CEK を Red Hat Single Sign-On で暗号化するために公開鍵を渡す必要があります。Red Hat Single Sign-On は、クライアントが提供する URL からの公開鍵のダウンロードをサポートします。クライアントは、Json Web Keys (JWK) 仕様に従って公開鍵を提供する必要があります。これを実行する方法は、「Confidential Client Credentials」の「Signed JWT」で定義します。詳細な手順は以下のとおりです。

キー暗号化のアルゴリズムは、Json Web Algorithm (JWA) 仕様で定義されています。Red Hat Single Sign-On は、デフォルトパラメーター (RSA-OAEP) を使用して RSAES-PKCS1-v1_5 (RSA1_5) および RSAES OAEP をサポートします。このアルゴリズムを選択する詳細な手順は以下のとおりです。

CEK による ID トークン暗号化アルゴリズムは、JWA 仕様にも定義されます。Red Hat Single Sign-On は、128 ビットキー (A128GCM) を使用した AES_128_CBC_HMAC_SHA_256 認証暗号化 (A128CBC-HS256) および AES GCM に対応しています。このアルゴリズムを選択する詳細な手順は以下のとおりです。

クライアントの Settings タブでクライアントの access type を confidential に設定した場合は、新しい Credentials タブが表示されます。このようなクライアントの処理の一環として、クライアントのクレデンシャルを設定する必要があります。

Client Authenticator リストボックスは、機密クライアントに使用する認証情報のタイプを指定します。デフォルトはクライアント ID およびシークレットになります。シークレットは自動的に生成され、Regenerate Secret ボタンを使用すると、必要に応じてこのシークレットを再作成します。

または、シークレットではなく、署名済みの Json Web Token (JWT) または x509 証明書の検証 (別名 Mutual TLS) を使用することができます。

この認証情報タイプを選択すると、クライアントの秘密鍵と証明書も生成する必要があります。秘密鍵は JWT に署名するために使用されます。一方、証明書は、署名の検証にサーバーによって使用されます。Generate new keys and certificate ボタンをクリックして、このプロセスを開始します。

これらのキーを生成すると、Red Hat Single Sign-On は証明書を保存し、クライアントが使用する秘密鍵と証明書をダウンロードする必要があります。必要なアーカイブ形式を選択し、秘密鍵とストアのパスワードを指定します。

外部ツールを使用してこれらを生成したり、クライアントの証明書をインポートするだけです。

インポートできる形式は複数あります。証明書を保存するアーカイブ形式を選択し、ファイルを選択してから Import ボタンをクリックします。

最後に、JWKS URL の使用 を選択している場合は、証明書をインポートする必要はありません。このような場合には、クライアントが JWK 形式で公開鍵を公開する URL を指定できます。Red Hat Single Sign-On 側では、クライアントがキーを変更すると、Red Hat Single Sign-On 側ですべてのキーを再インポートする必要がないため、柔軟性があります。

Red Hat Single Sign-On アダプターで保護されたクライアントを使用している場合は、https://myhost.com/myapp がクライアントアプリケーションのルート URL であると仮定して、https://myhost.com/myapp/k_jwks のように JWKS の URL を設定することができます。詳細は『サーバー開発者ガイド』を参照してください。

このクライアントシークレットは、クライアントによって JWT に署名するために使用されます。

バリデーターは、証明書の Subject DN フィールドも、regexp 検証式を設定して確認します。いくつかのユースケースでは、すべての証明書を受け入れるだけで十分です。この場合は、(.*?)(?:$) 式を使用できます。

Red Hat Single Sign-On がリクエストからクライアント ID を取得する方法は 2 つあります。最初のオプションはクエリーの client_id パラメーターです (OAuth 2.0 仕様 のセクション 2.2 で説明されています)。2 つ目の方法として、client_id をフォームパラメーターとして指定します。

各 OIDC クライアントには、アクセストークンの取得を可能にする組み込み service account があります。これは、「クライアント認証情報の付与」の OAuth 2.0 仕様で説明されています。この機能を使用するには、クライアントの Access Type を confidential に設定する必要があります。これを実行すると、Service Accounts Enabled スイッチが表示されます。このスイッチをオンにする必要があります。また、クライアントのクレデンシャルを設定されていることを確認してください。

このクライアントを使用するには、有効な confidential Client を登録する必要があります。また、このクライアントでは、Red Hat Single Sign-On 管理コンソールでスイッチ Service Accounts Enabled を確認する必要があります。Service Account Roles タブは、このクライアントの代わりに取得したサービスアカウントで利用可能なロールを設定できます。Full Scope Allowed が許可されていない限り、このクライアントのロールスコープマッピング (Scope タブで利用可能なロールを持っている必要があることを覚えておいてください。通常のログインでは、アクセストークンからのロールは以下の交差部分になります。

呼び出す REST URL は /auth/realms/{realm-name}/protocol/openid-connect/token です。この URL の呼び出しは POST リクエストで、クライアントクレデンシャルを投稿する必要があります。デフォルトでは、クライアント認証情報は Authorization: Basic ヘッダーでクライアントの clientId および clientSecret によって表されますが、署名付きの JWT アサーションやその他のクライアント認証用のカスタムメカニズムを使ってクライアントを認証することもできます。OAuth2 仕様に従って、grant_type=client_credentials パラメーターを使用する必要があります。

たとえば、サービスアカウントを取得する POST 呼び出しは以下のようになります。

    POST /auth/realms/demo/protocol/openid-connect/token
    Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=
    Content-Type: application/x-www-form-urlencoded

    grant_type=client_credentials

応答は、OAuth 2.0 仕様の標準の JSON ドキュメントです。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60
}

デフォルトでは、アクセストークンのみが返されます。更新トークンが返されず、認証の成功時に Red Hat Single Sign-On 側でユーザーセッションも作成されません。更新トークンがないため、アクセストークンの期限が切れると再認証が必要ですが、セッションはデフォルトで作成されないため、Red Hat Single Sign-On サーバー側で追加のオーバーヘッドは保証されません。

このような状況では、ログアウトは必要ありません。ただし、発行されたアクセストークンは、「OpenID Connect Endpoints」セクションで説明するように、OAuth2 Revocation Endpoint にリクエストを送信して取り消すことができます。

Red Hat Single Sign-On がデプロイされる典型的な環境は、一般的に、認証に Red Hat Single Sign-On を使用する 秘密 または 公開 クライアントアプリケーション (フロントエンドクライアントアプリケーション) のセットで構成されています。

また、フロントエンドクライアントアプリケーションからの要求に対応し、リソースを提供する サービス (OAuth 2 仕様では Resource Servers と呼ばれる) もあります。これらのサービスは通常、特定のリクエストに対して認証を行うために、アクセストークン (Bearer トークン) を送信する必要があります。このトークンは、Red Hat Single Sign-On へのログインを試みる際に、フロントエンドアプリケーションによって取得されていました。

サービス間の信頼が低い環境では、以下のシナリオが発生する可能性があります。

このフローは、サービス間の信頼レベルの高い環境においては問題になる可能性があります。ただし、サービス間の信頼が低くなる他の環境では、この問題が発生する可能性があります。

上記の例にあるように、アクセストークンが誤用しないようにするため、トークンでオーディエンスを制限し、トークンに関するオーディエンスを検証するようにサービスを設定することを推奨します。これが実行されると、以下のように上のフローが変更されます。

クライアントが後で good-service を呼び出す場合は、scope=good-service で SSO ログインを発行し、別のトークンを取得する必要があります。返されるトークンには、対象として good-service が含まれます。

"audience": [ "good-service" ]

さらに、good-service を呼び出すことができます。

IDP Initiated Login は、特定のアプリケーション/クライアントにログインする Red Hat Single Sign-On サーバーでエンドポイントを設定することができる機能です。クライアントの Settings タブで、IDP Initiated SSO URL Name を指定する必要があります。これは、空白のない単純な文字列です。この後、root/auth/realms/{realm}/protocol/saml/clients/{url-name} の URL でクライアントを参照できます。

IDP によって開始されたログイン実装は REDIRECT バインディングで POST を優先します (詳細は saml バインディングを参照)。そのため、最終バインディングおよび SP URL は以下の方法で選択されます。

クライアントに特別なリレー状態が必要な場合は、IDP Initiated SSO Relay State フィールドの 設定 タブで設定することもできます。または、ブラウザーは RelayState クエリーパラメーター (つまり root/auth/realms/{realm}/protocol/saml/clients/{url-name}?RelayState=thestate) にリレー状態を指定することもできます。

アイデンティティーブローカー を使用する場合は、外部 IDP からクライアントの IDP 開始ログインを設定できます。前述のように、ブローカー IDP で IDP 開始ログインに実際のクライアントが設定されている。外部 IDP は、ブローカーを示す特別な URL を参照するアプリケーションの IDP Initiated ログインにクライアントを設定し、仲介 IDP で選択したクライアントの IDP Initiated ログインエンドポイントを表す必要があります。これは、外部 IDP のクライアント設定を意味します。

ブローカー IDP から外部 IDP のクライアント設定に基本的なクライアント設定をインポートできることに注意してください。ブローカー IDP でアイデンティティープロバイダーの設定から利用可能な SP 記述子 を使用し、clients/client-id をエンドポイント URL に追加するだけです。

SAML 2.0 クライアントを手動で登録するのではなく、標準の SAML エンティティーの XML ファイルを使用してインポートできます。クライアントの追加ページには Import オプションがあります。

ファイルの選択 ボタンをクリックして、エンティティー記述子ファイルを読み込みます。そこに情報をすべて確認して、すべてが正しく設定されていることを確認する必要があります。

mod-auth-mellon などの SAML クライアントアダプターの中には、IDP の XML エンティティー記述子が必要です。この公開 URL (root/auth/realms/{realm}/protocol/saml/descriptor) に移動して、これを取得できます。

マッパー実装には優先順位があります。この優先順位はマッパーの設定プロパティーではなく、マッパーの具体実装のプロパティーになります。

マッパーは、マッパーのリストの順序で並び替え、トークンまたはアサーションの変更は、最初に適用される順を使用して適用されます。つまり、他の実装に依存する実装は、必要な順序で処理されます。

たとえば、まずトークンに含まれるロールを計算する場合は、まずそれらのロールに基づいてオーディエンスを解決します。次に、トークンにすでに利用可能なロールおよびオーディエンスを使用する JavaScript スクリプトを処理します。

ユーザーセッションの詳細はマッパー経由で行われ、さまざまな基準によって異なります。クライアントで機能を使用または有効化すると、ユーザーセッションの詳細が自動的に含まれます。Add builtin ボタンをクリックして、セッションの詳細を含めることもできます。

切り替え後のユーザーセッションは以下の詳細を提供します。

サービスアカウントセッションは以下の詳細を提供します。

Script Mapper を使用すると、ユーザー定義の JavaScript コードを実行して要求をトークンにマッピングできます。サーバーにスクリプトをデプロイする方法は、「JavaScript プロバイダー」を参照してください。

スクリプトをデプロイしたら、利用可能なマッパーの一覧からデプロイしたスクリプトを選択できるはずです。

クライアントスコープを作成する場合は、Protocol を選択する必要があります。同じプロトコルを使用するクライアントのみを、このクライアントスコープにリンクできます。

新しいレルムを作成したら、メニューに事前定義 (組み込み) クライアントスコープの一覧があることを確認できます。

クライアントスコープ (offline_access) は、クライアントがオフライントークンを取得する場合に便利です。Offline Access セクション または OpenID Connect 仕様 でオフライントークンについて説明します。ここで、scope パラメーターは offline_access の値で定義されます。

クライアントスコーププロファイル、profile、email、address、および phone は、OpenID Connect 仕様 にも定義されています。これらのクライアントスコープにはロールスコープのマッピングが定義されていませんが、一部のプロトコルマッパーが定義されており、これらのマッパーは OpenID Connect 仕様で定義される要求に対応します。

たとえば、phone クライアントのスコープを開き、Mappers タブを開くと、プロトコルマッパーが表示されます。これは、スコープの phone の仕様で定義される要求に対応します。

phone クライアントスコープがクライアントにリンクされると、そのクライアントは phone クライアントスコープで定義されたすべてのプロトコルマッパーを自動的に継承します。このクライアントに発行されたアクセストークンには、ユーザーに関する電話番号 (電話番号が定義されているか) が含まれます。

組み込みクライアントスコープには、仕様に定義されているプロトコルマッパーを正確に含まれますが、クライアントスコープを編集し、プロトコルマッパー (またはロールの範囲) の作成/更新/削除を行うことができます。

クライアントスコープ ロール は OpenID Connect 仕様に定義されず、アクセストークンの スコープ 要求に自動的に追加されません。このクライアントスコープにはいくつかのマッパーがあります。これは、ユーザーのロールをアクセストークンに追加するために使用され、Audience セクションに記載されているように、1 つ以上のクライアントロールを持つクライアントのオーディエンスを追加するために使用されます。

クライアントスコープの web-origins も OpenID Connect 仕様には定義されず、scope 要求には追加されません。これは、許可される Web オリジンをアクセストークン allowed-origins 要求に追加するために使用されます。

クライアント scopemicroprofile-jwt は MicroProfile/JWT Auth Specification で定義された要求を処理するために作成されています。このクライアントスコープは、upn 要求のユーザープロパティーマッパーと、groups クレームのレルムロールマッパーを定義します。これらのマッパーは、MicroProfile/JWT 固有の要求を作成するために、必要に応じてこれらのマッパーを変更できます。

クライアントスコープには、consent 画面に関連するオプションが含まれます。これらのオプションは、リンク先のクライアントが合意を必要とするように設定されている場合のみ便利です (Consent Required スイッチがクライアントで有効になっている場合)。

クライアントスコープとクライアント間のリンクは、特定のクライアントの Client Scopes タブで設定されます。クライアントスコープとクライアント間をリンクする方法は 2 つあります。

scope=openid phone

クライアントのタブ Mappers および Scope には、このクライアントのみに宣言されたプロトコルマッパーとロールスコープマッピングが含まれます。クライアントスコープから継承されるマッパーおよびスコープのマッピングは含まれません。ただし、有効なプロトコルマッパーが (クライアント自体で定義されるプロトコルマッパー)、リンクされたクライアントスコープから継承するものと、特定クライアントのトークンを生成するときに使用される有効なロールスコープマッピングを確認すると便利です。

クライアントの Client Scopes タブをクリックしてからサブタブ Evaluate をクリックすると、これらすべてが表示されます。ここから、適用する任意のクライアントスコープを選択できます。また、これにより scope パラメーターの値も表示されます。これは、アプリケーションから Red Hat Single Sign-On OpenID Connect 承認エンドポイントに送信する必要があります。

特定のユーザーのトークンを発行すると、クライアントスコープは、ユーザーがそれを使用できる場合のみ適用されます。クライアントスコープにロールスコープマッピングがそれ自体に定義されている場合は、各ユーザーは自動的にこのクライアントスコープを使用できます。ただし、クライアントスコープにそれ自体で定義されているロールスコープのマッピングがある場合は、ユーザーは少なくとも 1 つのロールのメンバーである必要があります。つまり、ユーザーロールとクライアントスコープのロール間に交差部分が必要です。この交差部分の評価時に、複合ロールが考慮されます。

ユーザーがクライアントスコープを使用できない場合、トークンの生成時にプロトコルマッパーまたはロールスコープマッピングは使用されなくなり、トークンの範囲にクライアントスコープは表示されません。

Realm Default Client Scopes を使用すると、新規作成されたクライアントへ自動的にリンクされるクライアントスコープのセットを定義できます。

左側のメニュー項目 Client Scopes を開き、Default Client Scopes を選択します。

ここから、新規作成したクライアントに Default Client Scopes として追加するクライアントスコープを選択し、Optional Client Scopes を新規作成したクライアントに設定します。

クライアントが作成されると、必要に応じて、デフォルトのクライアントスコープのリンクを解除できます。これは、デフォルトのロールを削除する方法と似ています。

scope は数カ所時に Red Hat Single Sign-On で使用されます。さまざまなスコープの発生は相互に関係しますが、異なるコンテキストと意味を持つ可能性があります。ここでは、Red Hat Single Sign-On で使用されるさまざまな scopes を説明します。

デフォルトロールでは、ユーザーが Identity Brokering を使用して新規に作成またはインポートされると、ユーザーロールのマッピングを自動的に割り当てることができます。デフォルトのロールを指定するには、左メニュー項目 Roles に移動し、Default Roles タブをクリックします。

スクリーンショットから分かるように、デフォルトで多くのデフォルトロールが設定されています。

master レルムには、2 つのレルムレベルのロールがあります。以下のとおりです。

admin ロールを持つユーザーはスーパーユーザーであり、サーバー上のレルムを管理するためにフルアクセスできます。create-realm ロールを持つユーザーは、新しいレルムを作成できます。このユーザーは、作成する新しいレルムに完全アクセスできます。

master レルム内の管理者ユーザーには、システムの他のレルムに対して管理権限を付与できます。Red Hat Single Sign-On の各レルムは、master レルムのクライアントで表されます。クライアントの名前は <realm name>-realm です。これらのクライアントには、クライアントレベルのロールが定義されており、個別のレルムを管理するアクセスレベルを定義します。

利用可能なロールは以下のとおりです。

ユーザーに必要なロールを割り当てると、管理コンソールのその特定の部分のみを使用できます。

最初に、管理者がクライアントを 1 つ、クライアントを 1 つだけ管理できるようにします。この例では、test という名前のレルムと、sales-application というクライアントがあります。レルム test では、そのレルムのパーミッションで、そのアプリケーションを管理する権限をユーザーに付与します。

もう 1 つのことは、管理者がユーザーに割り当てることのできるロールセットを制限することです。最後のサンプルを続行して、'sales-admin' ユーザーのパーミッションセットを拡張して、このアプリケーションにアクセスできるユーザーも制御できるようにします。細かいパーミッションにより、sales-admin が sales-application への特定のアクセス権限を付与するロールのみを割り当てることができます。また、管理者はロールのみをマッピングでき、他のタイプのユーザー管理を実行しないように制限することもできます。

sales-application が 3 つの異なるクライアントロールを定義しました。

sales-admin ユーザーがこれらのロールをシステムの任意のユーザーにマッピングできるようにします。これを実行する最初のステップでは、ロールが admin でマップされるようにします。viewLeads ロールをクリックすると、このロールの Permissions タブがあることを確認できます。

そのタブをクリックし、Permissions Enabled を on にすると、ポリシーを適用することのできる多数のアクションが表示されます。

関心のあるのは map-role です。このパーミッションをクリックし、上記の例で作成されたのと同じ User Policy を追加します。

行った内容は、sales-admin が viewLeads ロールをマッピングできることを示しています。何も指定していないユーザーは、管理者がこのロールをマップできるユーザーで指定します。このレルムの管理コンソールの Users セクションに移動する必要があります。左側のメニュー項目 Users をクリックすると、レルムのユーザーインターフェースが表示されます。Permissions タブが表示されるはずです。それをクリックして有効にします。

対象のパーミッションは map-roles です。これは、管理者のみがロールをユーザーにマッピングできるようにする制限ポリシーです。map-roles パーミッションをクリックし、作成したユーザーポリシーを再度追加すると、sales-admin はロールをどのユーザーにもマッピングできます。

最後に、view-users ロールを sales-admin に追加します。これにより、管理者は、sales-application ロールを追加するレルム内のユーザーを表示できます。

特定のクライアントやクライアントの特定のロールの管理以外に、より詳細なパーミッションを設定することが可能です。本章では、レルムに設定できるパーミッションタイプ全体を定義します。

鍵を定期的にローテーションすることが推奨されます。これを実行するには、既存のアクティブなキーよりも優先度が高い新しいキーを作成して開始する必要があります。または、同じ優先順位で新しいキーを作成し、以前のキーパッシブを作成します。

新しい鍵が利用可能になると、新しいトークンと cookie はすべて新しいキーで署名されます。ユーザーがアプリケーションに対して認証されると、SSO クッキーは新しい署名で更新されます。OpenID Connect トークンを更新すると、新しいキーで新たなトークンが署名されます。つまり、時間が経過するとすべての Cookie とトークンが新しいキーを使用し、古いキーを削除できる間に続きます。

古いキーを削除するまでの待機時間は、セキュリティー間のトレードオフであり、すべての cookie とトークンが更新されるようにします。通常は、数週間後に古いキーをドロップすることができます。追加された新しい鍵の間にアクティブでアクティブで、以前のキーが削除されるユーザーは再認証する必要があります。

これはオフライントークンにも適用されます。これらのアプリケーションが古いキーが削除される前にトークンを更新する必要のあることを確認するには、アプリケーションを更新します。

ガイドラインとして、3 〜 6 か月ごとに新しいキーを作成し、新規キーの作成後に古いキー 1-2 か月を削除することが推奨されます。

新しいく生成されたキーペアを追加するには、Providers を選択して、ドロップダウンから rsa-generated を選択します。新たなキーペアがアクティブなキーペアになるように、優先度を変更することができます。より小さいキーまたは大きい鍵が必要な場合は、keysize を変更することもできます (デフォルトは 2048 で、サポートされている値は 1024、2048、および 4096)。

Save をクリックして、新しいキーを追加します。これにより、自己署名証明書を含む新しいキーペアが生成されます。

プロバイダーの優先度を変更すると、キーが再生成されますが、キーサイズを変更する場合はプロバイダーを編集し、新しいキーが生成されます。

別のユーザーが取得したキーペアと証明書を追加し、Providers を選択し、ドロップダウンから rsa を選択します。新たなキーペアがアクティブなキーペアになるように、優先度を変更することができます。

Private RSA Key の Select file をクリックして秘密鍵をアップロードします。ファイルは PEM 形式でエンコードされる必要があります。公開鍵から自動的に抽出されるので、公開鍵をアップロードする必要はありません。

キーの署名済み証明書がある場合は、X509 Certificate の横にある Select file をクリックします。これを省略できます。これを行わないと、自己署名証明書が生成されます。

ホストの Java キーストアファイルに保存されている鍵と証明書を追加するには、Provider を選択し、ドロップダウンから java-keystore を選択します。新たなキーペアがアクティブなキーペアになるように、優先度を変更することができます。

Keystore、Keystore Password、Key Alias、および Key Password の値を入力し、Save をクリックします。

Active でキーペアを見つけ、Provider 列でプロバイダーをクリックします。これにより、キープロバイダーの設定画面に移動します。Active をクリックして OFF を有効にし、Save をクリックします。鍵はアクティブではなくなり、署名の検証のみに使用できます。

Active でキーペアを見つけ、Provider 列でプロバイダーをクリックします。これにより、キープロバイダーの設定画面に移動します。Enabled をクリックして OFF をオンにし、Save をクリックします。この鍵は有効ではなくなります。

または、プロバイダーを Providers テーブルから削除できます。

Red Hat Single Sign-On にはローカルに保存された署名キーがあり、クライアントアプリケーション、ユーザー、またはその他のエンティティーと共有されることはありません。ただし、レルム署名鍵が不正であると思われる場合は、上記のように最初に新しいキーペアを生成し、不正アクセスのキーペアを即座に削除する必要があります。

その後、クライアントアプリケーションが、侵害された鍵によって署名されたトークンを受け入れないようにするには、管理コンソールから実行できるレルムの not-before ポリシーを更新し、プッシュする必要があります。新しいポリシーをプッシュすることで、クライアントアプリケーションが侵害された鍵によって署名された既存のトークンを受け入れないようにすることができますが、クライアントアプリケーションも Red Hat Single Sign-On から新しいキーペアをダウンロードするように強制するため、不正アクセスされたキーによって署名されたトークンは有効になりません。REST および機密クライアントには Admin URL を設定する必要があるため、Red Hat Single Sign-On はプッシュされない not-before ポリシーに関して要求を送信できることに注意してください。

Bitbucket を使用したログインを有効にするためには、多くの手順を完了する必要があります。

まず、左側のメニュー項目 Identity Providers 開き、Add provider ドロップダウンリストから Bitbucket を選択します。これにより、Add identity provider ページが表示されます。

Save をクリックする前に、Bitbucket から Client ID および Client Secret を取得する必要があります。

Add consumer ボタンをクリックします。

Red Hat Single Sign-On Add Identity Provider ページから Redirect URI をコピーし、Bitbucket Add OAuth Consumer ページの Callback URL フィールドに入力します。

同じページで、Account の下の Email および Read ボックスにマークを付け、アプリケーションがユーザーのメールを読み取ることを許可します。

登録が完了したら、Save をクリックします。これにより、Bitbucket でアプリケーション管理ページが開きます。このページからクライアント ID とシークレットを検索し、Red Hat Single Sign-On の Add identity provider ページにそのクライアント ID とシークレットを入力できます。Save をクリックします。

Facebook を使用したログインを有効にするためには、多くの手順を完了する必要があります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから Facebook を選択します。これにより、Add identity provider ページが表示されます。

Facebook から Client ID および Client Secret を取得する必要があるため、まだ保存はクリックできません。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを Facebook に提供する必要があるため、この URI をクリップボードにコピーします。

ログインを有効にするには、最初に Facebook Developer Console でプロジェクトとクライアントを作成する必要があります。

コンソールにログインしたら、My Apps という画面の右上にあるプルダウンメニューが表示されます。Add a New App メニュー項目を選択します。

Website アイコンを選択します。Skip and Create App ID ボタンをクリックします。

メールアドレスとアプリケーションカテゴリーは必須フィールドです。この作業が完了したら、アプリケーションのダッシュボードに移動します。左側のメニュー項目の Settings をクリックします。

このページの最後にある + Add Platform ボタンをクリックし、Website アイコンを選択します。Red Hat Single Sign-On の Add identity provider ページから、Facebook の Website 設定ブロックの Site URL に Redirect URI をコピーアンドペーストします。

その後、Facebook app public を作成する必要があります。左メニューの項目の App Review をクリックし、ボタンを "Yes" に切り替えます。

このページから App ID および App Secret を取得して、Red Hat Single Sign-On の Add identity provider ページを入力する必要もあります。これを取得するには、左側のメニュー項目 Dashboard をクリックし、App Secret の下にある Show をクリックします。Red Hat Single Sign-On に戻り、それらの項目を指定し、最後に Facebook Identity Provider を保存します。

Facebook の Add identity provider ページで注意する設定オプションの 1 つが Default Scopes フィールドです。このフィールドでは、このプロバイダーでの認証時にユーザーが承認する必要のあるスコープを手動で指定することができます。スコープの全一覧については、https://developers.facebook.com/docs/graph-api を参照してください。デフォルトでは、Red Hat Single Sign-On は email の範囲を使用します。

GitHub でログインを有効にするために実行する必要のある手順が複数あります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから GitHub を選択します。これにより、Add identity provider ページが表示されます。

GitHub から Client ID および Client Secret を取得する必要があるため、Save はクリックできません。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを GitHub に提供する必要があるため、この URI をクリップボードにコピーします。

GitHub でのログインを有効にするには、まず GitHub Developer アプリケーション でアプリケーションプロジェクトを登録する必要があります。

Register a new application をクリックします。

Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーし、GitHub の Register a new OAuth application ページの Authorization callback URL フィールドに入力する必要があります。このページの完了後、アプリケーションの管理ページに移動します。

このページからクライアント ID およびシークレットを取得する必要があります。これにより、Red Hat Single Sign-On の Add identity provider ページでクライアント ID とシークレットを入力できます。Red Hat Single Sign-On に戻り、その項目を指定します。

GitLab でログインを有効にするために実行する必要のある手順が複数あります。

まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから GitLab を選択します。これにより、Add identity provider ページが表示されます。

Save をクリックする前に、GitLab から Client ID および Client Secret を取得する必要があります。

GitLab でログインを有効にするには、まず GitLab でアプリケーションを OAuth2 認証サービスプロバイダーとして登録する必要があります。

Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーし、GitLab Add 新規アプリケーションページの Redirect URI フィールドにその URI を入力します。

登録が完了したら、Save application をクリックします。これにより、GitLab でアプリケーション管理ページが開きます。このページからクライアント ID とシークレットを検索し、Red Hat Single Sign-On の Add identity provider ページにそのクライアント ID とシークレットを入力できます。

終了するには、Red Hat Single Sign-On に戻り、そのクライアント ID とシークレットを入力します。Save をクリックします。

Google でログインを有効にするために実行する必要のある手順が複数あります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから Google を選択します。これにより、Add identity provider ページが表示されます。

Google から クライアント ID および クライアントシークレット を取得する必要があるため、保存はクリックできません。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを Google に提供する必要があるため、この URI をクリップボードにコピーします。

Google でログインを有効にするには、最初に Google Developer Console でプロジェクトとクライアントを作成する必要があります。クライアント ID およびシークレットを Red Hat Single Sign-On 管理コンソールにコピーする必要があります。

まず、Google でプロジェクトを作成する方法を説明します。

Google Developer Console にログインします。

Create Project ボタンをクリックします。Project name と Project ID に任意の値を使用してから Create ボタンをクリックします。プロジェクトが作成されるまで待機します (しばらく時間がかかる場合があります)。作成されると、プロジェクトのダッシュボードに移動します。

次に、Google Developer Console の API & Services セクションに移動します。この画面で、Credentials の管理 に移動します。

Red Hat Single Sign-On から Google にログインすると、Google から consent 画面が表示され、Red Hat Single Sign-On がユーザープロファイルの情報を表示できるかどうかをユーザーに尋ねます。そのため、Google では、シークレットを作成する前に製品に関する基本的な情報が必要になります。新規プロジェクトでは、OAuth consent screen を設定しておく必要があります。

非常に基本的な設定では、アプリケーション名を入力します。また、このページの Google API のスコープなどの追加情報を設定することもできます。

次の手順では、OAuth クライアント ID およびクライアントシークレットを作成します。Credentials 管理に戻り、Credentials タブに移動し、Create credentials ボタンの下にある OAuth client ID を選択します。

その後、Create OAuth client ID ページに移動します。アプリケーションタイプとして Web application を選択します。クライアントの名前を指定します。Redirect URI を Red Hat Single Sign-On の Add Identity Provider ページから Authorized redirect URIs フィールドにコピーアンドペーストする必要があります。この作業を行ったら、Create ボタンをクリックします。

Create をクリックすると、Credentials ページに移動します。新しい OAuth 2.0 Client ID をクリックし、新しい Google Client の設定を表示します。

このページからクライアント ID およびシークレットを取得する必要があります。これにより、Red Hat Single Sign-On の Add identity provider ページでクライアント ID とシークレットを入力できます。Red Hat Single Sign-On に戻り、その項目を指定します。

Google の Add identity provider ページで注意する設定オプションの 1 つが Default Scopes フィールドです。このフィールドでは、このプロバイダーでの認証時にユーザーが承認する必要のあるスコープを手動で指定することができます。スコープの全一覧については、https://developers.google.com/oauthplayground/ を参照してください。デフォルトでは、Red Hat Single Sign-On は openid、profile、email のスコープを使用します。

組織が G Suite を使用し、組織のメンバーのみへのアクセスを制限する場合には、Hosted Domain フィールドに G Suite に使用されるドメインを入力してこれを有効にする必要があります。

LinkedIn でログインを有効にするために実行する必要のある手順が複数あります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから LinkedIn を選択します。これにより、Add identity provider ページが表示されます。

Client ID および Client Secret を LinkedIn から取得する必要があるため、まだ保存をクリックします。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際に LinkedIn が提供されるため、この URI をクリップボードにコピーする必要があります。

LinkedIn でログインを有効にするには、まず LinkedIn Developer Network でアプリケーションを作成する必要があります。

Create Application ボタンをクリックします。これにより、Create a New Application ページが表示されます。

フォームに適切な値を入力し、Submit ボタンをクリックします。これにより、新規アプリケーションの設定ページに移動します。

Default Application Permissions セクションで、r_basicprofile および r_emailaddress を選択します。Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーして、LinkedIn アプリケーション設定ページの OAuth 2.0 Authorized Redirect URLs フィールドに入力する必要があります。この作業を行ったら、忘れずに Update ボタンをクリックしてください。

次に、このページからクライアント ID およびシークレットを取得する必要があります。これにより、Red Hat Single Sign-On の Add identity provider ページでクライアント ID とシークレットを入力できます。Red Hat Single Sign-On に戻り、その項目を指定します。

Microsoft へのログインを有効にするには、完了する必要がある多くの手順があります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから Microsoft を選択します。これにより、Add identity provider ページが表示されます。

Microsoft から Client ID および Client Secret を取得する必要があるため、保存はクリックできません。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際に、Microsoft に提供する必要があります。したがって、この URI をクリップボードにコピーする必要があります。

Microsoft アカウントを使用したログインを有効にするには、まず OAuth アプリケーションを Microsoft に登録する必要があります。URL Microsoft Application Registration に移動します。

アプリケーション名を入力し、Create application をクリックします。これにより、新規アプリケーションのアプリケーション設定ページに移動します。

Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーし、Microsoft アプリケーションページの Redirect URIs フィールドに追加する必要があります。Add Url ボタンをクリックし、変更を 保存 します。

最後に、このページからアプリケーション ID とシークレットを取得する必要があります。これにより、Red Hat Single Sign-On の Add identity provider ページに戻すことができます。Red Hat Single Sign-On に戻り、その項目を指定します。

OpenShift でログインを有効にするために実行する必要のある手順をいくつか紹介します。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから OpenShift を選択します。これにより、Add identity provider ページが表示されます。

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: v1
metadata:
 name: kc-client 1
secret: "..." 2
redirectURIs:
 - "http://www.example.com/" 3
grantMethod: prompt 4
')

oc create コマンドで定義されるクライアント ID およびシークレットを使用して、Red Hat Single Sign-On の Add identity provider プロバイダーページで再度入力します。Red Hat Single Sign-On に戻り、その項目を指定します。

詳細ガイドは、公式の OpenShift ドキュメントを参照してください。

OpenShift 4 でログインを有効にするためにには、いくつかの手順を実行する必要があります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから OpenShift v4 を選択します。これにより、Add identity provider ページが表示されます。

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: v1
metadata:
 name: keycloak-broker 1
secret: "..." 2
redirectURIs:
 - "<copy pasted Redirect URI from OpenShift 4 Identity Providers page>" 3
grantMethod: prompt 4
')

oc create コマンドで定義されるクライアント ID とシークレットを使用して、Red Hat Single Sign-On の Add identity provider ページで再度入力します。Red Hat Single Sign-On に戻り、その項目を指定します。

詳細ガイドは、公式の OpenShift ドキュメントを参照してください。

PayPal でログインを有効にするには、完了している手順が複数あります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから PayPal を選択します。これにより、Add identity provider ページが表示されます。

まだ保存することはできません。これは、PayPal からClient ID および Client Secret を取得する必要はないためです。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを PayPal に提供する必要があるため、この URI をクリップボードにコピーします。

PayPal でログインを有効にするには、まず PayPal Developer アプリケーション でアプリケーションプロジェクトを登録する必要があります。

Create App ボタンをクリックします。

これで、アプリケーション設定ページに移動します。

Stack Overflow でログインを有効にするには、完了すべき多くのステップがあります。まず、Identity Providers の左側のメニュー項目に移動し 、Add provider ドロップダウンリストから Stack Overflow を選択します。これにより、Add identity provider ページが表示されます。

Stack Overflow でログインを有効にするには、最初に StackApps で OAuth アプリケーションを登録する必要があります。Stack Apps URL およびログインでアプリケーションを登録します。

アプリケーション名とアプリケーションの OAuth ドメイン名を入力し、Register your Application をクリックします。他の項目に必要なものを入力します。

最後に、このページからクライアント ID、シークレット、およびキーを取得し、Red Hat Single Sign-On Add Add identity provider にそれを戻す必要があります。Red Hat Single Sign-On に戻り、その項目を指定します。

Twitter でログインを有効にするために必要な多くのステップがあります。最初に、Identity Providers の左側のメニュー項目に移動し、Add provider ドロップダウンリストから Twitter を選択します。これにより、Add identity provider ページが表示されます。

まだ保存することはできません。これは、Twitter から Client ID および Client Secret を取得する必要はないためです。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを Twitter に提供する必要があるため、この URI をクリップボードにコピーします。

Twitter によるログインを有効にするには、最初に Twitter Application Management でアプリケーションを作成する必要があります。

Create New App ボタンをクリックします。これにより Create an Application ページが表示されます。

Name および Description を入力します。Web サイトは任意に指定できますが、localhost アドレスを持つことはできません。Callback URL の場合は、Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーする必要があります。

保存をクリックしたら、Details ページに移動します。

次に Keys and Access Tokens タブに移動します。

最後に、このページから API キーとシークレットを取得し、それらを Red Hat Single Sign-On の Add identity provider ページの Client ID および Client Secret フィールドにコピーする必要があります。

Instagram でログインを有効にするために必要な多くのステップがあります。最初に、Identity Providers の左側のメニュー項目に移動し、Add provider ドロップダウンリストから Instagram を選択します。これにより、Add identity provider ページが表示されます。

まだ保存することはできません。これは、Instagram からClient ID および Client Secret を取得する必要はないためです。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを Instagram に提供する必要があるため、この URI をクリップボードにコピーします。

Instagram でログインを有効にするには、まずプロジェクトおよびクライアントを作成する必要があります。Instagram API は、Facebook Developer Console で管理されます。

コンソールにログインしたら、My Apps という画面の右上にあるメニューが表示されます。Add a New App メニュー項目を選択します。

For Everything Else を選択します。

すべての必須フィールドを入力します。この作業が完了したら、アプリケーションのダッシュボードに移動します。左側のナビゲーションパネルのメニューで、Settings で Basic を選択します。

下部の + Add Platform を選択し、globe アイコンで [Website] をクリックします。サイトの URL を指定します。

左側のメニューから Dashboard を選択し、Instagram ボックスで Set Up をクリックします。左側のメニューで Instagram で Basic Display を選択し、Create New App をクリックします。

Display Name を指定します。

Red Hat Single Sign-On の Add identity provider ページから、Instagram Client OAuth Settings 設定ブロックの Valid OAuth Redirect URIs に Redirect URI をコピーアンドペーストします。

この URL は Deauthorize Callback URL および Data Deletion Request URL にも使用できます。Red Hat Single Sign-On は現在、それらのいずれかをサポートしていませんが、Facebook Developer Console には両方の入力が必要です。

このページから App ID および App Secret を取得して、Red Hat Single Sign-On の Add identity provider ページを入力する必要もあります。この項目を取得するには、App Secret の Show をクリックします。Red Hat Single Sign-On に戻り、それらの項目を指定し、最後に Instagram Identity Provider を保存します。

その後、Instagram アプリケーションを公開する必要があります。左のメニューの App Review をクリックしてから Requests をクリックします。その後、画面の指示に従います。

SAML プロバイダーを作成すると、そのプロバイダーを表示するときに表示される EXPORT ボタンがあります。このボタンをクリックすると、外部 SP へのインポートに使用できる SAML SP エンティティー記述子が削除されます。

このメタデータは、URL に移動することで公開されています。

http[s]://{host:port}/auth/realms/{realm-name}/broker/{broker-alias}/endpoint/descriptor

First Broker Login フローで提供されるデフォルトの動作を説明します。

要求なしでユーザーが自動的にリンクされる最初のログインフローを設定するには、以下の 2 つのオーセンティケーターで新しいフローを作成します。

デフォルトの最初のログインフローは、外部アイデンティティーに一致する Keycloak アカウントを検索し、これらをリンクします。一致する Keycloak アカウントがない場合は、自動的に作成されます。このデフォルトの動作は、読み取り専用の LDAP ユーザーストア (すべてのユーザーが事前に作成されることを意味します) など、一部のセットアップでは適切ではない可能性があります。この場合、自動ユーザー作成をオフにする必要があります。ユーザーの作成を無効にするには、以下を実行します。

この設定は、Keycloak 自体が、どの内部アカウントが外部アイデンティティーに対応するかを判断できないことも意味します。そのため、Verify Existing Account By Re-authentication オーセンティケーターにより、ユーザー名およびパスワードが提供されます。

SSO クッキーセットはすべて無効になり、アクティブなブラウザーセッションで認証を要求するクライアントを再ログインする必要があります。特定のクライアントのみが、このログアウトイベント (特に Red Hat Single Sign-On OIDC クライアントアダプターを使用しているクライアント) に通知されます。SAML などの他のクライアントタイプにはバックチャネルログアウトリクエストを受け取りません。

Logout all をクリックして、未処理のアクセストークンが取り消されていないことに注意してください。自然に期限切れになる必要があります。失効ポリシーをクライアントからプッシュする必要がありますが、Red Hat Single Sign-On OIDC クライアントアダプターを使用するクライアントでも機能することになります。

Sessions ページで、各クライアントにドリルダウンすることもできます。これにより、そのクライアントの Sessions タブに移動します。Show Sessions ボタンをクリックすると、どのユーザーがそのアプリケーションにログインしているかを確認できます。

個別ユーザーの Sessions タブに移動する場合は、セッション情報を表示することもできます。

デフォルトでは、Red Hat Single Sign-On はユーザーを LDAP からローカルの Red Hat Single Sign-On ユーザーデータベースにインポートします。このユーザーのコピーは、オンデマンドで同期されるか、または定期的なバックグラウンドタスクを介して同期されます。これに対する 1 つの例外は、パスワードの同期です。パスワードはインポートされません。検証は常に LDAP サーバーに委譲されます。このアプローチの利点は、すべての Red Hat Single Sign-On 機能は、ローカルに保存する必要のあるユーザーごとの追加のデータとして機能することです。このアプローチのマイナス面は、特定のユーザーが初めてクエリーされるたびに、対応する Red Hat Single Sign-On データベース挿入が実行されます。インポートは、LDAP サーバーとも同期する必要があります。しかし、LDAP マッパーがデータベースではなく LDAP から特定の属性を常に読み取るように設定されている場合には、インポートの同期は必要ありません。

または、Red Hat Single Sign-On ユーザーデータベースにユーザーをインポートしないよう選択することもできます。この場合、Red Hat Single Sign-On ランタイムが使用する一般的なユーザーモデルは LDAP サーバーのみでサポートされます。つまり、LDAP が Red Hat Single Sign-On 機能が必要とするデータの一部をサポートしない場合、その機能は機能しないことを意味します。このアプローチの利点は、LDAP ユーザーのコピーを Red Hat Single Sign-On ユーザーデータベースにインポートおよび同期するオーバーヘッドを持たないことです。

このストレージモードは、Import Users スイッチによって制御されます。ユーザーをインポートするには On に設定します。

User Account Service サービスのユーザー、および管理コンソールの管理者には、ユーザーメタデータを変更する機能があります。セットアップによっては、LDAP の更新権限がある場合とない場合があります。Edit Mode 設定オプションは、LDAP ストアで設定した編集ポリシーを定義します。

LDAP ストアにセキュアな接続 URL (例: 'ldaps://myhost.com:636') を設定する場合、Red Hat Single Sign-On は LDAP サーバーとの通信に SSL を使用します。重要なことは、Red Hat Single Sign-On サーバー側でトラストストアを適切に設定することです。そうでないと、Red Hat Single Sign-On は LDAP への SSL 接続を信頼できません。

Red Hat Single Sign-On のグローバルトラストストアは、Truststore SPI で設定できます。詳細は、『サーバーインストールおよび設定ガイド』 を参照してください。トラストストア SPI が分からないと、トラストストアは Java によって提供されるデフォルトメカニズムにフォールバックします (システムプロパティー javax.net.ssl.trustStore または cacerts ファイルのいずれか)。システムプロパティーが設定していない場合は、JDK から cacerts ファイルを使用します。

LDAP フェデレーションプロバイダー設定に Use Truststore SPI を使用すると、Truststore SPI を使用するかどうかを選択できます。デフォルトでは、この値は ldaps 専用 ですが、ほとんどのデプロイメントでは問題ありません。Truststore SPI は、LDAP への接続 URL が ldaps で始まる場合にのみ使用されます。

ユーザーのインポートオプションを有効にすると、LDAP プロバイダーは、必要な LDAP ユーザーの同期 (インポート) を Red Hat Single Sign-On のローカルデータベースに自動的に処理します。ユーザーがログインすると、LDAP プロバイダーは LDAP ユーザーを Red Hat Single Sign-On データベースにインポートし、LDAP パスワードに対して認証します。これは、ユーザーがインポートされる唯一の時間です。管理コンソールの左側のメニュー項目 Usersに移動し、View all users ボタンをクリックすると、Red Hat Single Sign-On によって最低 1 回認証された LDAP ユーザーのみが表示されます。この操作により LDAP ユーザーデータベース全体のインポートがトリガーされないように、この方法が実装されます。

全 LDAP ユーザーを Red Hat Single Sign-On データベースに同期する場合は、LDAP プロバイダー設定ページで Sync Settings を設定し、有効にすることができます。2 種類の同期が存在します。

同期を処理する最適な方法は、最初に LDAP プロバイダーを作成し、変更したユーザーの定期的な同期を設定する際に、Synchronize all users ボタンをクリックすることです。

LDAP マッパーは、さまざまな点で LDAP プロバイダーによってトリガーされる listeners で、別のエクステンションが LDAP 統合を参照します。これらは LDAP 経由でログインし、ユーザーが Red Hat Single Sign-On の起動中にインポートする必要がある場合や、ユーザーが管理コンソールからクエリーされる場合にトリガーされます。LDAP フェデレーションプロバイダーを作成すると、Red Hat Single Sign-On はこのプロバイダーの組み込み mappers のセットを自動的に提供します。このセットを変更し、新しいマッパーを作成したり、既存のマッパーを更新/削除したりすることもできます。

デフォルトでは、ユーザー名、ファイル名、名、姓、電子メールなどの Red Hat Single Sign-On の基本属性属性を対応する LDAP 属性にマップする User 属性マッパーがあります。これらの拡張は自由に行い、追加の属性マッピングを指定することができます。管理コンソールはツールチップを提供します。これは、対応するマッパーの設定に役立ちます。

ユーザーのパスワードが Red Hat Single Sign-On から更新され、LDAP に送信されると、常にプレーンテキストで送信されます。これは、ハッシュと salt が DB に送信される前にパスワードに適用される場合に、パスワードを組み込み Red Hat Single Sign-On データベースに更新することとは異なります。LDAP の場合、Red Hat Single Sign-On は LDAP サーバーに依存してパスワードのハッシュおよび salt を提供します。

Microsoft Active Directory、RHDS または FreeIPA などの LDAP サーバーは、デフォルトでこれを提供します。OpenLDAP や ApacheDS などのその他の場合には、RFC3062 に従って LDAPv3 Password Modify Extended Operation を使用しない限り、デフォルトでパスワードをプレーンテキストで保存できます。LDAPv3 Password Modify Extended Operation は LDAP 設定ページで明示的に有効にする必要があります。詳細は、お使いの LDAP サーバーのドキュメントを参照してください。

分かりやすくするために、すでに利用可能な FreeIPA Docker イメージが使用されます。サーバーを設定するには、FreeIPA ドキュメント を参照してください。

Docker を使用して FreeIPA サーバーを実行するには、以下のコマンドが必要です。

docker run --name freeipa-server-container -it \
-h server.freeipa.local -e PASSWORD=YOUR_PASSWORD \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
-v /var/lib/ipa-data:/data:Z freeipa/freeipa-server

server.freeipa.local のパラメーター -h は FreeIPA/IdM サーバーのホスト名を表します。YOUR_PASSWORD を選択したパスワードに変更するようにしてください。

コンテナーが起動したら、/etc/hosts を以下に変更します。

x.x.x.x     server.freeipa.local

この変更を加えない場合は、DNS サーバーを設定する必要があります。

SSSD フェデレーションプロバイダーが起動し、Red Hat Single Sign-On で実行するように、IPA ドメインに Linux マシンを登録する必要があります。

ipa-client-install --mkhomedir -p admin -w password

クライアントマシンで、すべてが想定通りに機能されていることを確認するには、以下を実行します。

kinit admin

パスワードの入力が求められます。その後、以下のコマンドを使用して IPA サーバーにユーザーを追加できます。

$ ipa user-add john --first=John --last=Smith --email=john@smith.com --phone=042424242 --street="Testing street" \      --city="Testing city" --state="Testing State" --postalcode=0000000000 --password

ユーザーのパスワードの設定を強制するには、kinit を使用します。ユーザーに john を指定し、以下のコマンドを入力します。

kinit john

通常の IPA 操作を復元するには、以下のコマンドを入力します。

kdestroy -A
kinit admin

前述のように、フェデレーションプロバイダーは D-BUS を使用して SSSD からデータを取得し、PAM を使用して認証を行います。

まず sssd-dbus RPM をインストールする必要があります。これにより、SSSD からの情報をシステムバスで送信できるようにします。

$ sudo yum install sssd-dbus

このプロビジョニングスクリプトを実行する必要があります。

$ .../bin/federation-sssd-setup.sh

このスクリプトは、/etc/sssd/sssd.conf に必要な変更を加えます。

[domain/your-hostname.local]
...
ldap_user_extra_attrs = mail:mail, sn:sn, givenname:givenname, telephoneNumber:telephoneNumber
...
[sssd]
services = nss, sudo, pam, ssh, ifp
...
[ifp]
allowed_uids = root, yourOSUsername
user_attributes = +mail, +telephoneNumber, +givenname, +sn

また、keycloak ファイルは /etc/pam.d/ に含まれています。

auth    required   pam_sss.so
account required   pam_sss.so

dbus-send を実行して、すべてが予想どおりに機能することを確認します。

sudo dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups string:john

ユーザーのグループが表示されるはずです。このコマンドでタイムアウトまたはエラーが返されると、Red Hat Single Sign-On で実行されているフェデレーションプロバイダーも何も取得できないことを意味します。

これは、マシンが FreeIPA IdM サーバーに登録されていないか、SSSD サービスにアクセスするパーミッションがありません。

パーミッションがない場合は、Red Hat Single Sign-On サーバーを実行しているユーザーが、以下のセクションの /etc/sssd/sssd.conf ファイルに含まれていることを確認します。

[ifp]
allowed_uids = root, your_username

Red Hat Single Sign-On は、DBus-Java を使用して D-Bus が低いレベルで通信します。これは Unix ソケットライブラリーに依存します。

SSSD フェデレーションプロバイダーを有効にする前に、このライブラリーの RPM をインストールする必要があります。

$ sudo yum install rh-sso7-libunix-dbus-java

PAM Red Hat Single Sign-On での認証では JNA を使用します。このパッケージがインストールされていることを確認します。

$ sudo yum install jna

sssctl user-checks コマンドを使用して設定を検証します。

$ sudo sssctl user-checks admin -s keycloak

ログインイベント:

アカウントイベント:

すべてのイベントには、対応するエラーイベントがあります。

イベントリスナーはイベントをリッスンし、そのイベントに基づいてアクションを実行します。Red Hat Single Sign-On には、Logging Event Listener と Email Event Listener の 2 つの組み込みリスナーがあります。

Logging Event リスナーは、エラーイベントが発生し、デフォルトで有効にされるたびにログファイルに書き込みます。ログメッセージの例を以下に示します。

11:36:09,965 WARN  [org.keycloak.events] (default task-51) type=LOGIN_ERROR, realmId=master,
                    clientId=myapp,
                    userId=19aeb848-96fc-44f6-b0a3-59a17570d374, ipAddress=127.0.0.1,
                    error=invalid_user_credentials, auth_method=openid-connect, auth_type=code,
                    redirect_uri=http://localhost:8180/myapp,
                    code_id=b669da14-cdbb-41d0-b055-0810a0334607, username=admin

このロギングは、fail2Ban などのツールを使用して、ユーザーパスワードの推測を試みる場所のハッカーボットがあるかどうかを検出する場合に非常に便利です。LOGIN_ERROR のログファイルを解析し、IP アドレスをプルできます。次に、この情報を Fail2Ban にフィードし、攻撃を防ぐのに役立ちます。

Logging Event リスナーは、イベントを org.keycloak.events ロガーカテゴリーに記録します。デフォルトでは、デバッグログイベントはサーバーログに含まれません。

サーバーログにデバッグログイベントを含めるには、standalone.xml ファイルを編集し、Logging Event リスナーによって使用されるログレベルを変更します。または、org.keycloak.events のログレベルを設定することもできます。

たとえば、ログレベルを変更するには、以下を追加します。

<subsystem xmlns="urn:jboss:domain:logging:...">
    ...
    <logger category="org.keycloak.events">
        <level name="DEBUG"/>
    </logger>
</subsystem>

Logging Event リスナーによって使用されるログレベルを変更するには、以下を追加します。

<subsystem xmlns="urn:jboss:domain:keycloak-server:...">
    ...
    <spi name="eventsListener">
      <provider name="jboss-logging" enabled="true">
        <properties>
          <property name="success-level" value="info"/>
          <property name="error-level" value="error"/>
        </properties>
      </provider>
    </spi>
</subsystem>

ログレベルの有効な値は debug、info、warn、error、および fatal です。

メールイベントリスナーは、イベント発生時にユーザーのアカウントにメールを送信します。

現在、Email Event リスナーは以下のイベントをサポートします。

Email Listener を有効にするには Config タブに移動し、Event Listeners フィールドをクリックします。これにより、メールを選択できるドロップダウンリストが表示されます。

ディストリビューションに同梱される standalone.xml、standalone-ha.xml、または domain.xml を編集して、1 つ以上のイベントを除外できます。以下は例になります。

<spi name="eventsListener">
  <provider name="email" enabled="true">
    <properties>
      <property name="exclude-events" value="[&quot;UPDATE_TOTP&quot;,&quot;REMOVE_TOTP&quot;]"/>
    </properties>
  </provider>
</spi>

standalone.xml、standalone-ha.xml、または domain.xml を編集して、データベースに保存されているイベントの詳細の最大長を設定することもできます。この設定は、一部のフィールド (例: redirect_uri) が非常に長い場合に役に立ちます。以下は、最大長を定義する例です。

<spi name="eventsStore">
    <provider name="jpa" enabled="true">
        <properties>
            <property name="max-detail-length" value="1000"/>
        </properties>
    </provider>
</spi>

standalone.xml、standalone-ha.xml、または domain.xml ファイルが存在する場所の詳細は、『サーバーインストールおよび設定ガイド』を参照してください。

クレデンシャルストアおよび vault のパスワードがプレーンテキストである vault を作成します。

クレデンシャルストアおよび vault を更新して、elytron-tool.sh によって提供されるマスクを使用するパスワードを取得できるようになりました。

/auth/admin へのアクセスを特定の IP アドレスだけに制限することができます。

以下の例では、/auth/admin へのアクセスを、10.0.0.1 から 10.0.0.255 の範囲の IP アドレスに制限しています。

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
    ...
    <server name="default-server">
        ...
        <host name="default-host" alias="localhost">
            ...
            <filter-ref name="ipAccess"/>
        </host>
    </server>
    <filters>
        <expression-filter name="ipAccess" expression="path-prefix('/auth/admin') -> ip-access-control(acl={'10.0.0.0/24 allow'})"/>
    </filters>
    ...
</subsystem>

CLI コマンドを使用した同等の設定:

/subsystem=undertow/configuration=filter/expression-filter=ipAccess:add(,expression="path-prefix[/auth/admin] -> ip-access-control(acl={'10.0.0.0/24 allow'})")
/subsystem=undertow/server=default-server/host=default-host/filter-ref=ipAccess:add()

/auth/admin をインターネット上で公開されていない別のポートに公開することができます。

以下の例では、ポート 8444 で /auth/admin を公開しますが、デフォルトポート 8443 でアクセスが許可されません。

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
    ...
    <server name="default-server">
        ...
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <https-listener name="https-admin" socket-binding="https-admin" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            ...
            <filter-ref name="portAccess"/>
        </host>
    </server>
    <filters>
        <expression-filter name="portAccess" expression="path-prefix('/auth/admin') and not equals(%p, 8444) -> response-code(403)"/>
    </filters>
    ...
</subsystem>

...

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    ...
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="https-admin" port="${jboss.https.port:8444}"/>
    ...
</socket-binding-group>

CLI コマンドを使用した同等の設定:

/socket-binding-group=standard-sockets/socket-binding=https-admin/:add(port=8444)

/subsystem=undertow/server=default-server/https-listener=https-admin:add(socket-binding=https-admin, security-realm=ApplicationRealm, enable-http2=true)

/subsystem=undertow/configuration=filter/expression-filter=portAccess:add(,expression="path-prefix('/auth/admin') and not equals(%p, 8444) -> response-code(403)")
/subsystem=undertow/server=default-server/host=default-host/filter-ref=portAccess:add()

もう 1 つでは、パスワード推測を防止するために、複雑なパスワードポリシーを確保して、ユーザーがパスワードの推測が困難であるようにします。詳細は、「パスワードポリシー」 の章を参照してください。

パスワード推測を防ぐ最善の方法は、サーバーがワンタイムパスワード (OTP) を使用するように設定することです。