asp.net-core.net-coresaml-2.0x509certificate2component-space

Export local idp/sp metadata separately with ComponentSpace.Saml2 ASP.NET Core

I want to export the sp/idp metadata, so external client can fetch it from the public endpoint. ComponentSpace.Saml2 for asp.net (.net framework) had static MetadataExporter class for that (docs) and the usage was pretty simple. But I'm struggling with the same in ComponentSpace.Saml2 for asp.net core. What is a proper way to export sp only/idp only metadata for core version?

The options I've discovered so far:

  1. ConfigurationToMetadata.ExportAsync (docs) - exports the whole configuration (both local sp and local idp, if they exists), so you have extract sp/idp only yourself;
  2. MetadataExporter + ServiceProviderMetadataExporter/IdentityProviderMetadataExporter (docs) - requires you to populate all the saml config stuff from idp local config + sp partner config/ sp local config + idp partner config.

I'm not sure which one is recommended. Also I checked the docs, not much of help for metadata export specifically.

Thank you and sorry if the question or its format looks weird (this is my first attempt)

Solution

  • Yes, there is different approach depends on your need.

    1. ConfigurationToMetadata.ExportAsync:This method can be used when you have a complete SAML configuration and you want to export the entire metadata which includes both the local service provider (SP) and local identity provider (IdP) components, if they exist. If your goal is to export just the SP or the IdP metadata, you would indeed need to extract the appropriate section manually after export.

    2. Using MetadataExporter with ServiceProviderMetadataExporter or IdentityProviderMetadataExporter:These are more specific to exporting only the SP or IdP metadata, respectively. You would typically create instances of ServiceProviderMetadata or IdentityProviderMetadata, populate them with the necessary information from your configuration, and then use the exporters to generate the metadata XML.

    The second approach allows more fine-grained control over what is exported. just would like to add one thing when populating the metadata, you'll need to take into account the expected SAML configuration for your SP or IdP partner, and this typically includes details such as entity IDs, assertion consumer service URLs, single logout service URLs, certificates, and so forth.