fbpx

Keycloak(15.02)でOpenID Connect CIBAとプッシュ通知を試す #keycloak #ciba #oauth #oidc

keycloak

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

1. 目次

  • 1. 目次
  • 2. 概要
  • 3. Keycloak14系から15系でのCIBA関連の差分
  • 4. CIBAの認証方法について
  • 5. 今回試す全体像の説明
  • 6. 今回使う環境の説明
  • 7. 検証用データの作成・確認
  • 8. シーケンス図でのやりとりベースでの解説
  • 9. 後書き

2. 概要

shiba チームの中村です。 今回は周りから CIBA = プッシュ通知が来て認証及び認可を行う というような話をよくにお聞きするので、CIBAと認証周りお話と、実際に Keycloakの最新版である 15.02 のバージョンでCIBAを絡めて、プッシュ通知でユーザーに通知が行き、プッシュ通知で許可する一連の流れを簡単に試してみたいと思います。

今回の記事で解説する箇所

今回の記事では主に下記の部分について解説していきます。
  • Keycloak14.0.0から15.0.2でCIBAに関連する機能がどう変わったか
  • CIBAと認証について
  • プッシュ通知を含んだフローの簡易版のデモ

今回の記事で説明しない所

下記の内容については詳細な解説は割愛させていただきます。参考になるリンクを貼っておいたので必要に応じて確認お願いします。

3. Keycloak14系から15系でのCIBA関連の差分

では14系から15系へのバージョンアップにおいて、主な差分としては下記のようなものになります。
  • 3.1 FAPICIBA および OpenBanking Brasil に対応
  • 3.2 CIBA pingモードのサポート
  • 3.3 CIBAのサポートレベルが Supported に変更
    • デフォルトで有効化
これらについて後ほど1つずつ簡単に見ていきます。
また、各バージョンのリリース情報は下記をご確認ください。

3.1 FAPICIBA および OpenBanking Brasil に準拠

リリースノートを見る限り、FAPICIBA および OpenBanking Brasilに対応したようです。

ではFAPIとFAPICIBAについて簡単にお話しますと、FAPI(Financial-grade API)は OpenID Foundation の　Financial-grade API ワーキンググループ が策定している技術仕様です。

この仕様は、標準的なOAuthやOpenID Connectで提供されるよりも高いレベルのセキュリティを必要とする、セキュリティと相互運用性に関する具体的な実装ガイドラインを提供することを目的とした、安全性の高いOAuth関連の仕様の集まりです。元々はオープンバンキング関連のシナリオでの使用を目的としていましたが、現在は他の高度なセキュリティのユースケースにも急速に拡大しており、あらゆる市場分野のAPIに適用できます。

ではFAPI CIBAは何かというと、CIBAの仕様を他のFAPIの仕様と組み合わせるために、推奨事項などの仕様の集まりを提供しているものです。詳しくは FAPI 1.0 の CIBA Profileをご確認ください。

ただし、OpenID Foundationの Certified Financial-grade API Client Initiated Backchannel Authentication Profile (FAPI-CIBA) OpenID Providers のページ見る限り、まだ FAPI CIBA の認定はまだ取得していないように見えます。また、redhatさんの issue で現状を確認するとPass All Conformance Tests for FAPI OpenID testsuite after Keycloak 15という チケットがまだ開いているので、テストスイートの合格を目指す状態のようです。

次に、OpenBanking Brasil ですが、これは Open Banking Brasil Financial-grade API Security Profile への対応を指しており、Open Banking Brasil GT Security によって作成された仕様です。

この仕様は Financial-grade API Security Profile 1.0 - Part 2: Advanced で提供されるよりも高いレベルのプライバシーを必要とするブラジルのオープンバンキング分野のAPIに適用可能な、セキュリティと相互運用性に関する具体的な実装ガイドラインを提供することを目的とした仕様の集まりです。

また Keycloak15.02のdocumentの Open Banking Brasil Financial-grade API Security Profile やredhatさんの issue OpenBanking Brasil support にもあるように、Keycloakが対応しているのは Open Banking Brasil Financial-grade API Security Profile 1.0 Implementations Draft1 です。しかし、現在はそのDraftである Open Banking Brasil Financial-grade API Security Profile 1.0 Implementers Draft 2 がでており、Draft1は非推奨とされていますのでご注意ください。

3.2 CIBA pingモードのサポート

次にCIBA pingモードのサポートです。CIBAはIDトークンやアクセストークンないしはオプションでリフレッシュトークンなどを受け取る手法として poll, ping, push という３つのモードがあります。Kyecloakは13.0.0からCIBAのサポートを開始してから長らくpollモードのみでしたが、15.0.0でpingのサポートが増えました。

3.3 CIBAのサポートレベルが Supported に変更

Keycloak14系ではCIBAに関する機能がPreview状態で、 デフォルトで無効でした。ですがバージョンが上がったことで、Supportedになるとともに、デフォルトで有効になりました。これは、14系のバージョンまでの下記のどちらかの対応が不要になったということです。

  • Dkeycloak.profile.feature.ciba=enabled のようにCIBAの設定だけ有効化する
  • Dkeycloak.profile=preview のように preview 機能を有効化する

4. CIBAの認証方法について

では次にCIBAの認証方法の話についてです。最初に結論を述べますが CIBAで認証の方法は仕様として何も決まっておりません。 

Oauth2.0 ではユーザーの認証の方法は仕様の範囲外のため決まっておりませんが、IDとPasswordでのフォームによるログインをよく見ます。あれらは仕様による制約によるものではありません。

同じようにCIBAも認証の方法は仕様の範囲外のため決まっておりませんが、プッシュ通知をよくみるという話です。勿論、仕様による制約ではありません。

例えば、電車の切符などのようにプッシュ通知が届くスマホを持っている事ということのみで権限がある対象として認証し、購入するかどうか・許可を与えるかどうかを問うケースも考えられますし、派生で指紋認証などで本人を確認するケースも考えられます。この点についてはFAPI CIBAの7.7. Authentication Device securityにも記載されていますが、こちらでも具体的な認証方法などは記載されておりません。

5. 今回試す全体像の説明

先程のパートで認証方式は任意の方法だと説明させていただきました。そこで今回は簡単にプッシュ通知を含んだ処理がどう見えるかを実際に試してみます。

プッシュ通知を試す環境は下記の通りです。

Xcode 12.5.1 (12E507)
環境(シミュレーター) iOS (iPhone SE - 2nd generation)
検証方法 Xcode のシミュレーターにコマンドラインツールでプッシュ通知を呼び出す
今回はKeycloakでプッシュ通知を含めてCIBAのフローを検証します。今回試す処理の簡易のシーケンス図が下記になります。

上記のポーリングでやりとりするケースのシーケンスの中で緑色の点線に囲まれた箇所がCIBAの仕様で決まっている部分で、主に下記の2箇所です。

  • Authentication Request とそのレスポンス
  • Token Request とそのレスポンス
それ以外の箇所はCIBAの仕様で決まっていない部分で、今回はClient側をMacのターミナルのアプリを用います。Keycloakから通信するAuthentication entity以降の流れはXcodeのシミュレーターを用いて、ユーザープッシュ通知で確認していきます。

今回のサンプルアプリケーションやdockerに関するソースコードは下記の場所にアップロードしています。

6. 今回使う環境の説明

ではまず今回試した環境について説明していきます。今回はdocker環境で試すこととします。keycloakのイメージは jboss/keycloak を用いて、認証用のエンティティとしては仮でRuby + Railsで簡易のAPIを実装していきます。

ここで例となるdocker-composeの設定例を記載します。

version: '3.8'

services:
  keycloak:
    container_name: keycloak
    image: jboss/keycloak:15.0.2
    command: -b 0.0.0.0
    ports:
      - "8088:8080"
    volumes:
      - ./docker/keycloak/demo-config/standalone-ha.xml:/opt/jboss/keycloak/standalone/configuration/standalone-ha.xml
    environment:
      KEYCLOAK_USER: admin
      KEYCLOAK_PASSWORD: password
  
  authn-server:
    container_name: authn-server
    build:
      context: ./docker/authn-server
    command: bash -c "rm -f tmp/pids/server.pid && bundle e rails s -p 3000 -b '0.0.0.0'"
    ports:
      - 3000:3000
    volumes:
      - ./docker/authn-server:/my_app

上記のdocker-composeの設定で確認が必要な点は2箇所です。

1箇所目は authn-server についてです。CIBAのドキュメントでは、ADによるユーザー認証の方法を規定しておらず、Keycloakでは、この認証を外部の authentication entity に委ねます。今回の検証では、 authentication entity の機能の一部を行うために authn-server というコンテナを作成します。

また、この authn-server が行うのは下記の２点のみです。

  • APIとして Authentication Delegation Request を
    受け取り、レスポンスを返す
  • プッシュ通知検証用に apns ファイル(JSON)を作成する

制約があまりないためお好きな言語で実装していただけますが、Ruby+Railsのの例だと下記のような感じになります。

module Api

    module V1

      class AuthController < ApplicationController

        def delegation

          alert = {

            title: 'ユーザーの購入の許可の確認について',

            subtitle: "#{params
新規CTA