エンタープライズit環境での openid connect / scim の具体的実装方法 idit2014

OpenIDファウンデーション・ジャパン

Enterprise Identity WG / 技術TF リーダー

八幡孝（株式会社オージス総研）

エンタープライズIT環境での

OpenID Connect / SCIM の

具体的実装方法

Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. 1

OIDF-J EIWGって？

OpenIDファウンデーション・ジャパン (OIDF-J)

国内におけるOpenID関連技術の普及・啓蒙のための活動を行なっています。

Enterprise Identity WG (EIWG)

エンタープライズIT市場でOpenID ConnectやSCIMなどの仕様をベースと

した、IDフェデレーションやIDプロビジョニングの普及を推進し、新たなビ

ジネスの創造・展開を図ることを目的に活動を行なっています。


「OpenID ConnectとSCIMのエンタープライズ利

用ガイドライン」を作成

エンタープライズITでのOIDC/SCIMの有用性

日本のエンタープライズITへの適用

EIWGの昨年度の活動


ビジネスモデルタスクフォース

エンタープライズITとクラウドサービスが連携すること

で、Win-Winとなれる連携モデルの検討

技術タスクフォース

エンタープライズITとクラウドサービスの連携を進める

ためのサンプル実装の作成、技術課題の検討

EIWGの今年度の活動


オンプレシステム ⇒ SaaS活用 ⇒ BaaS活用

エンタープライズIT とクラウドサービスの連携

エンタープライズにおけるID連携の動向


WebアプリのSSO ⇒ APIアクセスのSSO へ拡大

エージェント・リバースプロキシによるSSO

⇒ SAML連携 ⇒ OpenID Connect

CSV配布 ⇒ 独自I/Fを使ったIDプロビジョニング

⇒ SCIM

エンタープライズにおけるID連携の動向


OpenID Connect / SCIMを使ったサービス・フェデレーションに向かっている

http://www.slideshare.net/tkudo/saml-and-openid-connect-for-cloud-service-providers

オーソリテイティブ・ソース（人事システムなど）

プロビジョニング・システム

アイデンティティ・リポジトリ / SSO /

トークン管理システム

SaaS

プロバイダ

SaaS

プロバイダ

Web

サービス

Web

サービスユーザー・エージェント

（Webブラウザ）

ユーザー・エージェント（モバイルApp）

ユーザー・エージェント

（外部サービス）


（デスクトップApp）


（Webサービス）

企業

API

API

API

API

エンタープライズITで

OIDC/SCIMを実装する

とは、どういうことなのか？


WebアプリへのSSOをユースケースとして扱う。

認証サーバ (OP) を内部ネットワークに配置できる

ようOIDCではImplicit Flowを使う。

WebアプリへアカウントをSCIMを使って事前プロ

ビジョニングして利用する。

想定するストーリー


OIDC/SCIM実装の構成

IDM(SCIM-Cli)

Webアプリ(OIDC-RP)(SCIM-Svr)

OP(OIDC)

Implicit Flowの利用認証結果の連携ユーザ属性の連携

Firew

all

アカウントの事前プロビ不要アカウントのデプロビ

Webアプリ(OIDC-RP)(SCIM-Svr)

エンタープライズIT クラウドサービス


まずは作ってみた

OpenAM で OpenID Connect OP を構成する

Ruby OpenID Connect + Rails で OP/RP を作る

Java で SCIM Server を作る


サービス「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

実装例: OpenAMを使ったOPの構成

Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.

実装例: 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 :newreturn

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])elserender json: @req.error.response

endend

# 同意画面からPOSTされる先def create

res = OIDC::Response.new(params)res.owner = current_user

redirect_to res.build_responseend

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└ ...

認証状態のチェック

リクエストパラメータの検証

同意画面の表示

パラメータエラーの画面表示

ID Token, UserInfoなどのレスポンスを生成

ID Tokenなどをフラグメントにつけて、redirect_uriへリダイレクト

スクラッチで実装

13

次のページで


実装例: Rubyを使ったOPの実装# -*- coding: utf-8 -*-

...

module OIDCclass 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] ハッシュフラグメントで構成されたパラメータを含むURIdef 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 + '.' + payloadsignature = UrlSafeBase64.encode64(pkey.sign('sha256', input))input + '.' + signature

end

def pkeyOpenSSL::PKey::RSA.new(File.read(OIDC::Config.rsa_private_key))

end

# ID Token のクレームを定義def token_data

issue_at = Time.now.to_iexp = issue_at + id_token_expirereturn {

: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 scopesend

endend

JWTヘッダー

ID Tokenに含めるクレームセットを生成

JWSで署名をつける

スクラッチで実装


実装例: Rubyを使ったRPの実装# -*- coding: utf-8 -*-class AuthorizationController < ApplicationController

def authorizeredirect_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 => 400return

end

unless authz.validate(params, stored_state, stored_nonce) == truerender :nothing => true, :status => 400return

end

session[:id_token] = (authz.oidc.id_token).as_jsonsession[: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 OpenID Connect を使って

アプリケーションのセッションを生成する

次のページで

https://github.com/nov/openid_connect


実装例: Rubyを使ったRPの実装# -*- coding: utf-8 -*-require 'base64'

class Authorization < ActiveModelBase

...

def authorization_uri(state, nonce)client.redirect_uri ||= redirect_uriclient.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 thenRails.logger.error 'invalid state parameter.'return false

end

# ID Tokenの検証beginid_token = decode_id_token fragment['id_token']id_token.verify!(

issuer: issuer,client_id: identifier,nonce: nonce

)oidc.id_token = id_tokenoidc.user_info = id_token.raw_attributes['userinfo']

rescue => eRails.logger.error "#{e.message}"return false

end

return trueend

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))

endend

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_accessJSON::JWK::Set.new @jwks

end

#OpenIDConnect::Discovery::Provider::Config::Responsedef public_keys@public_keys ||= jwks.collect do |jwk|JSON::JWK.decode jwk

endend

end

state値の検証も忘れずに

ID Tokenの検証

Ruby OpenID Connectを使ってID Tokenのデコードと検証

Ruby OpenID Connect を使って

署名の検証に必要な鍵はOPのjwks_uriから入手する

Ruby OpenID Connectを使ってOPの認証エンドポイントへのURLを生成

https://github.com/nov/openid_connect


SCIMのスキーマ毎と

Bulk操作に対して、エ

ンドポイントを定義

実装例: Javaを使ったSCIMサーバの実装


実装例: 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へ強度の強い認証を要求する方法の取り決めが必要。


エンプラ側の視点で

言えば、多くのこと

がRPの実装に依存

した状態。

信頼できるRP

(正しく実装された

クラウドサービス)

をエンプラITは求

めるようになる。

信頼できるクラウドサービスがエンプラITとつながる

検討事項


ID/コード系

表示情報系













考慮点についての

技術TFでの検討内容


技術TFでの検討状況検討事項


ID/コード系

表示情報系













利用する属性の共通化を検討中

セッション管理方式の共通化を検討中

今後検討予定


利用属性の共通化の検討検討事項


ID/コード系

表示情報系













利用する属性の共通化を検討中


利用属性の共通化の方針

OIDC/SCIMの両方で同じ属性を扱う

対応すべき属性を3つのレベルに分類

RP（クラウドサービス）を動かすための最小限の属性

エンタープライズITで通常扱う属性

エンタープライズITで必要となりうる属性

利用する属性の共通化


利用する属性を3つのレベルに整理

属性 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 –

パスワード使用しない –

レベル1属性（RPを動かすための最小限の属性）


従業員番号 employeeNumber Claimの拡張が必要

組織コード orgUnitCode(*2) Claimの拡張が必要

組織名 orgUnitLocalNameValue(*2)

Claimの拡張が必要

役職コード titleCode(*2) Claimの拡張が必要

役職名 titleLocalNameValue(*2) Claimの拡張が必要

電話番号 phoneNumbers phone_number

…

レベル2属性（エンタープライズITで通常扱う属性）


言語 locale locale

表示順 displayOrder Claimの拡張が必要

…

レベル3属性（エンタープライズITで必要となりうる属性）

*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": "[email protected]","orgUnitCode": ["0111", "0211"],"orgUnitLocalNameValue": ["営業部", "企画部"],"titleCode": "002","titleLocalNameValue": "部長","locale": "ja_JP"

}}


OIDCで使う時に連携か？SCIMで事前プロビか？

アプリケーションの特性で使い分ける

属性の特性で使い分ける

サービス側の使い方で決まることではあるが、クラ

ウドサービス横断で利用することを前提に共通化を

検討



セッション管理方式の共通化の検討検討事項


ID/コード系

表示情報系













セッション管理方式の共通化を検討中


ゲートウェイのように構成され

た従来のSSO

統制（アプリへのアクセス制

御）観点のセッション管理は

SSOだけで実装

フェデレーション型では、セッ

ション管理はRPの実装に依存

統制観点のセッション管理のた

めに、OP-RP間の方式の取り決

めが必要

セッション管理方式の検討の必要性セッション管理方式の共通化

ユーザー SSO アプリユーザー

OP(SSO)

RP(アプリ)

従来型のSSO フェデレーション型SSO


セッション管理方式の検討ポイント

RPがOPにセッションの状態を確認する方法

タイムアウト後はアプリ (RP) が利用できないよう

にするためのOPの振る舞い

無効化されたアカウントのセッション停止

ユーザーの利用への影響、開発者の対応のしやすさ

セッション管理方式の共通化


セッション管理方式の選択肢

OpenID Connect Session Management

IDトークンの有効期限毎にセッションを更新

プロンプト無しで認証フローの再実行

リフレッシュトークンを使った認証情報の更新

デプロビジョニングによるコントロール

34



OpenID Connect Session

Management 1.0 - draft 21

http://openid.net/specs/openid-

connect-session-1_0.html

セッション確認のリアルタイム性は高い

OPへの負荷との調整しだいだが、分単位

で状態の反映が可能

対応のためには全アプリ画面へのiframe

埋め込みが必要。改修コストは高め。

OpenID Connect Session Managementセッション管理方式の共通化

OP iframe

RP iframe

OP

ブラウザ

client_id +session_state

changed /unchanged

セッション状態の問合せ（非同期）

http://openid.net/specs/openid-connect-session-1_0.html


ブラウザ

36

IDトークンの有効期限毎にIDトークンを

取り直すことでセッションを更新する

セッション確認の精度は数時間オーダー IDトークンの有効期限が1時間なら、確認精度は1時間

対応のためにはアプリのセッション管理

部分の改修が必要。コールバックを扱う

処理が必要。対応コストは中くらい。

IDトークン再取得をするときにPOST

データが失われる制限あり。

プロンプト無しで認証フローの再実行セッション管理方式の共通化

OP

SessionManager

アプリ

IDトークンの有効期限をチェック

prompt=noneで認証フローを再実行

新しいIDトークンとともに元のURLへ復帰


ブラウザ

37

IDトークンの有効期限毎にIDトークンを

取り直すことでセッションを更新する

セッション確認の精度は数時間オーダー IDトークンの有効期限が1時間なら、確認精度は1時間

対応のためにはアプリのセッション管理

部分の改修が必要。対応コストは低め。

OPがAuthorization Code Flowに対応す

る必要あり。DMZへの配置が必須。

POSTデータが失われることはない。

Offline Clientを使う場合の Refresh

Token の用法との整合について要検証。

リフレッシュトークンを使った認証情報の更新セッション管理方式の共通化

OP

SessionManager

アプリ

IDトークンの有効期限をチェック

リフレッシュトークンを使って新しいIDトークンを取得


セッションタイムアウトには対応できな

いが、無効化されたアカウントの利用は

確実に停止する。

ID管理によるデプロビジョニングを実行

することで実現。ID管理が実現されてい

れば対応コストは不要。

デプロビジョニングによるコントロールセッション管理方式の共通化

ユーザーテーブル

アプリ

OPIDM

ブラウザ

無効化されたユーザーのデプロビジョニング処理

無効化されたユーザーの継続利用はできなくなる


セッション管理方式の共通化の方向性

方式確認の精度アプリ開発者視点アプリ利用者視点

OpenID ConnectSession Management

○分オーダーでの精度で確認可能

×全画面へiframe埋め込みが必要

△UXは現状のアプリのまま維持できる。ブラウザの対応については検証が必要

プロンプト無しで認証フローの再実行

△時間オーダーの精度で確認可能

△セッション管理部の改修。コールバックを扱う処理が必要

×セッション更新時にPOSTデータが失われる可能性がある

リフレッシュトークンを使った認証情報の更新(OPがCodeフローに対応し、DMZに配置される必要あり)

△時間オーダーの精度で確認可能

○セッション管理部の改修。

○UXは現状のアプリのまま維持できる

デプロビジョニングによるコントロール

×無効化されたアカウントの停止にとどまる

―（改修なし）

○UXは現状のアプリのまま維持できる

目指すところはOIDC Session Management。アプリ対応コストが高いため、過渡的な選択肢は必要。いずれの方式も課題はあり、技術TF内で継続検討する。


今後の活動


今後の活動

サンプル実装の継続

コードサンプル、製品設定サンプル

考慮点の検証、相互接続性の検証

エンタープライズ向け OpenID Connect / SCIM

実装ガイドラインとして文書化

年内の公開を目指して活動中41

エンタープライズit環境での openid connect / scim の具体的実装方法 idit2014

Technology