エンタープライズitでのopenid connect利用ガイドライン

工藤達雄（株式会社野村総合研究所）

野村健太郎（オープンソース・ソリューション・テクノロジ株式会社）

エンタープライズITでの

OpenID Connect利用ガイドライン

Copyright 2013 OpenID Foundation Japan - All Rights Reserved.

目次

はじめに

エンタープラズITにおけるフェデレーションの要件

エンタープラズITにおけるOpenID Connectの適用例

まとめ

1


はじめに

登場人物

OP: クラウドサービス利用企業(の認証システム)

RP: クラウドサービス事業者

エンドユーザー、サービス利用者: クラウドサービス利用

企業の従業員

今回は、RPはサーバーサドゕプリケーションであ

ることを前提としている

2

エンタープライズ IT における

フェデレーションの要件

3


企業利用における特有の要件（1）

クラウドサービスに情報を渡す手段と、渡す情

報の内容

IDプロビジョニングあり/なし？

メールゕドレスや社員番号を渡すか？それとも PPID

（ランダム文字列、仮名）を渡すか？

OPのネットワーク構成

OPはフゔゕウォールの内にあるか、外にあるか?

4


企業利用における特有の要件（2）

ユーザーンターフェース

わかりやすいものがよい

ログン時の OP 選択画面は企業利用では不要？

情シス部門への問い合わせが増えるのはヤ

セキュリテゖレベルに応じた認証の実施

管理者向けコンテンツへのゕクセス時は多要素認証実施など

シングルログゕウト

できたらうれしいけど、実装は大変？

5

エンタープライズ IT における

OpenID Connectの適用例

6


OpenID Connect 適用のための検討事項

処理フローの選択

ユーザー識別子(IDトークン)

連携する属性情報(クレーム)

ユーザーンターフェース(ログン画面)

再認証処理


7







再認証処理


8



認可コードフロー

9

エンドユーザー RP OP

認可リクエスト

認可

エンドポイントログイン画面・同意画面の表示と認証

認可コード発行

アクセストークン

IDトークン

認可コードトークン

エンドポイント

UserInfo

エンドポイント

属性情報(クレーム)

認可コード

アクセストークン

RPからOPへの直接通信 RPからOPへの直接通信



Implicit フロー

10

エンドユーザー RP OP

認可リクエスト

認可

エンドポイントログイン画面・同意画面の表示と認証

ID トークン発行 IDトークン

IDトークン

ID トークンは URL フラグメントなので、リダイレクトで RP には送信されない

JavaScript を利用して、ID トークンを RP に送信

IDトークン

ID トークンの署名を検証


OPの配置によって処理フローを選択

11

認可コードフロー Implicit フロー

本来の想定用途

RP がサーバーサイド

アプリケーション

(Web アプリ)

RP がクライアントサイド

アプリケーション

(スマホアプリなど)

OP と RP の間の

サーバー間通信有無

ID トークンの

署名検証不要

必要

(署名用の鍵の管理が必要)

企業利用における

使い分け

OP が DMZ に

配置されている

OP がファイアウォール内に

配置されている


Implicitフローの場合にはIDトークンの検証が必須

IDトークンがエンドユーザーのブラウザを介し

て渡されることから、改ざん対策が必要

OP側の処理

▪IDトークンにデジタル署名、もしくは、MAC値を付加する

RP側の処理

▪IDトークンのデジタル署名/MAC値を検証する

12


IDトークンの検証に必要な「鍵」をどう運用するか

デジタル署名を利用する場合

公開鍵をRPに渡す必要がある

▪RP側で登録ンターフェースを用意し、OPがゕップロード

▪OP側で公開し、RPがダウンロード

MACを利用する場合

共通鍵をOPとRPとで共有する必要がある

共通鍵としてクラゕントシークレットを使うことも可能

▪クラゕントサドゕプリではやってはいけない！

13







再認証処理


14


ユーザー識別子の必要条件

ユーザー毎に一意であり、かつ再利用されてはならない

IDトークンの sub パラメーターの値

15

名寄せ可能な情報名寄せ不可能な情報

[email protected]

OP

RP2

[email protected]

RP1

[email protected]

OP

RP2

kodfas74

RP1

3jhfds2a

RP1: kodfas74 RP2: 3jhfds2a


ユーザー識別子の種類の使い分け

16

名寄せ可能な情報名寄せ不可能な情報

例メールアドレスランダム文字列

(仮名、PPID)

セキュリティ

(プライバシー保護) 普通高

OP 側の運用容易若干複雑

RP 側の運用容易若干複雑

使い分け実装コスト、運用効率重視セキュリティ重視







再認証処理


17



ユーザー識別子以外に RP が必要とする情報

氏名、所属部門(グループ)、連絡先など

コンシューマー環境とは異なり、全ての属性情

報を個人が所有しているわけではない

所属する企業により付与された属性情報

所属する企業とは関係しない属性情報

従業員が行う業務に関連した情報

18



RP は以下のような手段で情報を取得する

OPからのゕデンテゖテゖ・プロビジョニング

▪一番わかりやすくて、管理しやすい

フェデレーションによる取得

▪必要なときに必要な分だけ情報をもらうことができる (Just In Time

Provisioning)

▪2つの方法

▪IDトークンに含めてもらう

▪UserInfo エンドポントから取得する（RPからOPへの直接通信が可能な場合）

サービス利用者が直接 RP の画面から入力

19






ユーザーインターフェース(ログイン画面)

再認証処理


20


コンシューマー向けサービスの場合、ログインページにOP の選択肢を表示するのが一般的

21

Browser

ローカル認証

OP

ユーザー名

パスワード

Yahoo! Google

ログイン


エンタープライズITにおける要件

自社の会社名を一覧に表示してほしくない

他の利用企業に知られてしまう

サービス利用者が迷うようなンターフェース

は極力無くしたい

情報システム部門への問い合わせ増大を招きたくない

22


想定される実装案

RPがサービス利用企業ごとに一意となるURLを用意

ゕクセスしてきたサービス利用者に対応するOPを判別

し、自動的にそのOPへ遷移させる

▪SAMLのSP-Initiated SSO のメージ

OPは社内ポータルなどにRPへのリンク(上記の一意な

URL) を張っておき、サービス利用者に案内する

Account Chooser を使うという手も

サービス利用者への周知がポント

23







再認証処理


24


どのような状況において再認証処理が必要か

セキュリテゖレベルが高いコンテンツにゕクセ

スする場合

多要素認証などで認証させたい

RPに対して更新系のリクエストを送る場合

その前にID/パスワードの入力を再度求めたい (CSRF

対策など)

25


再認証処理の実現方法

「認証コンテキスト・クラス・リフゔレンス」

を利用

RP は認可リクエストで認証レベル(LoA)を指定

▪acr_values パラメーター

OP は要求されたレベルの認証を実施して、結果を ID

トークンに入れて返す

▪acr パラメーター

26







再認証処理

シングルログアウト

27


シングルログアウト

シングルサンオンしたのであれば、ログゕウ

トも一度の操作で完了したい

OpenID Connect 仕様の Session Management を

利用

HTML 5 を利用

環境によっては少しハードルが高いかもしれない

28


工夫で実現

よくあるやり方

RP 側のセッションタムゕウト時間を短めに設定してお

く(例えば 30 分)

▪セッションがタムゕウトしたら、再び OP に認可リクエストを

送信する

一方、OP のセッションタムゕウト時間を実用に耐える

時間(8時間など)にしておく

▪RP から短い間隔で認可リクエストを受け取っても、サービス利

用者からすれば、認証操作を行うことなくゕクセスし続けている

ように見える

29

まとめ

30


まとめ

エンタープラズ IT における OpenID Connect の

適用方法、フェデレーションの実現方法を検討した

現在のOpenID Connect仕様は、多くの場合、フェ

デレーションの要件に対応可能であると考えられる

OpenID Connectをどう適用するかについては、プ

ロビジョニングの有無、OP のネットワーク構成な

どが大きな考慮点となる

31

エンタープライズitでのopenid connect利用ガイドライン

Technology