Keycloakで実用的なリバースプロキシ型構成を構築してみよう:Keycloak超入門(7)(3/4 ページ)
本連載では、近年注目されている認証プロトコル「OpenID Connect」をサポートするオープンソースのシングルサインオン(SSO)ソフトウェア「Keycloak」の活用方法を解説していきます。Keycloakと標準的な認証/認可プロトコルに対応したプロキシを組み合わせることで、プロトコル未対応のアプリケーションに対し、安全なシングルサインオン環境を提供できます。
設定確認
構築が完了したら、設定を確認してみましょう。
●ロールの設定確認
まずは、「Keycloak管理コンソール」(https://sso.example.com/auth/admin/)にアクセスし、Keycloak管理者(admin)でログインして、ロールの設定を確認します。ロールには、レルムの範囲で有効となる「レルムロール」と、クライアントの範囲で有効となる「クライアントロール」の2種類があります。今回は、レルムロールに設定されているので、それを確認します(画面1)。
●クライアントの設定確認
続いて、クライアントの設定を確認します。連携先アプリ1用に「demo_app1」と連携先アプリ2用に「demo_app2」を設定されています(画面2)。
また、それぞれのクライアントで、レルムロールを連携するように「role」属性をマッパーに設定しています(画面3)。
●ユーザーの設定確認
続いて、ユーザーの設定を確認します。画面4のように「user001」と「user002」が作成されています。
また、表3の「ユーザー一覧」で記載した通り、それぞれのユーザーにロールマッピングを設定しています(画面5)。
●mod_auth_openidcの設定確認
次に、「mod_auth_openidc」の設定を確認します。表4の「コンテンツ一覧」で記載したアクセス制御設定はここで確認できます。
ここでは、詳細な解説は省略しますが、利用したmod_auth_openidc固有のディレクティブについて、説明を記載します(表5、表6)。
パラメーター名 | 必須 | 説明 |
---|---|---|
OIDCResponseType | − | OpenID Connectのレスポンスタイプを設定する。以下の中から指定する。 (1)code (2)id_token (3)id_token token (4)code id_token (5)code token (6)code id_token token このレスポンスタイプの指定により、OpenID Connectの認証フローが定まる。デフォルトは(1)のcodeなので、認可コードフローになる。(2)と(3)は、Implicitフローになる。(4)〜(6)はHybridフローになる。 |
OIDCCryptoPassphrase | ○ | Cookieやキャッシュの暗号化で使用されるパスフレーズを設定する。任意の値を設定する。 |
OIDCCookieDomain | − | mod_auth_openidcが発行するCookieのドメイン属性を設定する。デフォルトでは、ドメイン属性は付与されない。ドメイン間で、mod_auth_openidcのセッションを共有したい場合に利用する。 |
OIDCSSLValidateServer | − | OPとの連携でSSLを使用する場合に、有効なサーバ証明書かどうかのチェック有無を設定する。今回はKeycloakの自己署名サーバ証明書をプロキシサーバ側のOSの信頼済み証明書としてインポートしていないのでOffにする。プロダクション環境では、On(デフォルト)で動作させるべきである。 |
OIDCProviderMetadataURL | ○ | OPメタデータURLを設定する。Keycloak側のメタデータURLを指定する。 |
OIDCPassClaimsAs | − | mod_auth_openidcが連携アプリにクレームを連携する方法を設定する。以下の中から指定する。 (1)none (2)header (3)environment (4)both |
OIDCClaimPrefix | − | 連携アプリに連携するクレームのプレフィックスを設定する。デフォルトでは、連携するクレームに“OIDC_CLAIM_”というプレフィックスが付与されるが、任意に指定が可能(“”を指定すると付与されない)・ |
OIDCRedirectURI | ○ | mod_auth_openidcのリダイレクトURIを設定する。mod_auth_openidcで保護されているパス上のURLを指定する必要があるが、実際にコンテンツがあるURLを指定してはいけない。このURLがOIDCの動作中に利用される予約URLとなるため、ユーザーが直接呼び出すことができなくなるため(直接呼び出した場合は、パラメーター不足で500エラーが発生する)。 mod_auth_openidcのOIDCの動作ではログイン成功後、最初にこのURLにリダイレクトされた後で、もともとユーザーがアクセスしていたURLに再度リダイレクトされる動作となる。 |
OIDCClientID | ○ | クライアントIDを設定する。Keycloak側のクライアント設定のクライアントID(client-id)を指定する。 |
OIDCClientSecret | △ | クライアントシークレットを設定する。Keycloak側のアクセスタイプで"confidential"を指定した場合は必須である。 |
表5 mod_auth_openidcの主要設定 |
【※】mod_auth_openidcは高機能であるため、今回利用しなかった設定項目も数多くあります。必要に応じて、こちらも参照してください(https://github.com/zmartzone/mod_auth_openidc/blob/master/auth_openidc.conf)。
パラメーター名 | 必須 | 説明 | |
---|---|---|---|
AuthType | ○ | 認証タイプを設定する。"openid-connect"で固定。 | |
Require | valid-user | − | 認証を必須に設定する。 |
claim | − | ユーザー情報の値でアクセス制御を設定する。 (例) claim name:Joe => name が Joe のユーザーのみ許可 claim "role~.*admin.*" => role に admin が含まれるユーザーのみ許可 |
|
not claim | − | mod_auth_openidcでは利用できない。 | |
all granted | − | アクセス制御を無効に設定する。 | |
表6 アクセス制御をかける<Location>ディレクティブ内の設定 |
【※】claimによるアクセス制御はさまざまな設定方法があります。その他の方法に関しては、こちらを参照してください(https://github.com/zmartzone/mod_auth_openidc/wiki/Authorization)。
これで、Keycloakのリバースプロキシ型構成の設定確認が完了です。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- なぜ「シングルサインオン」が必要なのか?
企業でのWebサービスの実現が具体的になるにつれ、パスワード/IDマネジメントが重視されるようになり、「シングル・サインオン」がますます注目を集めている。この連載では、シングル・サインオンの実践ステップなど具体的な考え方を紹介する。また、メタディレクトリやLDAPなど「ディレクトリ統合」をキーワードとしてシングル・サインオンを実現するための技術を分かりやすく解説する。(編集部) - 第1回 もはや企業のID管理で避けては通れない「IDaaS」とは?
これまで社内設置が当たり前だったアイデンティティ(ID)管理/認証システム。でも「クラウド」「モバイル」に代表される激烈な変化に対応できる、と本当に思っていますか? ID管理/シングルサインオンの新たな選択肢「IDaaS」について解説する連載開始! - 強力なSSOを実現するXML認証・認可サービス(SAML)
- OpenIG、OpenDJと連携したOpenAMの新機能
今回は、OpenAMの姉妹製品で既存アプリケーションを改修せずにシングルサインオンを可能にする「OpenIG」と、OpenAMのデフォルトデータストアである「OpenDJ」について解説します。