Windows Azure Portal is just a webapp. But its also a webapp that comes with an azure AD instance. And that instance can now, using a rather convoluted process, be a managing SSO entity – in charge of a “trust model”. The trust model specified which other directory (namespaces) are associated with the management point. Below, we show the result of having associated our office365 directory (with its verified domain to which that directory proxies requests). we are now able to specify administrators of this portal that are authenticated using the now trusted/federated namespace.
THE process is a little convoluted. One logs into the portal using an existing (subscription grade) account. And, one indicates that one wishes to add another directory namespace to the forest. This induces the browser to not only logout of the current IDP but redirect to the IDP of the namespace to be added. having done that, one states ones consent to allow the principal directories admin to be a co-admin of that federating directory. Having done this, one can logout and return to the windows azure portal (using the primary directory login, which may be a liveid)
Now, upon adding co-administrators, as a above, a name in the newly federated namespace will be allowed, as shown. To this, one indicates which subscriptions (already tied to the login session) should accept this new administrator as a co-admin.
More than that, it even works!
Well done microsoft. You have essentially done what NSA did, about 20 years ago (though they did it with signed DAP requests/results). But, you have done it on a “rather larger scale” and for more clients than just a few US services or NATO countries federating directories. Whats more, Microsoft you retained something they did (well), being able to form polymorphic overlays of trust models (allowing namespaces to federate for different purposes).