This question is a continuation from How to pass required claims to OpenID identity provider with Azure ACS?
Its a slightly different take on the problem though, thus I'm posting this as a new question. Note: I'm also cross-posting this to the Azure Security forum but so far haven't gotten any useful input.
The Azure ACS samples shows that it is possible to add arbitrary OpenID identity providers to ACS. But for ACS to actually be helpful in our project as an STS for various popular providers we set out to get ACS working with MyOpenID.com (again, also used in the samples). The problem, as also the good Vittorio shows, is that MyOpenID will not give us claims like name and email address unless asked for. Vittorio and others states that this is because MyOpenID doesn't support Attribute Exchange.
I'm not so sure about that, though. Digging a bit deeper into the request url that ACS generates I can see that parameters like openid.ns.ax=http://openid.net/srv/ax/1.0 and openid.ax.required=email,fullname,firstname,lastname. Also, openid.ax.type.email is typed to the axschema.org/contact/email type. This is where things go wrong with MyOpenID. MyOpenID does not understand the axschema.org types and will thus not return an email value.
What I do know is that MyOpenID understands the schema.openid.net/contact/email type. So building on this I manually changed the ACS request url to use the openid.net schema instead of axschema. Lo and behold, MyOpenID reacts and shows that my email address in fact will be returned.
Here is a list of the parameters I'm trying to pass in to myopenid.com/server endpoint:
- openid.ns=http://specs.openid.net/auth/2.0
- openid.mode=checkid_setup
- openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select
- openid.identity=http://specs.openid.net/auth/2.0/identifier_select
- openid.realm=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid
- openid.return_to=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid...
- openid.ns.ax=http://openid.net/srv/ax/1.0
- openid.ax.mode=fetch_request
- openid.ax.required=email,fullname
- openid.ax.type.email=http://schema.openid.net/contact/email
- openid.ax.type.fullname=http://schema.openid.net/namePerson
Unfortunately, when the response is returned back to ACS it isn't good enough, and ACS fails with the following error codes:
HTTP Error Code: 400 Message: ACS30000: There was an error processing an OpenID sign-in response. Inner Message: ACS90014: Missing required field 'openid.ax.value.email'. Trace ID: f8e09e6f-0765-4370-9f03-f744cce6fa2a Timestamp: 2011-08-02 17:12:57Z
I've tried adding additional fields without changing the original email type, but only get the same errors. I'm starting to suspect that it is in fact ACS that is not supporting AX to its full extent and that it is somewhat hardcoded to only accept claims of certain types.
The question is: does my request parameters look right to you or am I missing something obvious here?
NOTE: my initial setup is working, if I leave the ACS request unchanged and in ACS only configures a single Passthrough rule for the identity provider, I can successfully authenticate my website through ACS using the MyOpenID identity provider. The problem remains though that MyOpenID will not hand over e.g. FullName or Email to ACS if the request from ACS does not explicitly ask for the claim types http://schema.openid.net/namePerson or http://schema.openid.net/contact/email
For security reasons, ACS can't allow callers to retype the email address claim. Effectively, what you're unknowingly doing is attempting is a variant of attack 4.5 (OpenID Data Type Confusion) from this paper. For security reasons, ACS has to ensure that email address and the other AX claims it supports exactly match the types it is aware of, otherwise malicious callers could trick ACS and substitute one claim for another. It's not that ACS doesn't support AX, it's that ACS only supports a single claim type as the email claim, and it's not the same one MyOpenID uses. In short, this isn't going to work.