次世代認証連携への学認の取り組み

認証プロキシサービスの試み
坂根 栄作
国⽴情報学研究所
2021/12/17

認証プロキシサービスの研究開発• 背景• 研究コミュニティは独⾃のトラストフレームワークをもつ。国家規模での認証エコシステム構築にむけて、たとえば IdP の機能を、⼤学・研究機関の IdP に置き換えるのは容易ではない• ポリシ・マッチングが⾃明ではない• ⼤学・研究機関 IdP と研究コミュニティ SP との調整は煩雑（両者の視点から）• 研究コミュニティでは産学連携は特別なものでない

例えば HPCI とか…

• ⽬的• 産学連携を念頭においた SP への Id 連携時に必要な Id 保証の担保などに柔軟に対応する• 既存の研究コミュニティのもつトラストフレームワークにおいて、Id 基盤部分を外だしできるようにする• ⽅法• OpenIdP をはじめとする各種既存 IdP や gBizID 等と各種 SP の間に配置する認証プロキシサービス (IDaaS) を導⼊する• 基本機能要件• 利⽤者と Id の紐付けできること（複数の Id にも対応︓Id 連携）• 総合 IAL/AAL 判定できること• 属性保証ができること• それぞれの関係者が必要な設定を⾏えること

認証プロキシのデザイン案
公的個⼈認証 gBizID

IdP

IdP

携帯事業者

ORCID

IdP

IdP

機関契約
MS/Google 機関IdP

IdP

IdP

属性プロバイダ群…

⾝元確認・本⼈確認
プロジェクト管理者
HPCI管理者などによる確認（属性付与）

認証プロキシ

紐付け・総合IAL/AAL判定
フィルタ
フィルタ

産学連携

IdP
新OpenIdP

IdP

所属メンバ情報提供

フィルタ

共同研究
PJ

機関

IdP

IdP

機関

KAGRA, HPCI, etc.
EJ等

LIGO等
MDX/GakuNin RDM SP

GakuNin/eduGAIN

SP

SPSP
Original: Prof. Motonori Nakamura

認証プロキシサービスの適⽤例• 新しいトラストフレームワークにより、関係者 (Participants) 間のポリシマッチングの議論が効率的に⾏える• 認証プロキシサービスが、研究コミュニティ (SP) と、利⽤者の所属機関による IdP との橋渡しを⾏う
新しいトラストフレームワーク

既存IdP

A⼤学
IdP

認証プロキシServiceY

B⼤学
IdP
企業の研究者
⼤学の研究者

ServiceX

ServiceA

Service
B

研究コミュニティQ

研究コミュニティP

次世代認証連携における認証プロキシ実装• 認証プロキシサービスの基本機能の設計・試作完了• 認証プロキシコア部 (IDaaS) - SELMID• ID 登録、ログイン、ID 紐付け、ID 紐付け解除、属性更新• 各種機能設定インターフェイス部（マイページ機能）• 今年度の開発⽬標• GakuNin RDM での実運⽤を⽬指す• 機能要件定義• 産学連携研究プロジェクトを想定し、実証評価実験を実施• 企業の研究者の⽅が、認証プロキシサービスを利⽤してサービスにアクセス

FY21 エンハンス事項⼀覧
1. SP管理機能（管理者向け機能）l

SP毎に要求するIALおよびAALを設定する機能

2. SP単位の同意管理機能lll

利⽤者がSPに初回ログインする際に同意を取得する機能
利⽤者が⾃⾝の同意状態の確認・取り消しが出来る機能
管理者が機関内のユーザの同意状態を確認する機能

3. 属性保証（旧機関管理）ll

管理者が管理対象ユーザの属性を保証する機能
例）⾃機関に所属するユーザの所属属性を保証する（招待による確認〜属性付与）

4. その他
ll

画⾯デザイン
現 OpenIdP からの移⾏・切り替え

次のスライドから現在開発中のものを含みますのでご留意ください61. SP管理機能
l 管理者向けSP管理ページからSP毎に要求するIAL/AALを設定する
l 設定したIAL/AALはデータベースへ保持（マイページDB and/or SP側DB）
l 利⽤者がSPへログインする際にSELMIDで対象SPのIAL/AAL要件をチェックし必要な制御を⾏う

SP管理者
利⽤者

SP B
• SP Aからの認証リクエス
トにはIAL/AAL要件あり• SP Bからの認証リクエス
トにはIAL/AAL要件なしAuthnContextRefがあれば優先管理者

SP A

AuthnContextRefを設定する

SP BのIAL/AAL要件をREST API
で問い合わせ管理者
ページDB

SELMID
IAL/AAL要件によりログイン制御を⾏う

AuthnContextRefがなければDBに問
い合わせ

SELMID範囲• SPからのリクエストにIAL/AALが無かったらSP管理DBへ問い合わせる

IAL/AAL要件
を保持（機関＋SP単位）

SP単位の管理者︓RDM担当
システム管理者︓NIIのIdP担当者
機関管理者︓CTCの管理者

マイページ範囲• 登録画⾯• DB構築〜レコード管理• REST API公開• SP側のDBへの書き込み（やるか︖）

7

仕様案
l SPからの認証コンテキスト要求（AuthnContextClassRef）に設定する値
l ⼀つの⽂字列しか設定できないのでIAL/AALの組み合わせ⽂字列の設定が必要
l 例）IAL2_AAL2（強度の順番を決める必要あり）

l データベースとのI/F（REST API）l メソッド︓GET/POSTのみ

l 認証︓Bearerトークン、BASIC認証、クライアント証明書認証
l SELMID⇒APIへのパラメータの渡し⽅lQueryString、Urlの⼀部（https://xxx.example.com/{username}）、Form、JSON、ヘッダl API⇒SELMIDへのレスポンス
lHTTPコード︓200 or 4xxl

JSONをボディで返却

参考）https://docs.microsoft.com/ja-jp/azure/active-directoryb2c/restful-technical-profile

{}

成功

{

“displayname": “Naohiro Fujie",“email": “hoge@example.com"}失敗"version": "1.0.0","status": 409,
"code": "API12345","requestId": "50f0bd91-2ff4-4b8f-828f-00f170519ddb","userMessage": "Message for the user","developerMessage": "Verbose description of problem and how to fix it.","moreInfo": "https://restapi/error/API12345/moreinfo"8

仕様案
l SP管理データベースの構造
l SP共通SPのID（SAMLRequest内のProviderNameと同じ値）
l AuthnContextClassRefの初期値
l 初期値以下のレベルの設定の許可・不許可フラグ
lAPIとしてはレコードが存在しなかった
ら初期値を返却

l 機関単位l

SPのID（SAMLRequest内のProviderNameと同じ値）

機関名（SELMIDに持つ所属組織名と同じ値）
l AuthnContextClassRef
l複合キー

l AuthnContextClassRefの値（SAMLRequestに⼊るものと同じ値）

9仕様案
l 認証コンテキストの優先順位（SELMID内の処理）
SPからの認証要求
2. ユーザ認証（IAL、所属情報の取得）
1.
3.

認証要求内にAuthnContextClassRefがあるl4.

コンテキストに応じたユーザ評価（IALを満たさない場合はブロックor追加IAL要求）

認証要求内にAuthnContextClassRefがない

SP、所属情報（機関名）を使ってデータベースからAuthnContextClassRefを取得
l コンテキストに応じたユーザ評価（IALを満たさない場合はブロックor追加IAL要求）l5.

AALの要求レベルに応じて多要素認証の強制

10

仕様案
l 管理機能の利⽤範囲
l

SP管理者
l

AuthnContextClassRefの初期値設定l

初期値以外の値を機関管理者が設定可能かどうかのフラグ設定

l

l

l

すべての機関に対して許可l

特定の機関に対して許可初期値を下回る値を機関管理者が設定可能かどうかのフラグ設定
l

すべての機関に対して許可l

特定の機関に対して許可

機関管理者
l

SP管理者が設定を許可していない場合
ll

SP管理者が設定を許可した場合
ll

設定値の閲覧

初期値以外の値を設定

システム管理者
l

SP管理者、機関管理者の替わりに設定可能

11

2. SP単位の同意管理機能l 利⽤者がSPに初回ログイン時にID連携に関する同意を取得する
l 利⽤者がマイページから⾃⾝のID連携/同意状態の確認、取り消しが出来る
l 管理者が⾃機関に所属する利⽤者のID連携/同意状態の確認が出来る（⾃機関内で特定のSPを使っている利⽤者⼀覧の把握など）
マイページ

利⽤者

ID連携/同意状態/最終ログイン⽇付の表⽰
同意取り消しDB同意同意SP

利⽤者毎の状態保持

同意履歴︖

IdP

IdP
XX⼤学
ShibSPSELMID
同意状態に応じて同意画⾯の表⽰制御REST API経由でR/W• 同意状態を確認• 同意結果を書き込み• 最終ログイン⽇付書き込み（やるか︖）

機関管理者

管理者
ページ

同意段階
1. 未同意2. 同意済みだが再同意が必要
3. 同意済み

マイページ範囲• ユーザ管理画⾯• DB構築〜レコード管理• REST API公開SELMID範囲• ユーザ管理DBへ同意状態を問い合わせ、必要に応じて同意画⾯を表⽰する• 同意結果、ログイン⽇付をDBへ書き込む

12

仕様案
l 同意管理データベースの構造

l ユーザID（ePPN※SP側に出⼒するID）
l SP（ProviderName）

複合キー

l 同意状態（1/未同意、2/同意済みだが再同意が必要、3/同意済み）
l 同意済みの規約バージョンl 同意⽇付l 最終ログイン⽇付

l 要決定事項l 同意履歴を持つかどうか

l DBとのI/F

l 前述と同様
13

仕様案
l 同意規約バージョンの管理

l 規約を変更した場合はSELMIDにHTMLの設定、規約バージョンを更新する

l ユーザの同意済みバージョンと最新規約バージョンを⽐較し、再度同意を求めるかどうかを判断する

l SELMID内の処理

l SPからの認証要求
l ユーザ認証l APIでDBから同意状態を取得
l同意バージョンの⽐較︓同意バージョンが古ければ再同意を求める

l同意状態の⽐較︓未同意、同意済みだが再同意が必要なら同意を求める

l 同意の取得
l規約の表⽰、同意状態保存の選択（毎回同意させるかどうか）l APIでDBへ同意状態を保存
14

仕様案
l 管理者機能l 機関管理者l

⾃機関に属するユーザのSP利⽤状況を⼀覧表⽰、ダウンロード
l

検索時点でSPに同意済みのユーザ⼀覧l同意フラグ状態、同意⽇付、同意対象規約、最終ログイン⽇付

l 利⽤者向け機能

l ⾃⾝が利⽤しているSP⼀覧の表⽰l

同意済みSP⼀覧l

同意フラグ状態、同意⽇付、同意対象規約、最終ログイン⽇付l SPへの同意状態の変更
l

同意フラグの再選択l

未同意、同意済みだが毎回再同意、同意済み

15

3. 属性保証（旧機関管理）
l 機関管理者がユーザの属性を保証するための機能
l 本ステップでは⾃機関に所属していることを保証する
l 保証⽅式としてはメールによる招待とする
利⽤者• 招待メールをクリックす
るとSELMIDのサインアップ/サインイン画⾯へ誘導• 属性登録後はマイページへランディング

要検討• 複数組織に所属するユーザがSPへログインする際に送出属性選択をさせるか︖• 所属属性の保持場所

マイページ

所属属性の読み込み

招待メール送信継続検討︖来歴管理も持つ︖
アカウント選択︖⇒ミニマム・オプションのパターン

管理者

管理者
ページ要検討• メールシステムをどうするか︖

SP
当該ユーザの所属属性を更新

DBSELMID
招待リンクの内容に従い所属属性を付与

SELMID範囲• メールリンクからユーザ属性更新するフロー作成• 所属属性のDB書き込み

招待ステータス管理
複数所属属性保持マイページ範囲• 招待管理画⾯• DB拡張（ステータス管理、複数所属保持）• 招待メール作成（招待⽤リンクの作成）※JWT形式（署名付きJSON）

16

仕様案
l 要検討事項
複数組織からの招待を受けるか
l シンプル実装にするなら後勝ちで所属をシングルバリューで持たせる形
l 将来的には機関単位で所属を持てるようにするべき︖
ll

複数組織に登録できる場合、IALとの関係は︖（誰がその⼈のIALに責任を持つのか）l

SP単位、組織単位でIAL/AAL要求があった場合は特に

l 導⼊ステップ案
1.

まずは単⼀組織からスタート
ll2.

複数組織からの招待を同⼀メールアドレスで受けられるようにエンハンスll3.

この時点では基本は組織単位でアカウントを使い分けてもらう想定
ePPNは変えずにメールアドレスを付け替えてもらうことでSP側でのデータ保全
SPへ連携する場合、どの組織の構成員としてアクセスするか選択できる画⾯が必要
同時に同意状態（どの組織として同意したか）、などの整理も必要

ePPNの複数化、IALの調整
llePPNと組織とIALのセットをDB管理
外部IdP（GビズIDなど）でIALをセットする際もどの組織に所属している⼈として保証されるか選択

17

仕様案
l 要決定事項

l 機関名、機関コードの払い出し、マスタ管理︖
l

誰が最初に機関名を決定するのか︖
l例）最初にアカウントを作った管理者がNIIに申請し、NII管理者が対象アカウントに機関を割り当てる

l 利⽤するメールシステム
l

NIIのメールシステムを使えるか︖

l

送信APIでメールを送信する仕組みが存在するか︖（SendGridのようなメール送信APIがあるか︖）

18

仕様案
l⼀連のフローl

機関管理者
l

招待対象者のメールアドレスをデータベースから検索l

既に存在する場合l

⾃機関に所属している場合︓操作不要l

⾃機関に所属していない場合︓• 現所属の表⽰（確認のため）• 招待の送信 ⇒招待中フラグを管理DBにたてるl

存在しない場合
ll

招待の送信 ⇒管理DBにレコードを作成し、招待中フラグをたてる

利⽤者l

招待メールを受け取りURLをクリック
l

ログイン⇒ id_token_hint内に設定されたメールアドレスとログインした⼈の⼀致をチェック

アカウントがない場合
ll

Id_token_hintの内容（抜粋）{“id”: “{対象者のメールアドレス}”,“organization”: “{招待する機関コード}”“exp”: “{有効期限}”}⇒このJSONをエンコードしデジタル署名する（ライブラリ有）

既にOrthorosにアカウントがある場合
ll

招待メール内のリンク
https://{SELMIDのアドレス}?id_token_hint={エンコード/署名されたJSON}

サインアップ⇒ 対象者のメールアドレスにワンタイムコードを⾶ばしアドレス所有確認

ログイン・サインアップした利⽤者の所属属性にid_token_hint内の機関コードが設定される
l

設定が完了したら管理DBの招待完了フラグをたてる
19

仕様案
l 管理DBの構造（基本はユーザDBへのカラム拡張）
l 招待状態（招待中、完了）
l 招待⽇付l 完了⽇付20まとめ• 認証プロキシサービスの研究開発• 産学連携を念頭においた SP への Id 連携時に必要な Id 保証の担保などに柔軟に対応する• 既存の研究コミュニティのもつトラストフレームワークにおいて、Id 基盤部分を外だしできるようにする• 2022年度 Open Forum にてデモンストレーションを予定︕

Orthros