ComponentSpace

Forums



Invalid Azure AD Metadata file base on SAMLValidator.Validate()


Invalid Azure AD Metadata file base on SAMLValidator.Validate()

Author
Message
dmitry.karabanovich
dmitry.karabanovich
New Member
New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)

Group: Forum Members
Posts: 13, Visits: 101
Hello everyone,
I am developing a Service Provider application where a user will be able to upload an Identity Provider metadata file to set up SAML SSO. Before getting configuration information about Identity Provider I call SAMLValidator.Validate() to validate uploaded xml file.
When this logic was implemented I tested this solution with a valid Azure AD metadata file (downloaded directly from Azure AD) and got two errors:
1. This is an invalid xsi:type 'http://docs.oasis-open.org/wsfed/federation/200706:SecurityTokenServiceType'.
2. This is an invalid xsi:type 'http://docs.oasis-open.org/wsfed/federation/200706:ApplicationServiceType'.

Could you please suggest what should be done to pass the validation and why directly downloaded metadata file from Azure AD does not pass validation?
The Azure AD metadata file is attached (some information has been replaced by ".............").

Thank you, Dmitry!
Attachments
Azure AD Metadata CS Forum.xml (1 view, 11.00 KB)
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
We use the SAML metadata XML schema that's provided as part of the SAML v2.0 specification to perform validation of the metadata.

The Azure AD metadata includes both SAML v2.0 and WS-Federation configuration information. It's the WS-Federation information that's failing to validate as it's unknown to the SAML specification.

You would need to remove the WS-Federation configuration from the metadata before attempting to validate the SAML configuration.

Regards
ComponentSpace Development
dmitry.karabanovich
dmitry.karabanovich
New Member
New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)

Group: Forum Members
Posts: 13, Visits: 101
ComponentSpace - 11/25/2020
We use the SAML metadata XML schema that's provided as part of the SAML v2.0 specification to perform validation of the metadata.

The Azure AD metadata includes both SAML v2.0 and WS-Federation configuration information. It's the WS-Federation information that's failing to validate as it's unknown to the SAML specification.

You would need to remove the WS-Federation configuration from the metadata before attempting to validate the SAML configuration.

Oh, got it, thank you!

About the possible solution: as I understand, it is possible that not only WS-Federation configuration could exist in uploaded .xml file together with SAML configuration, so we are not able to handle all possible solutions. In this case, what if we will not remove unnecessary information but will extract only SAML configuration and validate it.

And there is a question (I understand that this question is not related to the work of the library, for which I apologize in advance. I do not expect a full answer to this question, but I would be happy to take any advice): is there a way to extract information (part of xml) from xml which is connected only with SAML specification (possibly somehow it could be done using scheme, or only IDPSSODescriptor node should exist for ServicesProvider)?

Thank you!

 
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
I suggest removing all child nodes except for the IDPSSODescriptor. The IDPSSODescriptor is the only node you're interested in.

Regards
ComponentSpace Development
dmitry.karabanovich
dmitry.karabanovich
New Member
New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)

Group: Forum Members
Posts: 13, Visits: 101
ComponentSpace - 11/26/2020
I suggest removing all child nodes except for the IDPSSODescriptor. The IDPSSODescriptor is the only node you're interested in.

Perfect, thank you for the advice!
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
You're very welcome.

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 2 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search