Azure-activedirectory-identitymodel-extensions-for-dotnet: Full SAML2P/WS-Federation Metadata support

[AndersAbel]

As discussed in #758, it would be great to have full metadata support, e.g. ContactPerson, Organization, AttributeConsumingService. To be able to both parse and generate metada, both the classes representing metadata contents as well as a serializer are needed.

[brentschmaltz]

@AndersAbel thanks, we will review this for next release.

[AndersAbel]

@brentschmaltz any updates on this? We have a community initiative on this (part of https://github.com/Sustainsys/Saml2/pull/939) that would be possible to extract to a separate library. But I don't want to spend too much time on it if this issue will be implemented shortly. Or maybe our code could be used as the basis for this feature?

[brentschmaltz]

@AndersAbel we are open to getting this into IdentityModel.

[brockallen]

I think this would help position folks to be able to build out their own ws-fed STS as well, yes? These are missing APIs preventing that now, yes?

[brentschmaltz]

@AndersAbel @brockallen Anders and myself had a great skype call today.
There are a couple items that would help make this happen.

1. Ability to have multiple signatures in the envelope
2. SamlSecurityTokenHandler can validate token using an XmlReader.

[brentschmaltz]

for 5.3.1 we should do 1 and 2 above.
we will still need to think about how much metadata we can support

[AndersAbel]

1. is mostly not related to Metadata, but rather SAML protocol response message validation. I suggest that we discuss that in #1012.

I've had a look at the metadata from an ADFS server to understand better how the SAML2 metadata spec and the WS-Fed metadata is related. The overall structure of the metadata file is defined in the Saml2 metadata spec. The Saml2 endpoints are of course also defined there, inside SAML2 role descriptors. The WS-FED endpoints are described by separate role descriptors. The role descriptor node itself belongs to the Saml2 metadata namespace. But everything in it (except the signing key info) is defined i WS-FED or SOAP namespaces.

So my view is that the WS-Fed metadata is an extension to the SAML2 spec, although only a small part of the SAML2 spec is used by WS-Fed.

I suggest that a new Microsoft.IdentityModel.Xml.Metadata package is created that contains both Saml2 and WS-Fed metadata DTOs and serializers. This package has no further dependencies on WS-Fed or SAML2-specific packages. The current WSFederationMetadataSerializer is either deprecated or rewritten to become a wrapper of the new serializer.

[AndersAbel]

@brentschmaltz did you see my PR for multiple signatures? That's actually the only thing that affects metadata. The new overload to the SamlSecurityTokenHandler is for full SAML2P support.

[brentschmaltz]

@AndersAbel I haven't had a chance to look at it this week.
I'll get to it next week.

Thanks for pinging.

[brentschmaltz]

@AndersAbel we are lining up our 5.5.0. For that we will get the multiple signatures in that you asked for so long ago. Can we close this, I doubt we will ever do SamlP.

[AndersAbel]

Yes, I'm fine with closing this as won't-fix here. FYI I have full SAML2P metadata support in the Sustainsys.Saml2 package already :)