A long time ago, we decided to re-implement something we called the agent desktop. It was to be a list of those SSO sites to which you might click … to go. Of course, being SSO sites the idea was that no further credentials would be required.
We first implemented this nearly 15 years ago (or rather Isaac did do). It was a feature of the so-called Magic desktop, for which there was an administrator page (that configured the links that MIGHT appear on the users desktop page). Essentially the so-called “setup manager” (available on a administrator menu) allowed links to be assigned to user profiles that, if the user satisfied the rules of the profile, would populate a link on that users desktop.
IT wasn’t “really” an SSO portal page. But it was a single-sign on experience, in the sense that multiple apps were supposedly able to make RPC connections to a certain Magic ‘broker” – that would authenticated users and deliver the profile to the consuming magic process perhaps in the conrol of a third party (responsible for acting as an RP site).
As far as I know, it never worked or rolled out as intended, being at least 10 years ahead of the curve. In reality, since Microsoft’s multi-app, cloud-centric SSO (based on ws-fedp, oauthp and SAML/JWT assertions) is only now being rolled out, as seen below, perhaps it was more like 20 years ahead of the curve!
Today, one can add to a windows azure subscription multiple applications, PER directory namespace that has been associated with that subscription. Of course, one namespace comes WITH the subscription, that acts as a management point (for all the rest, optionally affiliated). But once affiliated ,users in each namespace can be managed by the subscription – and granted rights to access third party applications – to be associated with Azure (AD) – much as we intended magic apps to be associated with a magic broker.
For my part, I have associated my Office365 account (netmagic.onmicrosoft.com) with my azure subscription and its built in directory (rapmlssso.onmicrosoft.com). Since netmagic namespace has a rapmlsqa.com synonym (being a verified domain within that office365 tenant’s subscription and associated Azure AD), the users within the namespace of rapmlsqa.com are ALS associated with the azure centric rapmlssso.onmicrosoft.com directory. Since the latter is the management point for the subscription, this means that one can now bind users from EACH of the namespaces (rapmlssso, and rapmlsqa.com) to third party SSO relying parties:
in the azure portal, for a given directory, we see the UI used for selecting which of the possible namespace (for users) might now have applications associated with them, those nominally hosted in azure (or externally) and those of other vendor.
in my case, I added my wordpress.com account name to the associated application, which on my application access page got me to:
Obviously, we see wordpress.com added (to the applications that come built into office managed accounts (office!). This page is somewhat similar to our own portal page (which happens to have no SSO links, in this config)
A little fiddler tracing
gets us to the following (on a machine that happens to have a wordpress app installed, in Windows 8)
this gets us to
I’m then warned by this “MSOL” installation wizard that a browser needs an extension:
evenually, we can get the SSO process to handoff to a mechanism whereby the stored username/password is supplied to wordpress (live) to get a logon