Unable to Service Request

Question

I used the mgt api to add an openid provider to ACS, at demosso.accesscontrol.windows.net (if some admin wants to have a look around). It works nicely, and an IDP was duly registered. It accompanied an existing Google IDP registration, created previously using the portal UI.

The openid provider was a custom, happening to use the same google URI/endpoint as is also used by the "google" IDP featured in the ACS UI. Thats just the way that google have setup their cloud. Their cloud tenants do (or at least can) share an endpoint with the public identity, for gmail users. Thus one can logon as a gmail user, or as a Google cloud tenant, by sending openid requests to the very same endpoint.

ACS has an annoying bug/feature that it changed the title of my custom IDP, after a couple of minutes. It changed it to Google!  (Presumably as it recognized the IDP's endpoint as being that of google). Fortunately, it did NOT also change the realm name used in whr=. This means I now have 2 IDP in the list LOOK like they are called google (which makes rule group editing miserable, when using the ACS portal UI).

To do this, I just used the openid discovery project in the ACS SDK. if there is a better way of using Google cloud to talk to a PARTICULAR tenant on a distinct google-cloud endpoint, when then working with ACS's openid handlers, do let me know. I have to assume that this has been the subject of intense testing.

 

Answer 1

Hi,

If you think this is a bug, you can submit a bug on http://connect.microsoft.com/VisualStudio.

Answer 2

its a feature. A very confusing feature.

To be fair to the QA team of the portal UI, the ability of non-Portal sources to alter the records that the UI depends on was added after the portal UI was QA'd.

The real issue is that there is no official/community information source on how best to interact with Google Cloud openid providers, for the Google Apps case.

Google Apps has a convoluted mechanism of letting its tenants, on custom domains, share a common endpoint to which openid request messages are sent, tagged by the domain qualifier on requests to said endpoint. I dont understand it technically (and dont want to go figure either); but it involves so called host-meta files, which may well work perfectly in a Google-only world. I just want to know the steps to do it, correctly, when ACS interacts. I've given up attempting to read the related Google team's documentation for administrators (being far too convoluted). They assume everyone wants to be a developer or evangelist.

For example, today I have incorrect semantic behaviour in ACS. Though I want to express (by registering a custom openid IDP) a trust relationship between a subset of my demosso- ACS tenant hostged realying parties and a particular google apps domain, I cannot do this. As it stands, having introducced a custom openid provider pointing at the google endpoint, gmail users (vs users of a particular google apps domain) can also authenticate through the current trust binding. ACS duly re-asserts attributes from from the requested IDP for gmail users (incorrect, semantically), using the rule base bound to that custom IDP's realm name (correct)

How could I fix this in the interim, before ACS v3 exists?

Well Id hoped to hava a regexp in my rule base for the custom IDP, that guarded at the claim level. I wanted to say: if email claim (from Google) has form *.pingcertification.something.com (the name of the google apps domain), do map the email address (to nameid and the SAML token's attributeStatemenet subject field); dont otherwise. This would allows my RP to re-impose the trust model - based on name form recognition, per app domain. I could not figure how to make ACS do value-express on claim mapping, though (and it may not even be possible).

All part of maturing the public cloud. Only now does anyone care enough... to get to the actual use cases that matter. The days of theory of public websso are, foruantely, oever. We get to do it, for real. In just 2 years time, we will look back on today and wonder just how we could have been SO naieve .