WS-Fed ability to import federationmetadata.xml from 3rd party IDPs

[maliksahil]

Is your feature request related to a problem? Please describe.

When you try to import FederationMetadata.xml from a URL, with the current implementation of MSAL, things work when you import from ADFS becasue wsdl:definitions/ node is the top level node, as shown below.

However, when importing from third party Idps such as siteminder, this node is at a different level, as shown below, which causes this import to fail.

As per the spec, this should be an acceptable format, https://www.w3.org/TR/ws-metadata-exchange/#Appendix-A

Describe the solution you'd like
There are two possible fixes,

1. That we introduce a new overload to GetMexDocumentAsync where we accept which node we can read from.
2. Probably a good fix here is also to introduce a separate method where the federationmetadata.xml can be read in from a file.

I feel option #2 would be useful anyway, there are frequently scenarios where you need to pass in the xml by hand. This would give someone flexibility to hand-edit and feed a file if necessary, or when the file is unreachable because of any reason. I remember back in VS2005, authentication was a reason to have a file hand-fed in. But this would be useful regardless in environments where the federationmetadata.xml is distributed manually.

So ideally we should do both #1 and #2.

Describe alternatives you've considered
As an alternative, the customer can choose to hand-edit the 3rd party IDPs federationmetadata to match in structure as ADFS's and host it manually.

Additional context
None

[jmprieur]

Thanks @maliksahil : this is very clear and actionable!
@trwalke @henrik-me this is a recurrent issue. We might want to prioritize it (#supportability)

[mifarca]

@jmprieur along that, we have the following request for the same issue:
"the same situation but with the: "msal library wrong format for usernamemixed auth request""

Details troubleshooting MSAL auth request issue:
While trying to authenticate a federated account in O365 with MSAL, the authentication fails when the IDP is a third party IDP (siteminder)
When MSAL sends an auth request of type « usernamemixed », to siteminder , the library puts a TAG in the “request body »: wsa:messageID…</wsa:messageID>

The problem is that this TAG should be written with a “M” (uppercase)
From : https://www.w3.org/Submission/ws-addressing/

3.1. Message Information Headers XML Infoset Representation
The message information header blocks provide end-to-end characteristics of a message that can be easily secured as a unit. The information in these headers is immutable and not intended to be modified along the message path.

The following describes the contents of the message information header blocks:
wsa:MessageID xs:anyURI </wsa:MessageID>
<wsa:RelatesTo RelationshipType="..."?>xs:anyURI</wsa:RelatesTo>
wsa:Toxs:anyURI</wsa:To>
wsa:Actionxs:anyURI</wsa:Action>
wsa:Fromendpoint-reference</wsa:From>
wsa:ReplyToendpoint-reference</wsa:ReplyTo>
wsa:FaultToendpoint-reference</wsa:FaultTo>

This IDP is case sensitive, and then returns a HTTP 500 response.

Is there a chance for this to be addressed as well along the request?

[jmprieur]

Design: L
-[ ] Understand the scenario end to end
-Regression testing are ok

• we probably don't have setups for the scenario we are trying to enable => we need to setup that environement

[jmprieur]

@maliksahil : do you know how we can setup a test environment? Is it something you could work with the identity lab?

[bgavrilMS]

We could test using one of our own accounts, and maybe even setup automation with a lab account.

[trwalke]

• Enabling MSAL to read federation metadata form a file provided by the developer
• Fix MessageID character casing.
• Add overload for GetMexDocumentAsync to enable selection of the proper XML node when reading federation metadata form 3rd party IPs

[trwalke]

Need to sync with Sahil to get clarity on desired changes. Setting up time for it