Downloaded 12 times
![参考）オブジェクト間のつながりの表現
• SCIM / object id ベースの参照
“schemas” : [“urn:scim:schemas:core:1.0”],
“id” : “xxxxx”,
“displayName” : “hoge group”,
“members” : [
{
“value”: “yyyyy（ユーザの id）”,
“displayName”: “foo bar”,
“type”: “User”
}
]](https://image.slidesharecdn.com/scimandorgraph-130227103305-phpapp01/75/Scim-and-or-graph-16-2048.jpg)
More Related Content
![[Japan Tech summit 2017] SEC 007](https://cdn.slidesharecdn.com/ss_thumbnails/techsummit2017pdfsec007-171116035457-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Whitepaper] an overview of ibm mobile first platform](https://cdn.slidesharecdn.com/ss_thumbnails/whitepaperanoverviewofibmmobilefirstplatform-151120010232-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
![Day 2 sustainability is a_journey_not_a_destination[1]](https://cdn.slidesharecdn.com/ss_thumbnails/day2sustainabilityisajourneynotadestination1-110415040222-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Scim and or graph
- 1. Provisioning API を考える SCIM and/or Graph API 2012/2/27 #idcon mini @phr_eidentity Microsoft MVP for Forefront Identity Manager
- 2.
- 3.
- 4.
- 5. SCIM（System for Cross-domainIdentity 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-domainIdentity 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 が GraphAPI を採用した理 由 • 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 が GraphAPI を採用した理 由
- 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/orGraph • 比較するものではないが • SCIM は node （object）の管理・表現方法の標準化にフォーカス • Graph API はオブジェクト間の関係性の表現にもフォーカス • ユーザ・グループのプロビジョニング用途に特化すれば SCIM で十分？ • 足りないスキーマの拡張は必要 • 今後コネクションも管理したくなったら SCIM では足りない • サービスプロバイダはどうするべきか • SP • User/Group だけではサービスがなりたたない可能性大。Graph の方が良い？ • オブジェクトの種類、つながりの種類・方向性など • IdP/IdMaas • しばらくは User/Group だけ考えれば良さそう？SCIM で OK かも？ • 他の IdP との Federation などを考えると Graph の方が良いか？