Provisioning API を考えるSCIM and/or Graph API

2012/2/27 #idcon mini

@phr_eidentity

Microsoft MVP for Forefront Identity Manager

はじめに…

• プロビジョニングは楽しい

はじめに…

• 答えはありません…

• 一緒に特性を考えて向き、不向きなどを考えられればと

まずはそれぞれ

• SCIM

• Graph API

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.

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

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.

Graph API

• ソーシャル Graph を管理するための API

• オブジェクトの表現方法• JSON• Schema や Object / Connection の種類はサービス毎に定義

• オブジェクトの管理方法• RESTful• サービス毎に定義

• 採用製品/サービス• Facebook / Graph API• Microsoft / Windows Azure Active Directory Graph API

まとめてみる

SCIM Graph API

目的 標準化されたスキーマとプロトコルを提供することでユーザ管理のコストと複雑性を低減する

コンテンツとのつながりを簡単に持てることによりパーソナライズされた適切なエクスペリエンスを提供する

管理対象 オブジェクト・ユーザ・グループ

オブジェクト・いろいろコネクション

管理対象の表現方法 JSON標準化対象（Schema）

JSON各サービスで自由に定義

管理方法（プロトコル）

RESTful操作毎に標準化（Protocol）

RESTful各サービスで自由に定義※例：Windows Azure AD は OData v3

採用製品/サービス IdM製品/IdP中心 サービスプロバイダ中心

参考）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.

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

検討軸？

• オブジェクト表現の標準化• サービス毎にアダプタ/コネクタを作り続けるのか？• 今後クラウド上の管理対象オブジェクトはどうなっていくのか？

• スケーラビリティ• オブジェクト間の紐付き/関係性の表現

• 用途• オブジェクト/Connection の管理

• 作成（Create）• 検索（Read）• 更新（Update）• 削除（Delete）

結局どうなのか？

• ID 管理を行う上でオブジェクト表現（スキーマ）が標準化されていないのは確かに結構面倒くさい

• コネクタが高い（某社は\5M/コネクタw）• プロプラエタリだとサービス側の仕様変更についていくのが大変• LDAP や SPML が目指したもの• Graph API も標準化を目指せばよい？

• 今後は？• オブジェクトの種類はユーザとグループだけで良いのか？

• そもそも標準化したスキーマは使えるのか？• 種類が増えたら都度標準として定義？

• オブジェクト間のつながりも管理したい？• レポジトリ内のオブジェクト間のつながりはこれまでも表現してきた• レポジトリ外のオブジェクトとのつながり？Federation との親和性？

• 現にSCIM MLでは他のオブジェクトへの参照が議論に

• つながりの表現方法（方向性、つながりの種類）にバラエティは不要か？

参考）オブジェクト間のつながりの表現

• LDAP• 他のディレクトリへのオブジェクト参照（オブジェクト単位） :

referral• 属性タイプ（他のオブジェクトへの参照属性） : Reference

• ベンダ拡張

• Relational Database• Foreign Key

• SCIM• 他のオブジェクトの id• 循環参照などは SP 側で解決（return code : 409）

• Graph API / facebook• Connection として定義

参考）オブジェクト間のつながりの表現

• LDAP / dn ベースの参照

DC=com

DC=example

OU=org1

CN=user1

CN=group1

lastname : hoge

member : DN: CN=user1,OU=org1,DC=example,DC=com

memberOf : DN: CN=group1,OU=org1,DC=example,DC=com

参考）オブジェクト間のつながりの表現

• SCIM / object id ベースの参照“schemas” : [“urn:scim:schemas:core:1.0”],“id” : “xxxxx”,“displayName” : “hoge group”,“members” : [

{“value”: “yyyyy（ユーザの id）”,“displayName”: “foo bar”,“type”: “User”

}]

参考）オブジェクト間のつながりの表現

• Graph• Graph theory

• Node

• Edge• Bi-directional

• Uni-directional

user1Company1

website1

user2

likeFriend edge

Employee

Employer

manage

参考）オブジェクト間のつながりの表現

• Graph の目指すもの・利点• Multi dimensional protocol の必要性

• クラウドでは人、アプリケーションなどのオブジェクトが中央のディレクトリを通じて連携しない

• 関係性を柔軟に表現できる必要がある

• 方向付けの表現（雇用と所属など）

person

organization

directory

Apps

Servicesbelonguse

Appsperson

organization

Services

work

use

contract

結局どうなのか？

• SCIM and/or Graph• 比較するものではないが

• SCIM は node （object）の管理・表現方法の標準化にフォーカス• Graph API はオブジェクト間の関係性の表現にもフォーカス

• ユーザ・グループのプロビジョニング用途に特化すれば SCIM で十分？• 足りないスキーマの拡張は必要• 今後コネクションも管理したくなったら SCIM では足りない

• サービスプロバイダはどうするべきか• SP

• User/Group だけではサービスがなりたたない可能性大。Graph の方が良い？• オブジェクトの種類、つながりの種類・方向性など

• IdP/IdMaas• しばらくは User/Group だけ考えれば良さそう？SCIM で OK かも？• 他の IdP との Federation などを考えると Graph の方が良いか？