When logging into Win10 with a federated AAD account, the client calls up to AAD to get the MEX endpoint URL for the user's domain. Then, the client uses this URL to issue a GET to the MEX endpoint on the client's STS.
This works with ADFSv3 and returns a large XML response, but returns a 400 status code from IdentityServer2. It appears that the MEX endpoint on IdentityServer2 supports a POST (which I've seen it handle from Microsoft Sign On Assistant) but not a GET from Win10 AAD sign in flow. Is this expected?
More generally, I've struggled to find any docs that show what the MEX endpoint is meant to support - some kind of spec that tells identity provider vendors what behaviours their STS should exhibit. Any pointers?
When logging into Win10 with a federated AAD account, the client calls up to AAD to get the MEX endpoint URL for the user's domain. Then, the client uses this URL to issue a GET to the MEX endpoint on the client's STS.
This works with ADFSv3 and returns a large XML response, but returns a 400 status code from IdentityServer2. It appears that the MEX endpoint on IdentityServer2 supports a POST (which I've seen it handle from Microsoft Sign On Assistant) but not a GET from Win10 AAD sign in flow. Is this expected?
More generally, I've struggled to find any docs that show what the MEX endpoint is meant to support - some kind of spec that tells identity provider vendors what behaviours their STS should exhibit. Any pointers?
EDIT 11/07/2016: If anyone is interested, Microsoft have now published the required behaviours on an identity provider STS to support Win10 AAD sign in. See the new section 6.2. https://www.microsoft.com/en-us/download/details.aspx?id=41185