{"id":1222,"date":"2012-07-12T11:57:07","date_gmt":"2012-07-12T19:57:07","guid":{"rendered":"\/?p=1222"},"modified":"2012-11-08T09:34:55","modified_gmt":"2012-11-08T09:34:55","slug":"yes-to-scim-yes-to-graph","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=1222","title":{"rendered":"Yes to SCIM. Yes to Graph."},"content":{"rendered":"

Today Alex Simons<\/a>, Director of Program Management for Active Directory,\u00a0posted the links to\u00a0the Developer Preview of Windows Azure Active Directory<\/a>.\u00a0 Another milestone.<\/p>\n

I'll\u00a0write about\u00a0the release\u00a0in my next post.\u00a0 Today,\u00a0since the Developer Preview focuses a lot of attention on our Graph API, I thought it would be a good idea to respond first to the discussion that has been taking place on Twitter about the relationship between the Graph API and SCIM<\/a>\u00a0(Simple Cloud Identity Management).<\/p>\n

Since the River of Tweets flows without beginning or end, I'll share some of the conversation for those who had other things to do:<\/p>\n

@NishantK:<\/strong> @travisspencer IMO, @johnshew\u2019s posts talk about SaaS connecting to WAAD using Graph API (read, not prov) @IdentityMonk @JohnFontana<\/p>\n

@travisspencer:<\/strong> @NishantK Check out @vibronet\u2019s TechEd Europe talk on @ch9. It really sounded like provisioning \/cc @johnshew @IdentityMonk @JohnFontana<\/p>\n

\"\"@travisspencer:<\/strong> @NishantK But if it\u2019s SaaS reading and\/or writing, then I agree, it\u2019s not provisioning \/cc @johnshew @IdentityMonk @JohnFontana<\/p>\n

@travisspencer:<\/strong> @NishantK But even read\/write access by SaaS *could* be done w\/ SCIM if it did everything MS needs \/cc @johnshew @IdentityMonk @JohnFontana<\/p>\n

@NishantK:<\/strong> @travisspencer That part I agree with. I previously asked about conflict\/overlap of Graph API with SCIM @johnshew @IdentityMonk @JohnFontana<\/p>\n

@IdentityMonk:<\/strong> @travisspencer @NishantK @johnshew @JohnFontana check slide 33 of SIA322 it is really creating new users<\/p>\n

@IdentityMonk:<\/strong> @NishantK @travisspencer @johnshew @JohnFontana it is JSON vs XML over HTTP\u2026 as often, MS is doing the same as standards with its own<\/p>\n

@travisspencer:<\/strong> @IdentityMonk They had to ship, so it\u2019s NP. Now, bring those ideas & reqs to IETF & let\u2019s get 1 std for all @NishantK @johnshew @JohnFontana<\/p>\n

@NishantK:<\/strong> @IdentityMonk But isn\u2019t that slide talking about creating users in WAAD (not prov to SF or Webex)? @travisspencer @johnshew @JohnFontana<\/p>\n

@IdentityMonk:<\/strong> @NishantK @travisspencer @johnshew @JohnFontana indeed. But its like they re one step of 2nd phase. What are your partners position on that?<\/p>\n

@IdentityMonk:<\/strong> @travisspencer @NishantK @johnshew @JohnFontana I hope SCIM will not face a #LetTheWookieWin situation<\/p>\n

@NishantK:<\/strong> @johnshew @IdentityMonk @travisspencer @JohnFontana Not assuming anything about WAAD. Wondering about overlap between SCIM & Open Graph API<\/p><\/blockquote>\n

Given these concerns, let me explain what I see as the relationship between SCIM and\u00a0the Graph API.<\/p>\n

What is\u00a0SCIM?<\/strong><\/p>\n

All the SCIM documents<\/a>\u00a0begin with a commendably\u00a0unambiguous statement of what it is:<\/p>\n

The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build 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 of exchanging this schema using standard protocols. In essence, make it fast, cheap and easy to move users in to, out of and around the cloud. <\/strong>[Kim: emphasis is mine]<\/p><\/blockquote>\n

I support this goal. Further, I like the concept of spec\u00a0writers\u00a0being\u00a0crisp about\u00a0the essence of what they are doing: “Make it fast, cheap and easy to move users in to, out of and around the cloud”.\u00a0 For this type of spec to be useful we need it to be as widely adopted as possible, and that means keeping it constrained, focussed\u00a0and simple enough that everyone chooses to implement it.<\/p>\n

I think the SCIM authors have done important work to date.\u00a0 I have no comments on the specifics of the\u00a0protocol\u00a0or schema\u00a0at this point – I assume those will continue to be worked out in accordance with the spec's “essence statement”\u00a0and be vetted by a broad\u00a0group of players now\u00a0that SCIM is on a track towards standardization.\u00a0 Microsoft will\u00a0try to help\u00a0move this forward:\u00a0 Tony Nadalin will be attending the next SCIM meeting in Vancouver on our behalf.<\/p>\n

Meanwhile, what is\u00a0“the Graph”?<\/strong>\u00a0<\/p>\n

Given that\u00a0SCIM's role is clear, let's turn to\u00a0the question of how it relates to\u00a0a “Graph API”.\u00a0\u00a0<\/p>\n

Why\u00a0does our thinking\u00a0focus on\u00a0a Graph API in addition to a provisioning protocol like\u00a0SCIM?\u00a0 There are two answers.<\/p>\n

Let's start with the theoretical one.\u00a0 It is\u00a0 because of the\u00a0central importance of graph\u00a0technology in\u00a0being able to\u00a0manage\u00a0connectedness<\/strong>\u00a0– something that is at the\u00a0core of the digital universe.\u00a0\u00a0Treating the world as a graph allows us to\u00a0have a unified approach to querying and manipulating interconnected<\/strong> objects of many different kinds that exist in many different relationships to each other.<\/p>\n

But\u00a0theory only appeals to some… So let's\u00a0add a second\u00a0answer that is more… practical.\u00a0\u00a0A directory has emerged that\u00a0by August is projected to contain one billion users<\/a>.\u00a0True, it's only one directory in a world with many directories (most agree too many).\u00a0 But\u00a0beyond the importance it achieves through its scale,\u00a0it fundamentally changes what it means to be a directory:\u00a0 it is a directory that surfaces a\u00a0multi-dimensional network<\/strong>.\u00a0\u00a0<\/p>\n

This network isn't simply a network of devices or people.\u00a0 It's a network of people and the\u00a0actions they perform, the things they\u00a0use and create, the things that are important to them and the places they go.\u00a0 It's a network of relationships between\u00a0many meaningful things.\u00a0 And the challenge is now for all directories, in all domains, to meet\u00a0a new\u00a0bar\u00a0it has set.\u00a0\u00a0\u00a0\u00a0<\/p>\n

Readers who come out of a computer science background\u00a0are no doubt familiar with what a graph<\/a> is.\u00a0 But\u00a0I\u00a0recommend\u00a0taking the time to\u00a0come up to speed on\u00a0the current work on\u00a0connectedness,\u00a0much of which is\u00a0summarized in Networks, Crowds and Markets: Reasoning About a Highly Connected World<\/a>\u00a0(by Easley <\/a>and Kleinberg<\/a>).\u00a0\u00a0The thesis is straightforward:\u00a0 the world of technology is one where everything is connected with everything else\u00a0in a great many dimensions, and by refocusing on the graph in all its diversity we can begin to grasp it.\u00a0<\/p>\n

In early directories we had objects that represented “organizations”, “people”, “groups” and so on.\u00a0\u00a0We saw organizations as “containing” people, and saw groups as “containing” people and other groups in a hierarchical and\u00a0recursive fashion.\u00a0 The hierarchy was a particularly rigid\u00a0kind of network or graph that\u00a0modeled the\u00a0rigid social structures (governments, companies) being described by technology at the time.<\/p>\n

But in today's flatter, more interconnected world, the things we called “objects” in the\u00a0days of X.500 and LDAP are better expressed as “nodes” with different kinds of “edges” leading to many possible kinds of other “nodes”.\u00a0\u00a0Those who know my work from around\u00a02000 may remember I used to call this polyarchy<\/a>\u00a0and contrast it with the hierarchical limitations of LDAP directory technology.<\/p>\n

From a graph\u00a0perspective\u00a0we can see\u00a0“person nodes”\u00a0having “membership edges” to “group nodes”.\u00a0 Or “person nodes” having “friend edges” to other “person nodes”.\u00a0\u00a0Or “person nodes” having “service edges” to a “mail service node”.\u00a0\u00a0In other words the edges are typed relationships between nodes that may possibly contain other properties.\u00a0 Starting from a given node we can “navigate the graph”\u00a0across\u00a0different relationships (I think of them as dimensions), and reason in\u00a0many new\u00a0ways.\u00a0<\/p>\n

For example, we can reason about the strength of the relationships between nodes, and perform analysis, understand why things cluster together in different dimensions, and so on.<\/p>\n

From this vantage point,\u00a0directory is a repository of nodes that serve as points of\u00a0entry into\u00a0a vast graph, some of which are present in the same repository, and others of which can only be reached by following edges that point to resources in different repositories.\u00a0 We already\u00a0have\u00a0forerunners of this in today's directories – for example, if the URL\u00a0of my blog is contained in my directory entry it represents an edge leading to another object.\u00a0 But\u00a0with\u00a0conventional technology, there is a veil over\u00a0that distant\u00a0part of the graph (my blog).\u00a0 We can read it in a browser but not access the entities it contains as structured objects.\u00a0\u00a0The graph paradigm invites us to\u00a0take off the veil, making\u00a0it possible to navigate nodes\u00a0across many dimensions.<\/p>\n

The real power of directory in\u00a0this kind of\u00a0interconnected world is its ability to serve as the launch pad<\/strong> for getting from one node to a myriad of others by virtue of different \u00a0relationships.\u00a0<\/p>\n

This requires a Graph Protocol<\/strong><\/p>\n

To achieve this we need\u00a0a simple, RESTful protocol that allows use of these launch pads to enter a multitude of different dimensions<\/strong>.\u00a0<\/p>\n

We already know we can build a graph with just HTTP REST operations.\u00a0 After all, the web started as a graph of pages…\u00a0 The pages contained URLs (edges) to other pages.\u00a0 It is a pretty simple graph but that's what made it so powerful.<\/p>\n

With JSON (or XML) the web can return objects.\u00a0 And those objects can also contain URLs.\u00a0 So with just JSON and HTTP you can have a graph of things.\u00a0 The things can be of different kinds.\u00a0 It's all very simple and very profound.<\/p>\n

No technology ghetto<\/strong><\/p>\n

Here I'm going to put a stake in the ground.\u00a0\u00a0When I was back at ZOOMIT<\/a>\u00a0we\u00a0built the first commercial implementation of LDAP while Tim Howes<\/a> was still at University of Michigan.\u00a0 It was a\u00a0dramatic simplification\u00a0relative to X.500 (a huge and complicated standard\u00a0that\u00a0ZOOMIT had also implemented) and\u00a0we were all\u00a0very excited at how\u00a0much Tim had simplified things.\u00a0 Yet in retrospect, I think the origins of LDAP in X.500\u00a0condemned\u00a0directory people\u00a0to\u00a0life in a technology\u00a0ghetto.\u00a0 Much\u00a0more dramatic simplifications were\u00a0coming\u00a0down the pike\u00a0all around us in the form of\u00a0HTML, latter day SQL\u00a0and XML.\u00a0 For every 100 application programmers familiar with these technologies, there\u00a0might have been\u00a0– on a good day – one who knew something about LDAP.\u00a0\u00a0I absolutely respect and am proud of all the GOOD that came from LDAP, but I am also convinced that\u00a0our “technology isolation” was an important factor that kept (and keeps) directory from being used to its potential.<\/p>\n

\"\"<\/a><\/p>\n

So one of the things that I personally want to see as we reimagine directory is that every application programmer will know how to program to it.\u00a0\u00a0We know this is possible because of the popularity of\u00a0the Facebook Graph\u00a0API<\/a>.\u00a0\u00a0If you haven't seen it close up and you have enough patience to watch a\u00a0stream of consciousness demo you will get the idea by watching this little walkthrough of the Facebook Graph Explorer<\/a>.\u00a0\u00a0\u00a0Or better still just go here <\/a>and try with your own account data.<\/p>\n

You have to agree it\u00a0is dead simple and yet\u00a0does a lot of what is necessary to navigate\u00a0the kind of graph we are talking about.\u00a0 There are many other similar explorers available out there – including ours.\u00a0 I chose\u00a0Facebook's simply because it shows\u00a0that this approach is already being used\u00a0at colossal scale.\u00a0\u00a0For this reason it reveals\u00a0the power of the graph\u00a0as an easily understood model that will work across pretty much any entity domain – i.e. a model that is not technologically isolated from programming in general.<\/p>\n

A pluggable namespace with any <\/em>kind of entity plugging in<\/strong><\/p>\n

In fact, the Graph API approach taken by Facebook follows a series of discussions by people now scattered across the industry where the key concept was one of creating a uniform pluggable namespace with \u201cany\u201d kind of entity plugging in (ideas came from many sources including the design of\u00a0the Azure Service Bus<\/a>).<\/p>\n

Nishant and others have posed the question\u00a0as to whether such a multidimensional\u00a0protocol could do what SCIM does.\u00a0 And my\u00a0intuition\u00a0is that if it really is<\/em> multidimensional it should<\/em> be able to provide the necessary functionality.\u00a0\u00a0Yet\u00a0I don't think that\u00a0diminishes in any way the\u00a0importance of or the need for\u00a0SCIM as a\u00a0specialized protocol.\u00a0 Paradoxically it is the very importance of\u00a0the multidimensional\u00a0approach that explains this.<\/p>\n

Let's have a thought experiment.<\/strong>\u00a0<\/p>\n

Let's\u00a0begin with the assumption\u00a0that\u00a0a multidimensional protocol is one of\u00a0the great requirements of our time.\u00a0\u00a0It then seems inevitable to me that\u00a0we will continue to see the\u00a0emergence of\u00a0a number of different\u00a0proposals for\u00a0what\u00a0it should be.\u00a0\u00a0Human nature\u00a0and the angels of competition dictate that different players in the cloud\u00a0will\u00a0align themselves with different proposals.\u00a0 Ultimately we will see convergence – but\u00a0that will take a while.\u00a0\u00a0 Question:\u00a0 How are we do cloud provisioning in the meantime?\u00a0 Does everyone have to implement every multidimensional protocol proposal?\u00a0 Fail!<\/p>\n

So pragmatism calls for us to\u00a0have a widely accepted and extremely focused way of doing provisioning that “makes it fast, cheap and easy to move users in to, out of and around the cloud”.<\/p>\n

Meanwhile, allow developers to combine identity information with information about machines, services, web sites, databases, file systems, and line of business applications through multidimensional protocols and APIs like the Facebook and the Windows Azure Active Directory Graph APIs.\u00a0 For those who are interested, you can begin\u00a0exploring\u00a0our\u00a0Graph API here:\u00a0 Windows Azure AD Graph Explorer (hosted in Windows Azure)<\/a>\u00a0(Select ‘Use Demo Company’ unless you have your own Azure directory and have gone through the steps to give the explorer permission to see it…)<\/p>\n

To me, the goals of SCIM and the goals of the Graph API are entirely complementary and the protocols should coexist peacefully.\u00a0 We can even try to find synergy and ways to make things like schema elements align so\u00a0as to make it as easy as possible to move between one\u00a0and the other.\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"

The Windows Azure Active Directory Developer Preview is live. How does its new Graph API relate to the SCIM provisioning protocol?<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,86,87],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1222"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1222"}],"version-history":[{"count":1,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1222\/revisions"}],"predecessor-version":[{"id":1323,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1222\/revisions\/1323"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}