Azure ADFS with Shibboleth SP 2.6 metadata issues

Peter Schober peter.schober at univie.ac.at
Fri Mar 2 10:39:14 EST 2018


* Luke Alexander <luke at brandwatch.com> [2018-03-02 16:26]:
> We are having issues integrating a client of ours who use Microsoft Azure
> ADFS against our Shibboleth 2.6 service provider.
> 
> In the past we've used the adfs2fed.py script to 'convert' ADFS metadata to
> be parsed and loaded onto the service provider - this has worked without
> issue, thought this doesn't seem to work so well with Azure ADFS metadata.

If it's SAML 2.0 Metadata the Shib SP should never have needed
anything special in order to load it. (If you set validte="true" you
may need to supply the SP with additional XSD schemas for the
RoleDescriptor stuff MS-ADFS usually contains, but you acn just as
easily not enable validation for that metadata provider.)

> This new client runs ADFS from Azure, they appear to have a standard
> microsoft entityID, eg: entityID="https://sts.windows.net/<unique_id>/"
> 
> The cert contained within the metadata has:
> 
>         Issuer: CN=Microsoft Azure Federated SSO Certificate
>         Validity
>             Not Before: Feb 13 15:23:34 2018 GMT
>             Not After : Feb 13 15:23:24 2021 GMT
>         Subject: CN=Microsoft Azure Federated SSO Certificate
> 
> When we load (the non-validated) metadata on to the service provider and
> the client attempts to access the protected resource we see these errors in
> the logs:
>
> 2018-03-02 12:47:35 DEBUG OpenSAML.MessageDecoder.SAML2 [1]: extracting
> issuer from SAML 2.0 protocol message

The error and those messages are not from loading the metadata, so I
think the whole premise of your question is wrong.

The error comes from trying to validate the SAML message from the IDP,
and falling through to PKIX checking (which is not what you want) and
ultimately failing. Short version

> 2018-03-02 12:47:35 ERROR OpenSAML.SecurityPolicyRule.XMLSigning [1]:
> unable to verify message signature with supplied trust engine

The IDP likely is not signing the protocol message with a key you have
the matching certificate in metadata for.

-peter


More information about the users mailing list