Aspnetcore.docs: Generating Metadata XML (Statically or Dynamically)

[NickBeukema]

This documentation looks great, and has worked perfectly for setting up my DotNet Core Application to be a Relying Party in a WS-Fed trust relationship, but I do not see any documentation around the topic of creating a metadata endpoint for a ADFS Provider to pull and trust my application. Are there tools to generate these, or anyway to know the format so I can create an endpoint dynamically?

Is exchanging metadata urls the correct way to ensure trust, or is the manual process shown in these docs the suggested way to trust an application?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 59d6d442-8d46-3f9e-e75a-ad9d900fc117
• Version Independent ID: d07c4058-452f-cdac-c59d-8f09e70a43f3
• Content: Authenticate users with WS-Federation in ASP.NET Core
• Content Source: aspnetcore/security/authentication/ws-federation.md
• Product: aspnet-core
• GitHub Login: @chlowell
• Microsoft Alias: scaddie

[Rick-Anderson]

Thanks for the suggestion to create a new doc creating a metadata endpoint for a ADFS Provider to pull and trust my application

[Rick-Anderson]

@chlowell please review

[chlowell]

I don't think I'm parsing the question successfully. @NickBeukema can you further describe what you're trying to accomplish?

I'm not an expert on WS-Fed or Active Directory, but as I understand it you register your application with the WS-Fed provider which then creates federation metadata and provides an endpoint for retrieving it. So in this case Active Directory is the tool for generating these.

[NickBeukema]

@chlowell Yes you are correct, that is one side of it, but the process of registering your application with the WS-Fed provider can happen in multiple ways.

1. You manually add a client through Active Directory, including their redirect URL and the claims they will be using, along with everything else you can configure for a WS-Fed client, like encryption (I'm not an expert either, still learning what all of these are)
2. You can create a metadata endpoint of your own to plug into Active Directory, similar to the one that AD provides for clients. This allows for the exchange of one URL to the provider in order to authorize the client, and keep it authorized, even when encryption keys are rotated (Which I believe is the largest use-case of this method).

After quite a bit of digging, I have found a util that can be run on Windows only, that will generate this metadata XML file for you using Windows Identity Foundation SDK 4.0, mentioned in this one Stack Overflow Post.

I have multiple instances of a DotNet Core Application for different environments, and need this file to be somewhat different for each (redirect URLs mostly), so I've gone ahead and generated the basic structure using the util mentioned above, then created a controller that just fills in the environment specific metadata on the XML file and returns the finished product.

I suppose my original question had two parts, which could hopefully be clarified in the documentation:

1. What format does AD as the provider require for a relying party's metadata file? (Format, required nodes, etc)
2. I'm still learning about WS-Fed, is exchanging metadata URLs the appropriate way to establish a trust relationship between provider and relying party?

[chlowell]

I think the rigorous answers to your questions are in the WS-Federation spec, which documents the protocol and federation metadata. That's a heavy read though. If you're using Azure AD, its federation metadata documentation is probably more useful.

@Rick-Anderson @CamSoper any other ideas for good sources of AD WS-Fed documentation? This looks broader than something we'd document for this middleware, or ASP.NET Core specifically.

[Rick-Anderson]

Thanks for contacting us.
We don’t have the resources to invest in this area, so we are closing the issue. Should your request generate enough 👍 responses, we’ll reconsider.