自己紹介 氏縄武尊 (Ujinawa Takeru) ThemiStruct 認証技術グループ技術開発 (Inventory 認証等 ) OpenID Connect OpenID Foundation Japan Enterprise Identity WG 2

Transcription

1 OpenID Connect & SCIM 最新プロトコル動向 株式会社オージス総研テミストラクトソリューション部氏縄武尊 2015/08/24

2 自己紹介 氏縄武尊 (Ujinawa Takeru) ThemiStruct 認証技術グループ技術開発 (Inventory 認証等 ) OpenID Connect OpenID Foundation Japan Enterprise Identity WG 2

3 会社概要 株式会社オージス総研 代表者 : 設立 : 代表取締役社長西岡信也 1983 年 6 月 29 日 資本金 : 4.4 億円 ( 大阪ガス株式会社 100% 出資 ) 事業内容 : 主な事業所 本社 : 東京本社 : 千里オフィス : 名古屋オフィス : システム開発 プラットフォームサービス コンピュータ機器 ソフトウェアの販売 コンサルティング 研修 トレーニング 大阪府大阪市西区千代崎 3- 南 2-37 ICCビル東京都港区港南 品川インターシティA 棟大阪府豊中市新千里西町 愛知県名古屋市中区錦 名興ビル 売上実績 : 582 億円 ( 連結 ) 308 億円 ( 単体 ) (2014 年度 ) 従業員数 : 3,126 名 ( 連結 ) 1,279 名 ( 単体 ) 関連会社 : さくら情報システム ( 株 ) ( 株 ) 宇部情報システム ( 株 ) システムアンサー OGIS International, Inc. 上海欧計斯軟件有限公司 ( 中国 ) オージス総研グループ売上構成比 ( 連結 ) 取得許可認定 3

4 第 章 認証を取り巻く時代の変遷 4

5 従来の認証 それぞれの Web ページでの認証 - 各ページでログインを行う - 各ページの開発を行う 1 アクセス 2 認証要求 3 認証応答 4 情報照会 クライアント端末 6 識別情報返却 7 識別情報と一緒にアクセス アプリケーション 5 認証結果 ユーザーストア 8 ユーザ向けページ 5

6 従来の認証 (SSO) OpenAM 等 2 認証 5 識別情報提供 認証基盤アプリケーション 3 情報照会 4 認証結果 認証基盤 ユーザーストア クライアント端末 7 識別情報確認 6 識別情報と一緒にアクセス 8 ユーザ情報連携 9 ユーザ情報連携 ウェブアプリケーション 1 アクセス 10 ユーザ向けページ エージェント or リバースプロキシ アプリケーション 6

7 SAML 1 アクセス 5 検証 クライアント端末 6 ユーザ向けページ 4SAML アサーション ( 認証情報 属性 権限 ) SP (Service Provider) 2SAML リクエスト IdP (Identiry Provider) 7

8 SAML の問題点 導入が困難なケースが多い - 用語の多い - メリット デメリットの理解が追いつかない - 検証 デバッグが容易でない SAML + 独自プロトコル等の実装 変化が多く対応し辛い状況が続いている 8

9 第 章 OpenID Connect とは 9

10 OAuth2.0 HTTP 上で認可 - 自分の代わりに何かしてもらう クライアント端末 4 認可コード 2 認可 OAuth クライアントリクエスト 5 認可コード 6 トークン応答 認可サーバ 10

11 OpenID Connect 3ID Token RP (Relying Party) クライアント端末 OP (OpenID Provider) 11

12 OpenID Connect (OP で ) 認証後に (RP の ) サービスを利用 - 認証結果と属性情報を受け渡せる - OAuth2.0 プロトコルがベース 重要なワード - OP (OpenID Provider) 認証を行い ID 情報を連携する - RP (RelyingParty) OP で認証後にアプリケーションを提供する - ID Token 認証したエンドユーザの情報 認証に関する情報を持つトークン - User Info 認証したエンドユーザの情報 - Access Token Userinfo の情報を取得するためのトークン 12

13 Code Flow クライアント端末 4 認可コード連携 2 認証要求 RP (Relying Party) 5 認可コード 6ID Token OP (OpenID Provider) 13

14 認可 Code Flow クライアント端末 RP(Relying Part) OP(OpenID Provider) アクセス OP へリダイレクト response_type=code client_id= クライアント ID redirect_uri= 認証後に戻る場所 scope= 取得したい情報 nonce=replay atack 対策 state= コールバック主の特定 etc 14

15 認可 Code Flow クライアント端末 Relying Party OpenID Provider 上の値を持って OP へリダイレクト 認証画面返却 認証情報送信 redirect_uri にリダイレクト code= 認可コード state= 渡された state 値 15

16 認可 Code Flow クライアント端末 Relying Party OpenID Provider 渡された情報を持ってリダイレクト 取得したコードを用いて ID Token, Access Token を要求 ID Token と Access Token を返却 Access Token を用いて User Info の情報を要求 ユーザ向けのサービスを提供 User Info の情報を返却 16

17 Implicit Flow クライアント端末 4ID Token 連携 2 認証要求 RP (Relying Party) OP (OpenID Provider) 17

18 Implicit Flow クライアント端末 Relying Party OpenID Provider アクセス OP にリダイレクト response_type=id_token token client_id= クライアント ID redirect_uri= 認証後に戻る場所 scope= 取得したい情報 nonce=replay atack 対策 state= コールバック主の特定 etc 18

19 Implicit Flow クライアント端末 Relying Party OpenID Provider 上の値を持って OP へ 認証画面返却 認証情報送信 redirect_uri にリダイレクト id_token=id Token state= 渡された state 値 access_token= アクセストークン token_type=bearer 19

20 Implicit Flow クライアント端末 Relying Party OpenID Provider 渡された情報を持ってリダイレクト Access Token を用いて User Info の情報を要求 User Info の情報を返却 ユーザ向けのサービスを提供 20

21 ID Token の形 ( 例 ) eyj0exaioijkv1qilcjhbgcioijsuzi1nij9.eyjzdwiioij1amk1miisi mf1zci6imnsawvudf9pzcisimlzcyi6imh0dha6ly9vcc5legftcgxl LmNvbSIsImV4cCI6IjE0Mzk5NDYzNjAiLCJub25jZSI6IkFCQ0QxMjM 0IiwiaWF0IjoiMTQzOTk0NjAwMCJ9.S2GTMObgH956hjE6Pf7LEL1 +CyiobH8tVImvxsVqx1fAZkFNZGP4aVv5jjNj2Ldwt/LoGJs8Er0YZSf KPWI1cdmEr+NtYeRyljbQvCRhg3T4aZpBfzBcwABj8DQxbv0uNuV 0s4eHS0OMM7LVJnXk/kzdCeM/cwlzz0Vor0aYdAg= ヘッダ. ペイロード. 署名 JWT(JSON Web Token) 形式 引用 21

22 ID Token の中身 ( 例 ) ヘッダ ( 署名に用いる情報 ) { "typ":"jwt", "alg":"rs256" } ペイロード (ID Token の情報 ) { "sub":"uji52", "aud":"client_id", "iss":" "nonce":"abcd1234", "iat": " " "exp":" " } eyj0exaioijkv1qilcjhbgcioijsuzi1nij9 + eyjzdwiioij1amk1miisimf1zci6imnsawv udf9pzcisimlzcyi6imh0dha6ly9vcc5legf tcgxllmnvbsisimv4cci6ije0mzk5ndyznja ilcjub25jzsi6ikfcq0qxmjm0iiwiawf0ijoi MTQzOTk0NjAwMCJ9 S2GTMObgH956hjE6Pf7LEL1+CyiobH8tVI mvxsvqx1fazkfnzgp4avv5jjnj2ldwt/log Js8Er0YZSfKPWI1cdmEr+NtYeRyljbQvCRhg 3T4aZpBfzBcwABj8DQxbv0uNuV0s4eHS0 OMM7LVJnXk/kzdCeM/cwlzz0Vor0aYdAg= 22

23 SAML に比べての優位点 実装しやすい - 何をやりとりするのかがわかりやすい - 設定に必要な属性を予め特定できる - 開発者の負担軽減 23

24 第 章 OpenID Connect 実装例 24

25 実装例 & デモ OP(OpenID Provider) -OpenAM -op.example.com RP(RelyingParty) -Node.js (passport) -rp.example.com 25

26 第 章 OpenAM 26

27 OpenAM の設定 OpenAM の OP 化 - クレーム - リクエストタイプ - 署名方法 - etc RP の登録 - Client ID - Client Secret - redirect uri - etc 27

28 OpenAM(OAuth2 プロバイダ ) サービス >OAuth2 プロバイダ - OP の設定 サポートするクレーム リクエストタイプ 署名方式 28

29 OpenAM(OAuth2 プロバイダ ) 29

30 OpenAM(OAuth2 プロバイダ ) 30

31 OpenAM(OAuth2.0 クライアント ) エージェント >OAuth2.0 クライアント - Client ID/Secret - リダイレクト URI 等 31

32 OpenAM(OAuth2.0 クライアント ) 32

33 OpenAM(OAuth2.0 クライアント ) 33

34 第 章 Passport 34

35 35

36 Node.js(passport-openidconnect) 初期設定 - Web フレームワーク (Express) # npm install -g express # npm install -g express-generator # express -e passport - 今回は passport-openidconnect というモジュールを使って Node.js のプロジェクトを RP として動作させる 36

37 package.json 利用するライブラリを指定 - passport 認証ストラテジー を使って認証機能を実装 - passport-openidconnect OpenID Connect 用の 認証ストラテジー を提供 snip "passport": "*", "passport-openidconnect": "*", } } 37

38 RP の設定 - app.js に記載した RP として動作させるための設定 passport.use(new OpenidConnectStrategy({ authorizationurl: " tokenurl: " userinfourl: " clientid: "passporttest", clientsecret: "password", callbackurl: " scope: ["openid"] }, function(accesstoken, refreshtoken, profile, done) { return done(null, profile); })); app.get('/auth', passport.authenticate('openidconnect')); app.get('/cb', passport.authenticate('openidconnect',{failureredirect: '/login'}), function(req, res) {res.redirect('/');} ); 38

39 RP で取得できる ID Token の情報 ( デモ内容の概要 ) OP からのリダイレクト /cb?scope=openid&code=a7a96bf2-f3ab-4d10-b1d3-6dbc125e9bc6 ID Token の情報 { tokenname: 'id_token', azp: 'passporttest', sub: 'uji52', at_hash: 'vbghv8i7ainpfa4gz9_hpg', iss: 'themistruct', iat: , auth_time: , aud: [ 'passporttest' ], snip } 39

40 第 章 Identity の管理 40

41 ID 管理製品 これまでの ID 管理 それぞれのプロトコルや独自 API に合わせた ID 配布 受け口がバラバラ プロビ先毎の対応が必要 都度開発必要 職人技 高価格化 41

42 SCIM とは System for Cross-domain Identity Management - ID 管理のためのスキーマとインターフェースを定義 RESTful - リソースの操作を HTTP メソッドに準拠 GET: 取得 POST: 新規 PUT: 更新 DELETE: 削除 PATCH: 部分更新 - ステートレス - ステータスコードで処理結果を通知 GET PUT PATCH POST DELETE 標準化状況 - RFC Editor Queue に入っておりまもなく RFC 化の見込み 42

43 スキーマ 属性を列挙したもの - Singular Attribute id, username, name, etc - Multi-valued Attribute s, addresses, groups, etc urn:ietf:params:scim:schemas:core:2.0:user urn:ietf:params:scim:schemas:core:2.0:group urn:ietf:params:scim:schemas:extension:enterprise:2.0:user { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:user"], "id": "abcd1234 ", "externalid": "uji52", "username": "uji52" "name": { "familyname": "ujinawa", 43

44 リソースの共通属性 ( 一部 ) id - SCIM サーバ側でリソースにユニークな ID externalid - SCIM クライアント側での ID meta - created 作成した時刻 - lastmodified 最終更新時刻 - location リソースにアクセスするための URI - etc 44

45 ユーザリソースの属性 ( 一部 ) username - サービスプロバイダでユニークな ID name - familyname - givenname - middlename - honorificprefix/suffix title - 役職 active s addresses 45

46 POST /Users HTTP/1.1 POST サンプル /Users HTTP/1.1 ( ユーザ作成リクエスト ) Host: scim.example.com Host: scim.example.com Accept: application/scim+json Accept: application/scim+json Content-Type: application/scim+json Content-Type: application/scim+json Authorization:... //APIの認可情報 Authorization:... //APIの認可情報 Content-Length:... Content-Length:... { "schemas": "schemas": "urn:ietf:params:scim:schemas:core:2.0:user"], ["urn:ietf:params:scim:schemas:core:2.0:user"], "username": "uji52", "username": "ujinawa takeru", "externalid": "uji52", "externalid": "uji52", "name": { "name": "familyname": "ujinawa", "familyname": "ujinawa", "givenname": "takeru" "givenname": "takeru" snip snip

47 HTTP/1.1 サンプル 201 ( ユーザ作成レスポンス Created ) Content-Type: application/scim+json Location: /v2/users/< ユーザのリソースID> { "schemas":["urn:ietf:params:scim:schemas:core:2.0:user"], "id": < ユーザのリソースID>, "username": "uji52", "externalid": "uji52", "name": { "familyname": "ujinawa", "givenname": "takeru" snip

48 サンプル ( ユーザ情報取得 ) GET /Users/< 取得したいユーザのリソースID> Host: scim.example.com Accept: application/scim+json Authorization:... //APIの認可情報 48

49 HTTP/1.1 サンプル 200 ( ユーザ情報取得 OK ) Content-Type: application/scim+json Location: /v2/users/< ユーザのリソースID> { "schemas":["urn:ietf:params:scim:schemas:core:2.0:user"], "id": < ユーザのリソースID>, "username": "uji52", "externalid": "uji52", "name": { "familyname": "ujinawa", "givenname": "takeru" snip

50 第 章 まとめ 50

51 まとめ それぞれが独自の方式を取るのは辞めたい - 開発費用がかかる - 運用が大変 標準の仕様なので安心して身を任せる - 周知の技術なら教えてくれる人も多い 力を合わせてセキュリティ向上へ 51

52 ご清聴ありがとうございました お問合せ先 TEL: / info@ogis-ri.co.jp 52