営業マンにもわかる?
GRAPH API 概要
TWITTER / @PHR_EIDENTITY
FACEBOOK / NAOHIRO.FUJIE
HTTP://IDMLAB.EIDENTITY.JP
CONTENTS
• CHALLENGE
• PROVISIONING PROTOCOLS
• IDENTITY CONTEXTS
• SOLUTION?
• GRAPH
• GRAPHとは
• GRAPH APIとは
• CONCLUSION
CHALLENGE : 1
PROVISIONING PROTOCOLS
プロトコルの氾濫、かさむ出費
Corporate
IdM System
Cloud
Services
Groupware
Active
Directory
LDAP / ADSI
REST
New
Application
JDBC
New
Protocol
IT管理者
SI/ベンダ
CSVによる標準化?
Corporate
IdM System
Cloud
Services
Groupware
Active
Directory
New
Application
Import
PGM
Import
PGM
Import
PGM
Import
PGM
Common
CSV
IT管理者
SI/ベンダ
CHALLENGE : 2
IDENTITY CONTEXTS
企業アイデンティティを取り巻く環境
• 企業や従業員を取り巻く環境は...
• グローバル化、M&A
• ITリテラシーが高いデジタル・ネイティブ
• コンシューマ・サービスのエンタープライズ進出
多層のIDENTITY – BRING YOUR OWN IDENTITIES
Private
Business
Company
Social
APL
Customer’s
Systems
Corporate
Systems
みなさん色んな所に
Identityを持ってます
複数のコンテキストと関係性
Corporate
Systems
Customer’s
Systems
Social
APL User
BOSS
Share
Customer
Friend
Fun
Private
Business
Company
それぞれで色んな
関係性を持ってます
=Identity
フェデレーションによる紐付と相互利用
Private
Business
Company
Social
APL
Customer’s
Systems
Corporate
Systems
紐づけたり
どうやってIDENTITYを管理するのか?
Private
Business
Company
Social
APL
Customer’s
Systems
Corporate
Systems
中央レポジトリを
作ってまとめて保管?
まとめたり
どうやってIDENTITYを管理するのか?
Private
Business
Company
Social
APL
Customer’s
Systems
Corporate
Systems
他のレポジトリと
の関係性は?
でもIdentityを
うまく表せない?
SOLUTION?
結局のところ…
• ソーシャル(コンシューマ)や取引先のシステムを使うのは仕
方ない
• ソーシャルアプリを超える利便性やスケールを自社で提供できる
わけでもないし
• 統合レポジトリを作ってそこから全部プロビジョニングする?
• アプリが増えるとプロビジョニング先が増えてお金が。。。
• BYOIとかどうする?
分散レポジトリの間の関係性を管理して
「ゆるく」システム間連携をするしかない?
どうやって効率よくIDENTITYを管理するのか?
• プロトコルの標準化
• クラウドとの親和性 : RESTベース
• SCIM(SYSTEM FOR CROSS-DOMAIN IDENTITY MANAGEMENT)
• GRAPH API
• 表現と保持方法
• 他のレポジトリとの関係を含めて保持
• GRAPH
GRAPH
とりあえず SCIM は置いておいて今回は GRAPH
GRAPH とは?
• ソーシャルグラフ
• THOUGHTS ON THE SOCIAL GRAPH / BRAD FITZPATRICK(EX-SIX-APART /
2007)
• HTTP://BRADFITZ.COM/SOCIAL-GRAPH-PROBLEM/
• 人間関係図みたいなもの
• ノード:人間やアプリケーション、WEBサイトなど
• エッジ:つながり(意味と方向性を持つ)
GRAPH
Tony Company1
website1Zakk
likeFriend
Employee
Employer
manage
ノード
エッジ
GRAPH API とは?
• GRAPH を操作するための API
• FACEBOOK や WINDOWS AZURE ACTIVE DIRECTORY がサポート
• RESTベース
• ノードの作成・検索やエッジの作成・検索などが可能
• 例)TONYさんの友達は? ⇒ ZAKKさん
• 例)TONYさんとZAKKさんの関係は? ⇒ 友達
何が良いのか?
• RESTベースなので簡単に実装できる⇒開発コストが安い
• SCIM はもっと標準化が進んでいるが。。(プロトコルとスキーマの標準化)
• WINDOWS AZURE ACTIVE DIRECTORY の GRAPH API は ODATA V3 準拠
• 他のレポジトリに入っているユーザとの関係性を表現できる
• 今のところ SCIM や LDAP は
• 自身のレポジトリ内のオブジェクトとの関係しか表現できない
• 関係性自体に意味を持たせられない
• クラウドとの親和性が高い ⇒ IDMAASへの移行によるコスト低減の可能性
• プロトコル的にも、BYOI などの自由度的にも
ゆるく分散管理されたアイデンティティ
Private
Business
Company
Social
APL
Customer’s
Systems
Corporate
Systems
BYOIの許容
会社間での
協業
■自レポジトリ上の属性
- 氏名:Tony McAlpine
- 部署:Shrapnel 部
- 上司:Mike Varney
■取引先との関係
- Customerシステムを利用
■ソーシャルとの関係
- Facebook上のxxページの管理者
最低限の情報
管理
REST API
動的に関係性
を構築
今後の課題
• ガバナンスと個人の同意
• どこまで許すか?
• プライバシーとの境目はどこか?
• 外資系の BYOD のポリシーが参考になるかも
• 使っても良いけどポリシーが適用されていることが前提
• システム化が進む領域かも
CONCLUSION
まとめ
• 接続する対象のアプリケーションの種類や数の増加に対応で
きる標準化された仕様に準拠したID管理システムが必要
• 多様化するワークスタイルへ対応するためには多層に分散し
たIDを効率よくつなげて管理して行くことが必要になる
• プロトコルの標準化、柔軟なアイデンティティの表現の可能
性の両面から GRAPH / GRAPH API は一つの解となる可能性が
ある

Graph api introduction_20130425