https://github.com/AzureADSamples/WindowsAzureAD-GraphAPI-Sample-OrgChart nicely points out that we are NOT talking about merely adding a few schema objects to AAD, in much the same way that one used to add a few classes for exchange to AD. Rather, we are talking about extensions for Apps - and apps in a multi-tenant world.
Unlike the typical use of multi-tenant in traditional asp.net webapp land, in AAD-enabled webapp-land this term means those AAD_tenants who have formed a private trust domain, through oauth consent processes and associated permissions allocation.
The 1990-era X.500 model had a nice mental model, that helps me for one understand the above. The main issue is : what is the representation - in terms of classes, objects, schemas, inheritances etc (where one notes that these terms do not have the same"basis" as OOP models found in the typical programming language).
X.500 allowed parallel worlds of schema "representation", called partitions (if I remember right). Then, for a given named object in the principal schema, it could "subscribe to" one or more extension partitions. (each partition was just a huge blob file, full of serialized instances). An object in the any one partition could and would have a backpointer to the named object in the principal partition - to "represent" subscription of schema/data extensibility; or multiple such backpointers if multiple namespaces had subscribed. (yes its just VSAM, from 1960...)
(One standard extension held management data about usage o objects in the principal schema, as retained by the service agents doing request processing - an early "app" that could say: object read 5 times per second, in last week...; another held security policy info that guided the master or slave service agents when doing crypto signature validation or (not) supplying stale crypto data FROM slave-caches when reading)
With this mental model, THESE DAYS I simply see each app - now as in metro-land "app" - having a small directory partition, storing away its app-specific object classes. The objects within THEREFORE have multiple backpointers, to the *several* AAD tenants/namespaces who have engaged in conseting to allow their combined users/principals to participate in a private trust model (rather like an AD-era enterprise-wide forest of trusts...)
The nice thing about the model is that the original named object in the principal schema - a user object in N tenants in their private multi-tenant trust model in all likelihood - now APPEAR to have "inherited" the app objects, STORED in the app-specific partition BUT LINKED ASIF a class in the principal schema; giving "per-app schema extension" when using the likes of a graph-explorer. Furthermore, which extensions "appear" is access-controlled (by membership in the trust model between namespaces)
And obviously, there can be as many such "app extensions" as there are apps, or private "trust models" that limit which TENANTS HAVE access to WHICH app extensions' INHERITED extension-object-classes.
Do I have the right SORT of mental model?
If I do, Ill work on integrating this kind of concept into our usage of AAD... because i COULD believe in that! If I don't, I should perhaps go away for a year re AAD extensions - and wait for next year's more finished samples that will presumably show what they are really intended for.