<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Beyond LDAP &#8211; have a look at system.identity</title>
	<atom:link href="http://blogs.kuppingercole.com/kuppinger/2010/06/20/beyond-ldap-have-a-look-at-system-identity/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.kuppingercole.com/kuppinger/2010/06/20/beyond-ldap-have-a-look-at-system-identity/</link>
	<description>KuppingerCole</description>
	<lastBuildDate>Wed, 08 Feb 2012 09:08:03 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Identités : faut-il sacrifier LDAP ? — SecurityVibes Magazine</title>
		<link>http://blogs.kuppingercole.com/kuppinger/2010/06/20/beyond-ldap-have-a-look-at-system-identity/comment-page-1/#comment-319</link>
		<dc:creator>Identités : faut-il sacrifier LDAP ? — SecurityVibes Magazine</dc:creator>
		<pubDate>Wed, 23 Mar 2011 13:45:43 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.kuppingercole.com/kuppinger/?p=305#comment-319</guid>
		<description>[...] la gestion des identités ? C&#8217;est en tout cas une piste explorée par Martin Kuppinger dans un récent billet. Deux reproches principaux sont faits à LDAP dans le domaine de la gestion des identités : [...]</description>
		<content:encoded><![CDATA[<p>[...] la gestion des identités ? C&#8217;est en tout cas une piste explorée par Martin Kuppinger dans un récent billet. Deux reproches principaux sont faits à LDAP dans le domaine de la gestion des identités : [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kim Cameron</title>
		<link>http://blogs.kuppingercole.com/kuppinger/2010/06/20/beyond-ldap-have-a-look-at-system-identity/comment-page-1/#comment-241</link>
		<dc:creator>Kim Cameron</dc:creator>
		<pubDate>Mon, 28 Jun 2010 07:57:06 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.kuppingercole.com/kuppinger/?p=305#comment-241</guid>
		<description>Emmanuel, just for the record, I&#039;ve worked with X.500 and LDAP since the very beginning, and my company, ZOOMIT, did the first commercial implementation of LDAP.  So there is no need to be derisive - I do actually understand how it works.  The essence is that it implements the X.500 model.  This model is based on named entities that represent real-world objects.  The distinguished name (DN) is the base identifier of the objects, and consists of attributes strung together in a sequence out of which a hierarchy is constructed.  Thus the identifier and hierarchy are conflated with the semantic contents of the object. 
 
X.500 also has the concept of aliases.  The alias is an obect that points at another object.  It has its own name as a sequence of distinguished attributes.  So the aliases are a second set of objects that live within a second hierarchy and point at objects living within a first hierarchy.   
 
The main problem is that neither of these hierarchies have much to do with what programmers need.  Let&#039;s face it.  Hierarchical databases went out around 1980.  People who build the vast majority of the world&#039;s applications don&#039;t use hierarchical databases - they use relational databases.  They build hierarchies out of relationships, and don&#039;t hard-code them.  This has a great many advantages, and these advantages explain why, in most aspects of development, relational databases have won out.  Further, hard-coding causes a great many difficulties which we could drill into when we have more time.  Now those of us who work in identity need to bring directory into alignment with relational databases so the world&#039;s programmers understand it and can benefit from the advantages it brings. 
 
I can&#039;t discuss all the issues here, but will do so more in upcoming days on my blog, and I do invite you to continue this discussion with me there. </description>
		<content:encoded><![CDATA[<p>Emmanuel, just for the record, I&#039;ve worked with X.500 and LDAP since the very beginning, and my company, ZOOMIT, did the first commercial implementation of LDAP.  So there is no need to be derisive &#8211; I do actually understand how it works.  The essence is that it implements the X.500 model.  This model is based on named entities that represent real-world objects.  The distinguished name (DN) is the base identifier of the objects, and consists of attributes strung together in a sequence out of which a hierarchy is constructed.  Thus the identifier and hierarchy are conflated with the semantic contents of the object. </p>
<p>X.500 also has the concept of aliases.  The alias is an obect that points at another object.  It has its own name as a sequence of distinguished attributes.  So the aliases are a second set of objects that live within a second hierarchy and point at objects living within a first hierarchy.   </p>
<p>The main problem is that neither of these hierarchies have much to do with what programmers need.  Let&#039;s face it.  Hierarchical databases went out around 1980.  People who build the vast majority of the world&#039;s applications don&#039;t use hierarchical databases &#8211; they use relational databases.  They build hierarchies out of relationships, and don&#039;t hard-code them.  This has a great many advantages, and these advantages explain why, in most aspects of development, relational databases have won out.  Further, hard-coding causes a great many difficulties which we could drill into when we have more time.  Now those of us who work in identity need to bring directory into alignment with relational databases so the world&#039;s programmers understand it and can benefit from the advantages it brings. </p>
<p>I can&#039;t discuss all the issues here, but will do so more in upcoming days on my blog, and I do invite you to continue this discussion with me there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin Kuppinger</title>
		<link>http://blogs.kuppingercole.com/kuppinger/2010/06/20/beyond-ldap-have-a-look-at-system-identity/comment-page-1/#comment-236</link>
		<dc:creator>Martin Kuppinger</dc:creator>
		<pubDate>Fri, 25 Jun 2010 07:50:23 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.kuppingercole.com/kuppinger/?p=305#comment-236</guid>
		<description>It is not about having multiple directories with different schemas and different hierarchies on one server. That is not the point, obviously. The point is that within one directory I have one schema. Within this schema, I have one hierarchy (which again is obvious when looking at the concepts of LDAP, the DNs, and so on). Thus based on the same set of data I end up with some inflexibility. I can for sure use Virtual Directory Services on top to create different hierarchical views but that is just a workaround.
Thus it is not about whether an RFC is implemented correctly (I assume that M$ is a biased abbreviation for Microsoft). It is also not about LDAP being broken, but LDAP being limited. By the way: For sure I know not only Microsoft Active Directory but many other directory services.
Aliases are not sufficient. That is again very obvious to any practicioner, because it is an inefficient workaround. Thus there is the obvious need to rethink this issue.
I&#039;m pretty sure that I&#039;ve got some of the points (which were examples). And just because the new concept has been developed by someone from Microsoft it is not necessarily bad. The real bad thing, from my perspective, is being narrowminded.</description>
		<content:encoded><![CDATA[<p>It is not about having multiple directories with different schemas and different hierarchies on one server. That is not the point, obviously. The point is that within one directory I have one schema. Within this schema, I have one hierarchy (which again is obvious when looking at the concepts of LDAP, the DNs, and so on). Thus based on the same set of data I end up with some inflexibility. I can for sure use Virtual Directory Services on top to create different hierarchical views but that is just a workaround.<br />
Thus it is not about whether an RFC is implemented correctly (I assume that M$ is a biased abbreviation for Microsoft). It is also not about LDAP being broken, but LDAP being limited. By the way: For sure I know not only Microsoft Active Directory but many other directory services.<br />
Aliases are not sufficient. That is again very obvious to any practicioner, because it is an inefficient workaround. Thus there is the obvious need to rethink this issue.<br />
I&#8217;m pretty sure that I&#8217;ve got some of the points (which were examples). And just because the new concept has been developed by someone from Microsoft it is not necessarily bad. The real bad thing, from my perspective, is being narrowminded.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Emmanuel Lecharny</title>
		<link>http://blogs.kuppingercole.com/kuppinger/2010/06/20/beyond-ldap-have-a-look-at-system-identity/comment-page-1/#comment-235</link>
		<dc:creator>Emmanuel Lecharny</dc:creator>
		<pubDate>Thu, 24 Jun 2010 10:41:10 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.kuppingercole.com/kuppinger/?p=305#comment-235</guid>
		<description>Funny, but totally off base. 
 
LDAP allows more than one hierarchy. You can even have more than one schema used in a Ldap Server. My be M$ not implementing the RFC correctly is a reason not to support that, but it has nothing to do with LDAP being broken 
 
LDAP allows you to refer data in many places through aliases. No need to invent another mechanism. 
 
LDAP is not perfect, but you missed to point out the real problem in your article. </description>
		<content:encoded><![CDATA[<p>Funny, but totally off base. </p>
<p>LDAP allows more than one hierarchy. You can even have more than one schema used in a Ldap Server. My be M$ not implementing the RFC correctly is a reason not to support that, but it has nothing to do with LDAP being broken </p>
<p>LDAP allows you to refer data in many places through aliases. No need to invent another mechanism. </p>
<p>LDAP is not perfect, but you missed to point out the real problem in your article.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tweets that mention Beyond LDAP – have a look at system.identity &#124; Martin Kuppinger -- Topsy.com</title>
		<link>http://blogs.kuppingercole.com/kuppinger/2010/06/20/beyond-ldap-have-a-look-at-system-identity/comment-page-1/#comment-234</link>
		<dc:creator>Tweets that mention Beyond LDAP – have a look at system.identity &#124; Martin Kuppinger -- Topsy.com</dc:creator>
		<pubDate>Sun, 20 Jun 2010 17:11:39 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.kuppingercole.com/kuppinger/?p=305#comment-234</guid>
		<description>[...] This post was mentioned on Twitter by Kuppinger Cole, Laura E. Hunter. Laura E. Hunter said: RT @kuppingercole: Beyond LDAP – have a look at system.identity http://is.gd/cWfic [...]</description>
		<content:encoded><![CDATA[<p>[...] This post was mentioned on Twitter by Kuppinger Cole, Laura E. Hunter. Laura E. Hunter said: RT @kuppingercole: Beyond LDAP – have a look at system.identity <a href="http://is.gd/cWfic" rel="nofollow">http://is.gd/cWfic</a> [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

