provisioning api としての SCIM と Graph API

1. Provisioning API を考える
SCIM and/or Graph API
2012/2/27 #idcon mini
@phr_eidentity
Microsoft MVP for Forefront Identity Manager

2. はじめに…
• プロビジョニングは楽しい

3. はじめに…
• 答えはありません…
• 一緒に特性を考えて向き、不向きなどを考えられればと

4. まずはそれぞれ
• SCIM
• Graph API

5. SCIM（System for Cross-domain Identity
Management）
• 目的（http://tools.ietf.org/html/draft-ietf-scim-core-schema-00より）
• The System for Cross-Domain Identity Management (SCIM) specification is designed
to make managing user identity in cloud based applications and services easier. The
specification suite builds upon experience with existing schemas and deployments,
placing specific emphasis on simplicity of development and integration, while
applying existing authentication, authorization, and privacy models. Its intent is to
reduce the cost and complexity of user management operations by providing a
common user schema and extension model, as well as binding documents to
provide patterns for exchanging this schema using standard protocols. In essence,
make it fast, cheap, and easy to move identity in to, out of, and around the cloud.
This document provides a platform neutral schema and extension model for
representing users and groups in JSON and XML formats. This schema is intended for
exchange and use with cloud service providers. Additional binding documents
provide a standard REST API, SAML binding, and use cases.

6. SCIM（System for Cross-domain Identity
Management）
• Identity Management のための標準 Schema と Protocol を定義したもの
• オブジェクトの表現方法 : Schema
• JSON
• Schema の標準化（拡張可能）
• オブジェクトの管理方法 : Protocol
• RESTful
• 操作（CRUD）毎に標準化
• 採用製品/サービスの例
• PingIdentity / PingFederate
• UnboundID / Identity Data Sync
• WSO2 / WSO2 Identity Server
• DirectoryServices / GreyTower Identity

7. Graph API
• 目的（https://developers.facebook.com/blog/post/377/より）
• Any webpage can now easily become part of the social graph
• On Facebook, users build their profiles through connections to what they care about
— be it their friends or their favorite sports teams, bottles of wine, or celebrities.
The Open Graph protocol opens up the social graph and lets your pages become
objects that users can add to their profiles. When a user establishes this connection
by clicking Like on one of your Open Graph-enabled pages, you gain the lasting
capabilities of Facebook Pages: a link from the user's profile, ability to publish to the
user's News Feed, inclusion in search on Facebook, and analytics through our
revamped Insights product.
• In summary, by giving your users better, simpler ways to connect with the content
on your site, you can then use those connections to provide more personalized,
relevant experiences. And the product only gets better over time. The more people
that come back to your site, the more connections that are made, the better your
service becomes.

8. Graph API
• ソーシャル Graph を管理するための API
• オブジェクトの表現方法
• JSON
• Schema や Object / Connection の種類はサービス毎に定義
• オブジェクトの管理方法
• RESTful
• サービス毎に定義
• 採用製品/サービス
• Facebook / Graph API
• Microsoft / Windows Azure Active Directory Graph API

9. まとめてみる
SCIM Graph API
目的 標準化されたスキーマとプロトコル コンテンツとのつながりを簡単に持
を提供することでユーザ管理のコス てることによりパーソナライズされ
トと複雑性を低減する た適切なエクスペリエンスを提供す
る
管理対象 オブジェクト オブジェクト
・ユーザ ・いろいろ
・グループ コネクション
管理対象の表現方法 JSON JSON
標準化対象（Schema） 各サービスで自由に定義
管理方法（プロトコ RESTful RESTful
ル） 操作毎に標準化（Protocol） 各サービスで自由に定義
※例：Windows Azure AD は OData v3
採用製品/サービス IdM製品/IdP中心 サービスプロバイダ中心

10. 参考）WAAD が Graph API を採用した理
由
• Kim Cameron の blog（http://www.identityblog.com/?p=1222）
• It is because of the central importance of graph technology in being able to manage
connectedness - something that is at the core of the digital universe. Treating the
world as a graph allows us to have a unified approach to querying and
manipulating interconnected objects of many different kinds that exist in many
different relationships to each other.
• A directory has emerged that by August is projected to contain one billion users.
True, it's only one directory in a world with many directories (most agree too many).
But beyond the importance it achieves through its scale, it fundamentally changes
what it means to be a directory: it is a directory that surfaces a multi-dimensional
network.
• This network isn't simply a network of devices or people. It's a network of people
and the actions they perform, the things they use and create, the things that are
important to them and the places they go. It's a network of relationships between
many meaningful things. And the challenge is now for all directories, in all
domains, to meet a new bar it has set.

11. 参考）WAAD が Graph API を採用した理
由

12. 検討軸？
• オブジェクト表現の標準化
• サービス毎にアダプタ/コネクタを作り続けるのか？
• 今後クラウド上の管理対象オブジェクトはどうなっていくのか？
• スケーラビリティ
• オブジェクト間の紐付き/関係性の表現
• 用途
• オブジェクト/Connection の管理
• 作成（Create）
• 検索（Read）
• 更新（Update）
• 削除（Delete）

13. 結局どうなのか？
• ID 管理を行う上でオブジェクト表現（スキーマ）が標準化されていないの
は確かに結構面倒くさい
• コネクタが高い（某社は5M/コネクタw）
• プロプラエタリだとサービス側の仕様変更についていくのが大変
• LDAP や SPML が目指したもの
• Graph API も標準化を目指せばよい？
• 今後は？
• オブジェクトの種類はユーザとグループだけで良いのか？
• そもそも標準化したスキーマは使えるのか？
• 種類が増えたら都度標準として定義？
• オブジェクト間のつながりも管理したい？
• レポジトリ内のオブジェクト間のつながりはこれまでも表現してきた
• レポジトリ外のオブジェクトとのつながり？Federation との親和性？
• 現にSCIM MLでは他のオブジェクトへの参照が議論に
• つながりの表現方法（方向性、つながりの種類）にバラエティは不要か？

14. 参考）オブジェクト間のつながりの表現
• LDAP
• 他のディレクトリへのオブジェクト参照（オブジェクト単位） :
referral
• 属性タイプ（他のオブジェクトへの参照属性） : Reference
• ベンダ拡張
• Relational Database
• Foreign Key
• SCIM
• 他のオブジェクトの id
• 循環参照などは SP 側で解決（return code : 409）
• Graph API / facebook
• Connection として定義

15. 参考）オブジェクト間のつながりの表現
• LDAP / dn ベースの参照
DC=com
DC=example
OU=org1
CN=user1
lastname : hoge
memberOf : DN: CN=group1,OU=org1,DC=example,DC=com
CN=group1
member : DN: CN=user1,OU=org1,DC=example,DC=com

16. 参考）オブジェクト間のつながりの表現
• SCIM / object id ベースの参照
“schemas” : [“urn:scim:schemas:core:1.0”],
“id” : “xxxxx”,
“displayName” : “hoge group”,
“members” : [
{
“value”: “yyyyy（ユーザの id）”,
“displayName”: “foo bar”,
“type”: “User”
}
]

17. 参考）オブジェクト間のつながりの表現
• Graph
• Graph theory
• Node
Employer
• Edge user1
Company1
• Bi-directional Employee
• Uni-directional
Friend edge
like
website1
user2 manage

18. 参考）オブジェクト間のつながりの表現
• Graph の目指すもの・利点
• Multi dimensional protocol の必要性
• クラウドでは人、アプリケーションなどのオブジェクトが中央のディ
レクトリを通じて連携しない
• 関係性を柔軟に表現できる必要がある
• 方向付けの表現（雇用と所属など）
Apps person
person use Apps
use work
belong directory Services
organizat
organizat ion contract
ion Services

19. 結局どうなのか？
• SCIM and/or Graph
• 比較するものではないが
• SCIM は node （object）の管理・表現方法の標準化にフォーカス
• Graph API はオブジェクト間の関係性の表現にもフォーカス
• ユーザ・グループのプロビジョニング用途に特化すれば SCIM で十分？
• 足りないスキーマの拡張は必要
• 今後コネクションも管理したくなったら SCIM では足りない
• サービスプロバイダはどうするべきか
• SP
• User/Group だけではサービスがなりたたない可能性大。Graph の方が良い？
• オブジェクトの種類、つながりの種類・方向性など
• IdP/IdMaas
• しばらくは User/Group だけ考えれば良さそう？SCIM で OK かも？
• 他の IdP との Federation などを考えると Graph の方が良いか？