エンタープライズIT環境での OpenID Connect / SCIM の具体的実装方法 idit2014

エンタープライズIT環境での
OpenID Connect / SCIM の
具体的実装方法
OpenIDファウンデーション・ジャパン
Enterprise Identity WG / 技術TF リーダー
八幡孝（株式会社オージス総研）

OIDF-J EIWGって？
 OpenIDファウンデーション・ジャパン(OIDF-J)
 国内におけるOpenID関連技術の普及・啓蒙のための活動を行なっています。
 Enterprise Identity WG (EIWG)
 エンタープライズIT市場でOpenID ConnectやSCIMなどの仕様をベースと
した、IDフェデレーションやIDプロビジョニングの普及を推進し、新たなビ
ジネスの創造・展開を図ることを目的に活動を行なっています。
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. 1

EIWGの昨年度の活動
 「OpenID ConnectとSCIMのエンタープライズ利
用ガイドライン」を作成
 エンタープライズITでのOIDC/SCIMの有用性
 日本のエンタープライズITへの適用

EIWGの今年度の活動
 ビジネスモデルタスクフォース
 エンタープライズITとクラウドサービスが連携すること
で、Win-Winとなれる連携モデルの検討
 技術タスクフォース
 エンタープライズITとクラウドサービスの連携を進める
ためのサンプル実装の作成、技術課題の検討

エンタープライズにおけるID連携の動向
 オンプレシステム⇒ SaaS活用⇒ BaaS活用
 エンタープライズIT とクラウドサービスの連携

エンタープライズにおけるID連携の動向
 WebアプリのSSO ⇒ APIアクセスのSSO へ拡大
 エージェント・リバースプロキシによるSSO
⇒ SAML連携⇒ OpenID Connect
 CSV配布⇒ 独自I/Fを使ったIDプロビジョニング
⇒ SCIM

OpenID Connect / SCIMを使った
サービス・フェデレーションに向かっている
オーソリテイティブ・
ソース（人事
システムなど）
プロビジョニング・
システム
アイデンティティ・
リポジトリ/ SSO /
トークン管理システム
SaaS
プロバイダ
SaaS
プロバイダ
Web
サービス
Web
サービス
ユーザー・
エージェント
（外部サービス）
ユーザー・
エージェント
（モバイルApp）
企業
ユーザー・
エージェント
（Webサービス）
ユーザー・
エージェント
（デスクトップApp）
http://www.slideshare.net/tkudo/saml-and-openid-connect-for-cloud-service-providers
ユーザー・
エージェント
（Webブラウザ）
API
API
API
API

エンタープライズITで
OIDC/SCIMを実装する
とは、どういうことなのか？

想定するストーリー
 WebアプリへのSSOをユースケースとして扱う。
 認証サーバ(OP) を内部ネットワークに配置できる
ようOIDCではImplicit Flowを使う。
 WebアプリへアカウントをSCIMを使って事前プロ
ビジョニングして利用する。

OIDC/SCIM実装の構成
OP
(OIDC)
IDM
(SCIM-Cli)
Webアプリ
(OIDC-RP)
(SCIM-Svr)
 Implicit Flowの利用
 認証結果の連携
 ユーザ属性の連携
Firewall
 アカウントの事前プロビ
 不要アカウントのデプロビ
Webアプリ
(OIDC-RP)
(SCIM-Svr)
エンタープライズIT クラウドサービス

まずは作ってみた
 OpenAM でOpenID Connect OP を構成する
 Ruby OpenID Connect + Rails でOP/RP を作る
 Java でSCIM Server を作る

実装例: OpenAMを使ったOPの構成
 サービス「OAuth2 Provider」を
追加することでOPを構成
 サポートするフローのタイプ
▪ Implicitフロー、認可コードフロー
 サポートするクレーム
▪ 例. openid, profile, email, …, etc
 IDトークンの有効期間
▪ サポートするIDトークンの署名ア
ルゴリズム
▪ 例. HS256, RS256, …, etc
 IDトークンの署名鍵
 …, etc

実装例: OpenAMを使ったOPの構成
 エージェントの設定で「OAuth 2.0
クライアント」としてRPを登録
 クライアントシークレット
 クライアントタイプ
▪ Implicitフロー, 認可コードフロー
 リダイレクトURI
 サポートするスコープ属性
▪ 例. openid, profile, email, …, etc
 サポートするレスポンスタイプ
▪ 例. code, id_token, …, etc
 …, etc

実装例: Rubyを使ったOPの実装
# -*- coding: utf-8 -*-
class AuthorizationsController < ApplicationController
require 'oidc/request'
require 'oidc/response'
before_action :authenticate_user!
def new
@req = OIDC::Request.new(params)
if @req.valid?
render :new
return
end
if (params[:redirect_uri].present? &&
スクラッチで実装
Application.has_redirect_uri(params[:client_id], params[:redirect_uri]))
redirect_to @req.error.with_fragment(params[:redirect_uri])
else
render json: @req.error.response
end
end
# 同意画面からPOSTされる先
def create
res = OIDC::Response.new(params)
res.owner = current_user
redirect_to res.build_response
end
end
tiny-oidc-provider
├── app
│ ├── controllers
│ │ ├── application_controller.rb
│ │ ├── applications_controller.rb
│ │ ├── authorizations_controller.rb
│ │ ├── jwk_controller.rb
│ │ └── registrations_controller.rb
│ ├── models
│ │ ├── application.rb
│ │ └── user.rb
│ ├── views
│ │ └ ...
│ └ ...
├── lib
│ ├── oidc
│ │ ├── config.rb
│ │ ├── error_response.rb
│ │ ├── request.rb
│ │ └── response.rb
│ └── oidc.rb
└ ...
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
認証状態のチェック
リクエストパラメータの検証
同意画面の表示
パラメータエラーの画面表示
ID Token, UserInfoなどのレ
スポンスを生成
ID Tokenなどをフラグメント
につけて、redirect_uriへリ
ダイレクト
13
次のページで

実装例: Rubyを使ったOPの実装
# -*- coding: utf-8 -*-
...
module OIDC
class Response
...
def initialize(opts)
@client_id = opts[:client_id]
@redirect_uri = opts[:redirect_uri]
@token_type = 'Bearer'
@state = opts[:state]
@nonce = opts[:nonce]
@scope = opts[:scope]
end
# Authorization Request に対するResponse を生成します
#
# @return [String] ハッシュフラグメントで構成されたパラメータを含むURI
def build_response
uri = URI.parse(@redirect_uri)
uri.fragment=(build_params)
uri.to_s
end
private
def build_params
[:token_type, :id_token,:state].inject('') {|str, key|
str << "#{key}=#{self.send(key)}&"
}.chop!
end
14
# ID Token(JWT) を生成します
def id_token
header = UrlSafeBase64.encode64({
:typ => 'JWT',
:alg => 'RS256',
}.to_json)
payload = UrlSafeBase64.encode64(token_data.to_json)
input = header + '.' + payload
signature = UrlSafeBase64.encode64(pkey.sign('sha256', input))
input + '.' + signature
end
def pkey
OpenSSL::PKey::RSA.new(File.read(OIDC::Config.rsa_private_key))
end
# ID Token のクレームを定義
def token_data
issue_at = Time.now.to_i
exp = issue_at + id_token_expire
return {
:iss => issuer,
:sub => owner.sub,
:aud => @client_id,
:exp => exp,
:iat => issue_at,
:nonce => @nonce,
:userinfo => userinfo
}
end
# ownerの情報に対してscopeで指定された情報のみ返却
def userinfo
owner.as_json scopes
end
end
end
スクラッチで実装
JWTヘッダー
ID Tokenに含めるクレー
ムセットを生成
JWSで署名をつける

実装例: Rubyを使ったRPの実装
Ruby OpenID Connect を使って
# -*- coding: utf-8 -*-
class AuthorizationController < ApplicationController
def authorize
redirect_to authz.authorization_uri(new_state, new_nonce)
end
def callback
# @see http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#FragmentNotes
end
def validate
if params['error']
logger.error "error=#{params['error']}, description=#{params['error_description']}"
render :nothing => true, :status => 400
return
end
unless authz.validate(params, stored_state, stored_nonce) == true
render :nothing => true, :status => 400
return
end
session[:id_token] = (authz.oidc.id_token).as_json
session[:user_info] = (authz.oidc.user_info).as_json
end
...
end
15
oidc-implicit-flow-rp
├── app
│ ├── controllers
│ │ ├── application_controller.rb
│ │ ├── authorization_controller.rb
│ │ └── top_controller.rb
│ ├── models
│ │ ├── active_model_base.rb
│ │ ├── authorization.rb
│ │ ├── concerns
│ │ └── oidc.rb
│ └── views
│ └ ...
└ ...
OPの認証エンドポイントへリ
ダイレクトする
コールバック先エンドポイント
フラグメントをPOSTする
JavaScriptを返す
フラグメントのPOST先エン
ドポイント
ID Tokenを検証し、セッショ
ンを生成する
OPがエラーを返した場合の処理
ID Tokenを検証
アプリケーションのセッショ
ンを生成する
次のページで

実装例: Rubyを使ったRPの実装
# -*- coding: utf-8 -*-
require 'base64'
class Authorization < ActiveModelBase
...
def authorization_uri(state, nonce)
client.redirect_uri ||= redirect_uri
client.authorization_uri(
response_type: [:id_token].collect(&:to_s),
state: state,
nonce: nonce,
scope: [:openid, :email, :profile].collect(&:to_s)
)
end
def validate(fragment, state, nonce)
#stateパラメータのチェック
unless fragment['state'] == state then
Rails.logger.error 'invalid state parameter.'
return false
end
# ID Tokenの検証
begin
id_token = decode_id_token fragment['id_token']
id_token.verify!(
issuer: issuer,
client_id: identifier,
nonce: nonce
)
oidc.id_token = id_token
oidc.user_info = id_token.raw_attributes['userinfo']
rescue => e
Rails.logger.error "#{e.message}"
return false
end
return true
end
Ruby OpenID Connect を使って
16
def oidc
@oidc||= OIDC.new
end
private
def client
@client ||= OpenIDConnect::Client.new member_to_json
end
def member_to_json
[:issuer, :identifier, :jwks_uri,
:authorization_endpoint,
:token_endpoint,
:userinfo_endpoint
].inject({}) do |hash, key|
hash.merge!(
key => self.send(key)
)
end
end
def decode_id_token(id_token)
OpenIDConnect::ResponseObject::IdToken.decode id_token, public_keys.first
end
def jwks
@jwks ||= JSON.parse(OpenIDConnect.http_client.get_content(jwks_uri)).with_indifferent_access
JSON::JWK::Set.new @jwks
end
#OpenIDConnect::Discovery::Provider::Config::Response
def public_keys
@public_keys ||= jwks.collect do |jwk|
JSON::JWK.decode jwk
end
end
end
state値の検証も忘れずに
ID Tokenの検証
Ruby OpenID Connect
を使ってID Tokenのデ
コードと検証
署名の検証に必要な鍵は
OPのjwks_uriから入手す
る
Ruby OpenID Connect
を使ってOPの認証エンド
ポイントへのURLを生成

実装例: Javaを使ったSCIMサーバの実装
 SCIMのスキーマ毎と
Bulk操作に対して、エ
ンドポイントを定義

実装例: Javaを使ったSCIMサーバの実装
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// 認証処理
Operation op = new Operation();
boolean result = op.auth( context, request );
if ( !result ) {
// 認証エラー
errorResponse( response, op.getErrorCode(), op.getErrorMessage() );
} else {
// 検索パラメータ取得
String targetId = request.getPathInfo();
String attributes = request.getParameter( "attributes" );
String filter = request.getParameter( "filter" );
String sortBy = request.getParameter( "sortBy" );
String sortOrder = request.getParameter( "sortOrder" );
String startIndex = request.getParameter( "startIndex" );
String count = request.getParameter( "count" );
// 検索
JsonObject searchResult = op.search(context, request, targetId, attributes, filter,
sortBy, sortOrder, startIndex, count );
}
 各エンドポイントに認証処理
を実装。Basic認証、OAuth2
を使った認証など。
 SCIMの仕様ではOAuth2が推
奨されている。
 パラメータ取得。
 GETの場合はQUERYパラメー
タから取得。
 POST, PUT, PATCH操作の場
合は、リクエストボディで送
られてくるJSONの取得と解
析が必要。
 実際のオブジェクトへの操作
を実装。
 バックエンドにDBやLDAPを
使う設計としてそれらへの操
作を実装する。

OIDC: 実装簡単。考慮点多い。
 ライブラリもあるし、製品でも対応。実装は簡単。
 OP/RPの連携で認証機能を実現。考慮点は多い。
 エンタープライズIT(OP) とクラウドサービス(RP)
 OPができること、RPができること
 OPで対応すべきこと、RPで対応すべきこと
 相互接続性を保つための取り決め

SCIM: 実装はやや難。SCIM 2.0対応を視野に。
 使えるライブラリ、フレームワークが不足。
 JSON処理以外はほぼスクラッチ
 SCIM 2.0仕様は、2014年末にリリース予定
 現在draft の更新が活発
 SCIM 1.1 -> SCIM 2.0 の変更は多い。
 実装はSCIM 2.0 への対応をにらんで。

認証基盤を作るときによく検討されること
検討事項
認証された
ユーザに
関する情報
の連携方法
ID/コード系
表示情報系
セッション
管理
アイドル
タイムアウト
セッション
タイムアウト
特定機能利用時の再認証処理
特定機能利用時の強い認証の
要求
従来型の認証基盤
（一元管理）
HTTPヘッダで連携する
 連携されたIDでLDAP問合せ
 事前にプロビしておく
 HTTPヘッダで連携する
認証基盤でタイムアウト処理
認証基盤でタイムアウト処理
認証基盤がURLで機能判定し、
認証画面を表示
認証基盤がURLで機能判定し、
追加の認証画面を表示
フェデレーション型の認証基盤
（分散協調型の管理）
トークンで連携
 トークンで連携
 ユーザー情報APIから取得
RP側で実装が必要。セッション
状態の受け渡し方法が課題。
RP側からOPへ再認証を要求する
方法の取り決めが必要。
RP側からOPへ強度の強い認証を
要求する方法の取り決めが必要。

信頼できるクラウドサービスがエンプラITとつながる
 エンプラ側の視点で
言えば、多くのこと
がRPの実装に依存
した状態。
 信頼できるRP
(正しく実装された
クラウドサービス)
をエンプラITは求
めるようになる。
検討事項
認証された
ユーザに
関する情報
の連携方法
ID/コード系
表示情報系
セッション
管理
アイドル
タイムアウト
セッション
タイムアウト
要求

考慮点についての
技術TFでの検討内容

技術TFでの検討状況
検討事項
認証された
ユーザに
関する情報
の連携方法
ID/コード系
表示情報系
セッション
管理
アイドル
タイムアウト
セッション
タイムアウト
要求
利用する属性の共通化
を検討中
セッション管理方式の
共通化を検討中
今後検討予定

利用属性の共通化の検討
検討事項
認証された
ユーザに
関する情報
の連携方法
ID/コード系
表示情報系
セッション
管理
アイドル
タイムアウト
セッション
タイムアウト
要求
を検討中

利用属性の共通化の方針
 OIDC/SCIMの両方で同じ属性を扱う
 対応すべき属性を3つのレベルに分類
 RP（クラウドサービス）を動かすための最小限の属性
 エンタープライズITで通常扱う属性
 エンタープライズITで必要となりうる属性

利用する属性を3つのレベルに整理
レベル1属性（RPを動かすための最小限の属性）
属性SCIM Schema (*1) OIDC Claims
ユーザーID externalId, userName sub
メールアドレ
ス
emails email
– email_verified
名前name.formatted name
name.givenName given_name
name.familyName family_name
name.middleName middle_name
更新日lastModified updated_at
状態Active –
パスワード使用しない–
レベル2属性（エンタープライズITで通常扱う属性）
従業員番号employeeNumber Claimの拡張が必要
組織コードorgUnitCode(*2) Claimの拡張が必要
組織名orgUnitLocalNameValue
(*2)
Claimの拡張が必要
役職コードtitleCode(*2) Claimの拡張が必要
役職名titleLocalNameValue(*2) Claimの拡張が必要
電話番号phoneNumbers phone_number
…
レベル3属性（エンタープライズITで必要となりうる属性）
言語locale locale
表示順displayOrder Claimの拡張が必要
…
*1: SCIM2.0 draft-06の項目名で整理
*2: 「OpenID Connect とSCIM のエンタープライズ利用ガイドライン」
で定義したOrganizationalUnitリソース、Titleリソースの属性

OIDCでの連携方法～ scope
 レベル1属性はscope=email profile で要求できる。
 レベル2、レベル3属性を要求するために拡張scope
を定義する。
 それぞれにscope名を定義
 名称は検討中

OIDCでの連携方法～ IDトークンへの埋め込み
 IDトークンに
userinfo claim
を追加して応答
{
"iss": "http://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"userinfo": {
"name": "日本太郎",
"given_name": "太郎",
"family_name": "日本",
"email": "nippontaro@example.com",
"orgUnitCode": ["0111", "0211"],
"orgUnitLocalNameValue": ["営業部", "企画部"],
"titleCode": "002",
"titleLocalNameValue": "部長",
"locale": "ja_JP"
}
}

OIDCで使う時に連携か？SCIMで事前プロビか？
 アプリケーションの特性で使い分ける
 属性の特性で使い分ける
 サービス側の使い方で決まることではあるが、クラ
ウドサービス横断で利用することを前提に共通化を
検討

セッション管理方式の共通化の検討
検討事項
認証された
ユーザに
関する情報
の連携方法
ID/コード系
表示情報系
セッション
管理
アイドル
タイムアウト
セッション
タイムアウト
要求
セッション管理方式の
共通化を検討中

セッション管理方式の検討の必要性
従来型のSSO フェデレーション型SSO
 ゲートウェイのように構成され
た従来のSSO
 統制（アプリへのアクセス制
御）観点のセッション管理は
SSOだけで実装
セッション管理方式の共通化
 フェデレーション型では、セッ
ション管理はRPの実装に依存
 統制観点のセッション管理のた
めに、OP-RP間の方式の取り決
めが必要
ユーザーSSO アプリユーザー
OP(SSO)
RP(アプリ)

セッション管理方式の検討ポイント
 RPがOPにセッションの状態を確認する方法
 タイムアウト後はアプリ(RP) が利用できないよう
にするためのOPの振る舞い
 無効化されたアカウントのセッション停止
 ユーザーの利用への影響、開発者の対応のしやすさ

セッション管理方式の選択肢
 OpenID Connect Session Management
 IDトークンの有効期限毎にセッションを更新
 プロンプト無しで認証フローの再実行
 リフレッシュトークンを使った認証情報の更新
 デプロビジョニングによるコントロール
34

OpenID Connect Session Management
 OpenID Connect Session
Management 1.0 - draft 21
 http://openid.net/specs/openid-connect-
session-1_0.html
 セッション確認のリアルタイム性は高い
 OPへの負荷との調整しだいだが、分単位
で状態の反映が可能
 対応のためには全アプリ画面へのiframe
埋め込みが必要。改修コストは高め。
ブラウザ
OP iframe
client_id +
session_state
セッション状態の
問合せ（非同期）
changed /
unchanged
RP iframe
OP

プロンプト無しで認証フローの再実行
ブラウザ
36
 IDトークンの有効期限毎にIDトークンを
取り直すことでセッションを更新する
 セッション確認の精度は数時間オーダー
 IDトークンの有効期限が1時間なら、確認精度は1時間
 対応のためにはアプリのセッション管理
部分の改修が必要。コールバックを扱う
処理が必要。対応コストは中くらい。
 IDトークン再取得をするときにPOST
データが失われる制限あり。
Session
Manager
OP
アプリ
IDトークンの
有効期限をチェック
新しいIDトークンと
ともに元のURLへ復帰
prompt=none
で認証フローを再実行

リフレッシュトークンを使った認証情報の更新
ブラウザ
37
 IDトークンの有効期限毎にIDトークンを
取り直すことでセッションを更新する
 セッション確認の精度は数時間オーダー
 IDトークンの有効期限が1時間なら、確認精度は1時間
 対応のためにはアプリのセッション管理
部分の改修が必要。対応コストは低め。
 OPがAuthorization Code Flowに対応す
る必要あり。DMZへの配置が必須。
 POSTデータが失われることはない。
 Offline Clientを使う場合のRefresh
Token の用法との整合について要検証。
Session
Manager
OP
アプリ
IDトークンの
有効期限をチェック
リフレッシュトークンを使って
新しいIDトークンを取得

デプロビジョニングによるコントロール
 セッションタイムアウトには対応できな
いが、無効化されたアカウントの利用は
確実に停止する。
 ID管理によるデプロビジョニングを実行
することで実現。ID管理が実現されてい
れば対応コストは不要。
アプリ
ユーザー
テーブル
無効化されたユーザーの
継続利用はできなくなる
ブラウザ
無効化されたユーザーの
デプロビジョニング処理
IDM OP

セッション管理方式の共通化の方向性
方式確認の精度アプリ開発者視点アプリ利用者視点
OpenID Connect
Session Management
○
分オーダーでの精度で確認
可能
×
全画面へiframe埋め込みが必要
△
UXは現状のアプリのまま維持
できる。ブラウザの対応につ
いては検証が必要
プロンプト無しで
認証フローの再実行
△
時間オーダーの精度で確認
可能
△
セッション管理部の改修。コー
ルバックを扱う処理が必要
×
セッション更新時にPOSTデー
タが失われる可能性がある
リフレッシュトークンを
使った認証情報の更新
(OPがCodeフローに対応し、DMZ
に配置される必要あり)
△
時間オーダーの精度で確認
可能
○
セッション管理部の改修。
○
できる
デプロビジョニングによる
コントロール
×
無効化されたアカウントの
停止にとどまる
―
（改修なし）
○
できる
目指すところはOIDC Session Management。アプリ対応コストが高いため、過渡的な選択肢は必要。
いずれの方式も課題はあり、技術TF内で継続検討する。

今後の活動
 サンプル実装の継続
 コードサンプル、製品設定サンプル
 考慮点の検証、相互接続性の検証
 エンタープライズ向けOpenID Connect / SCIM
実装ガイドラインとして文書化
 年内の公開を目指して活動中
41

エンタープライズIT環境での OpenID Connect / SCIM の具体的実装方法 idit2014

エンタープライズIT環境での OpenID Connect / SCIM の具体的実装方法 idit2014

More Related Content

What's hot

Viewers also liked

Similar to エンタープライズIT環境での OpenID Connect / SCIM の具体的実装方法 idit2014

Recently uploaded

エンタープライズIT環境での OpenID Connect / SCIM の具体的実装方法 idit2014