注目のWebAuthnと公式より早いKeycloak最新動向を紹介！OSSセキュリティ技術の会 第5回勉強会

2019年6月7日、サイボウズ東京オフィスにて「OSSセキュリティ技術の会」による第5回勉強会「KeycloakとWebAuthnのツインシュートの巻」が開催された。1年前の第3回勉強会に続きKeycloakを主なテーマとして取り上げつつも、最新の認証規格である「WebAuthn」も取り混ぜて開催。80名ほどが参加し関心の高さをうかがわせた。 この分野は日本のコミュニティで活発に開発が行われており、3つのセッションにて、まさに最前線の報告が行われた。

※OSSセキュリティ技術の会の詳細についてはコチラを参照。

WebAuthnの国産OSSライブラリ
「WebAuthn4J」

1つ目のセッションでは、「WebAuthn4J」の主要開発者の能島良和氏が登壇し、WebAuthn4Jを紹介した。

「WebAuthn4J」主要開発者 能島良和氏

能島氏は、Twitterで@shiroicaのアカウント名で活動している。WebAuthn4JとはWebAuthnのサーバサイドJavaライブラリだ。

まず、WebAuthnについて解説。WebAuthn登場の背景として、パスワード認証の限界が関与しているという。能島氏はWeb認証のフィッシング攻撃耐性とリスト型攻撃耐性、モバイルデバイス対応に触れ、「パスワード認証に変わる認証手段が必要だ」と述べた。

WebAuthnは、それらの問題点を克服したセキュアな認証を実現するためのWeb標準。W3Cで新しい認証方式としてWeb Authentication仕様の策定が進められており、現在、主要ブラウザ(Edge、Chrome、Firefox、Safari)での実装が進行している。その主な特徴として以下の3つが挙げられた。

1. 指紋認証や顔認証など認証方式を差し替え可能
2. 生体情報をサーバーで保存せず、安全性が高い
3. フィッシング攻撃、CSRF攻撃対策の組み込み

会場では認証のデモが行われ、その後、裏で行われている処理について説明があった。

Web Authenticationの認証フロー

• ユーザー登録処理
  • サーバーからブラウザへ、チャレンジと呼ばれるCSRFトークン相当のランダムデータが送られる
  • ブラウザはユーザー登録処理を検出すると認証デバイスを呼び出し、ユーザーの同意を得た上で公開鍵、秘密鍵のペアを作る
  • この鍵ペアは認証機能を提供するサイトRelying Party(RP)ごとに作成、保管される
  • その後公開鍵はサーバーに送信され、保存される
• ユーザー認証処理
  • ブラウザは認証デバイスを呼び出して認証処理を行う
  • 認証の同意を得た上でRelying Partyに固有の秘密鍵を使って署名を作成
  • サーバーは保存しておいた公開鍵で送られてきた署名を検証

WebAuthn ではユーザーと認証デバイス間のローカルで認証を行い、認証デバイスとサーバー間で公開鍵を使うという組み合わせで認証が行われている。このとき、生体情報(究極のプライバシー情報)などは認証デバイスに保存されておりサーバー側には送られない。リモート認証の場合の攻撃リスクを減らし、生体情報は認証デバイスの外に流通しないため安全性が高い。

一方、この方式のデメリットは、登録時に使用した認証デバイスが手元にないと認証ができないことだ。能島氏は「サイトは複数の認証デバイスを登録できるようにするなどの工夫が必要」と述べた。

パスワード認証問題で挙げられた3点に対するWebAuthnの効果は以下の通りだ。

• フィッシング攻撃対応
  • 認証の鍵ペアがドメインごとに保存される
  • 他ドメインから認証要求を受けても秘密鍵は不正利用されない
• リスト型攻撃対応
  • サーバ側に保存されるのは公開鍵
  • RPごとドメインごとに異なる鍵ペアを使われるため影響を受けない
• モバイルデバイス対応
  • WebAuthnを使うとスマホの生体認証機能を使ってログインが可能
  • パスワードの打ち込みによるユーザーの離脱を防げる

WenAuthnはブラウザからアプリケーションに対して、フロントエンドにあるJavaScriptのAPIを呼び出す必要がある。フロントエンドはバックエンドからチャレンジを受け取り、ブラウザのWebAuthn APIを呼び出し、結果をバックエンドに返送する処理が必要だ。

バックエンドでは、リプレイ攻撃防止用のチャレンジデータを発行し、チャレンジデータとクライアント側で発行された認証情報を用いてWebAuthnの仕様で定められた検証を実施する。能島氏によると「この検証が結構大変」とのことで、現在開発中の「WebAuthn4J」というJavaライブラリを紹介した。WebAuthn4Jは登録認証のメッセージを検証するためのライブラリで、現在NRIや日立製作所などの協力を得て開発を進めている。KeycloakやSpring Security向けのアダプタも開発中だ。その後ライブラリの使い方を説明し、最後にWebAuthn導入における注意点に触れた。

鍵ペアはドメインに紐づけて保存され、ドメイン名を似せた偽サイトでフィッシング攻撃を受けた場合でもその不一致を確認できる。どのサブドメインの範囲までを一致とみなすかは鍵の登録時に指定するrpIDというパラメータを用いるが、複数のTLD(トップレベルドメイン)にまたがって存在するサイトの場合、WebAuthnの使用では同一のサイトとして扱うことができない。また、ドメイン名を変更すると既存ユーザが認証できなくなってしまうため、注意が必要だ。ドメイン名が異なる場合にWebAuthn資格情報が共有できない問題はドメイン間でOpenID ConnectやSAMLでシングルサインオンさせることで緩和可能とのことである。

公式よりも早い!? Keycloakの最新動向を紹介

2番目のセッションでは、日立製作所の中村 雄一氏がKeycloakの概要説明と5月に米ボストンで開催された「Red Hat Summit」で得たKeycloakの最新動向を報告した。

日立製作所 中村雄一氏

KeycloakはRed Hat社を中心としたコミュニティで開発されているID情報を取り扱うOSSで、従来のシングルサインオンと呼ばれるものを実現できる。近年よく見られるFacebook等の外部サイトのアカウントでログインするソーシャルログインにも対応できる。 また、KeycloakはAPIの分野でも注目されているという。APIのセキュリティの基本として認証とアクセス制御の2つがあるが、認証の実現方式としてはOAuth/OpenID Connectがデファクトになっている。そのOAuth/OpenID ConnectをサポートしていることからKeycloakが注目されていると説明した。その他にKeycloakはJavaさえ入っていればWindowsでもLinuxでもすぐに起動できる状態で配布されているため簡単に試すことができる点や、ドキュメントが充実している点なども紹介された。

Keycloakの最新動向では、「Red Hat Summit」会場でKeycloak主要メンバと日本コミュニティとで行われたコミュニティミーティングにて議論された内容を中心に報告。Red Hat SummitのKeycloak関連セッションとしては、英国で標準化が進むOpenBanking向けにKeycloak(Red Hat SSO)にも力を入れていくといった内容のセッションがあったほか、OpenShiftやミドルウェアのセッションの中で部品として触れられていたとのことだ。

コミュニティミーティングでは、Keycloak主要メンバ側としてマネージャのMike氏と主要開発者のMarek氏が参加。ミーティングの内容は、主なトピックであったFinancial API(FAPI)とWebAuthn、Keycloakのロードマップに分けて以下のように紹介された。

• FAPIは銀行などの金融分野でAPIを公開する際にOAuth/OpenID Connectの安全な使い方を規定したもの。KeycloakのFAPI対応については、実装は日立製作所の乗松氏(@tnorimat)を中心に取り組んでおり、大きなところは概ね完了している。一方で、FAPIのConformance Testが4月にリリースされたため、現在はFAPIのConformance Testのパスに向けてOSSセキュリティ技術の会のGitHubリポジトリを通じて日本コミュニティで動き出している。Keycloakコミュニティも日本コミュニティに期待しているとのこと。
• KeycloakではWebAuthnロジックそのものを持つつもりはなく、外部ライブラリを活用する方針だ。ライブラリとしてはWebAuthn4Jが有力候補として上がっている。日本コミュニティでは、WebAuthn4J用のKeycloak認証プラグインを開発し、Keycloakコミュニティに提案している。

Keycloakのロードマップについては、本勉強会の直前に「メンテナから日本コミュニティへ」ということで資料が送付されたが、正式発表前であるため会場限定として紹介された。6/12、13日に英国で開催されたKeycloakとID管理OSSのカンファレンス「KeyConf 2019」で発表された。日立の開発者である乗松氏も講演予定とのことで、「機会があればレポートを共有したい」と語った。

豊富な拡張ポイントを活用して
カスタマイズ「Keycloak拡張入門」

最後のセッションでは「Keycloak拡張入門」と題して、野村総合研究所の和田広之氏がKeycloakの拡張機能の概要と具体例を紹介した。

野村総合研究所の和田広之氏

和田氏によると「keycloakは様々なユースケースに対応できるようデザインされているが、実際には個別にカスタマイズが必要な案件は意外と多い」という。ただし、カスタマイズが必要でもKeycloak本体に手を加える必要はない。Keycloakには50を超える拡張ポイントが用意されており、必要に応じて機能を追加できる。

和田氏は、Keycloakの拡張ポイントの種類として以下の4点を挙げた。

1. テーマ
   画像やスタイルシートなどの必要なリソースファイルを所定のディレクトリに配置し、管理コンソール画面で設定するだけでログイン画面などのKeycloakの様々な画面をカスタマイズできる。
2. スクリプト(JavaScript)
   JavaScriptのコードを記述して、管理コンソール画面から認証処理やSAML、OpenID Connectのマッパー処理をカスタマイズできる。
3. SPI(Service Provider Interfaces)
   KeycloakがSPI(Java6から導入されたServiceLoaderを利用したプラグイン機構)単位で提供するProviderおよびProviderFactoryを実装してデプロイすることで、認証ロジックの追加など様々な機能を拡張できる。
4. カスタムSPI
   拡張ポイントであるSPI自体を作成するときに使用。基本的にはKeycloak本体の開発やカスタマイズ時にのみ使用する。例として、現在提案中のOAuth 2.0 Device Authorization Grant対応でUser CodeのフォーマットをカスタマイズできるようにSPIを追加する際に使用する。

次に、拡張機能を利用する具体例について、初級編/中級編/上級編の3段階に分けて解説した。

1. 初級編「動的にログイン画面を変更したい」
   例えば、社内からのアクセスか社外からのアクセスかにより表示する外部IdP(Identity Provider)を切り替えたいという要望がよくある。標準のテーマ機能では動的に制御できないが、ログイン処理のSPIを拡張することで実現可能となる。
2. 中級編「○○でログインに対応したい」
   Keycloakでは標準でGitHubなどいくつかのソーシャルログインに対応しているが、LINEやDiscordなどそれ以外の外部IdPを利用したいという要望がよくある。SAMLやOpenID Connectに対応する外部IdPではそれを利用すれば良いが、そうでない場合には認証処理のSPIを拡張することで実現可能となる。
3. 上級編「○○ADのようにSSO時にサービス利用権限がない場合はエラーとしたい」
   特定のグループやロールのユーザーのみアクセスを許可したいという要望がある。いわゆる「条件付きアクセスによるアクセス制御」を実現したいケースである。Keycloakの標準機能だけではアプリケーション側でのアクセスコントロールが必要となるが、デフォルトのSAMLのログイン処理をカスタマイズして差し替えることで条件付きのアクセス制御が実現可能となる。ただし、このデフォルトの処理を差し替える方法はバージョンアップで使えなくなる可能性があり、注意が必要とのことだ。

おわりに

今回は、第5回勉強会の様子を紹介した。本勉強会は毎度新しい参加者が半数以上を占めており、会の活動は確実に広がりを見せている。次回の勉強会も企画中であり、興味のある方はぜひ楽しみにしていただきたい。