which is evidence support for
The texts above are output from the MOSDAL tool:
The trail of the stack trace suggests that via the MetadataExchange protocol (SOAP messages pulling the elements of the metadata) data HAS been pulled. And, then certain artifacts are being sought, in the “message sets” (this is the right word, for the result of pulling serialized metadata objects). Within the list of artifacts, one is looking for a particular policy/binding, in the “service element”.
well we can decode the objects much as probably that conformance checker is doing (probably using the same library):
The name of the method (ADFSPolicy.FromServiceDescription) suggests that its looking for a policy object (within the 2005 service description).
We do note the obvious, that from ADFS there is 1 service description (whereas there are 2 from or STS):
I suppose the obvious thing to do is make ours have 1, too!
The first trick is to make sure there is no import to the ws-policy bindings (because by default bindings get a tempuri namespace). This has to be true regardless of whether or not one uses the singleWSDL filtering (available in dotNet 4.5)
We achieved that simply by declaring the binding namespace (and name, to match ADFS): securitytokenservice!
When we look at the client-side of the mex endpoint (the soap call getting the parts of the above), we do now get an ADFS-like SINGLE servicedescription (and 2 schema parts).
If you think about it, it makes perfect sense that office 365 would refuse to follow (in WSDL documents) URI references to policy objects (bindings). Rather it wants definitive object descriptions on the URL that an administrator (under login policy) has defined in the federation settings record.
With that done, we move ONE step further along the chain to nirvana.
Now to the semantic validation error! (testing for windows authentication endpoint/binding fails).