Azure ADFS with Shibboleth SP 2.6 metadata issues

[Luke Alexander]

Hi,

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.

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
2018-03-02 12:47:35 DEBUG OpenSAML.MessageDecoder.SAML2 [1]: message from (
https://sts.windows.net/<unique_id>/)
2018-03-02 12:47:35 DEBUG OpenSAML.MessageDecoder.SAML2 [1]: searching
metadata for message issuer...
2018-03-02 12:47:35 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [1]:
evaluating message flow policy (replay checking on, expiration 60)
2018-03-02 12:47:35 DEBUG XMLTooling.StorageService [1]: inserted record
(_52fb8d05-693c-4c49-8abf-e3f5f2e462b4) in context (MessageFlow) with
expiration (1519995095)
2018-03-02 12:47:35 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [1]:
validating signature profile
2018-03-02 12:47:35 DEBUG XMLTooling.CredentialCriteria [1]: keys didn't
match
2018-03-02 12:47:35 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: unable to
validate signature, no credentials available from peer
2018-03-02 12:47:35 DEBUG XMLTooling.TrustEngine.PKIX [1]: validating
signature using certificate from within the signature
2018-03-02 12:47:35 DEBUG XMLTooling.TrustEngine.PKIX [1]: signature
verified with key inside signature, attempting certificate validation...
2018-03-02 12:47:35 DEBUG XMLTooling.TrustEngine.PKIX [1]: checking that
the certificate name is acceptable
2018-03-02 12:47:35 DEBUG XMLTooling.TrustEngine.PKIX [1]: adding to list
of trusted names (https://sts.windows.net/<unique_id>/)
2018-03-02 12:47:35 DEBUG XMLTooling.TrustEngine.PKIX [1]: certificate
subject: CN=Microsoft Azure Federated SSO Certificate
2018-03-02 12:47:35 DEBUG XMLTooling.TrustEngine.PKIX [1]: unable to match
DN, trying TLS subjectAltName match
2018-03-02 12:47:35 DEBUG XMLTooling.TrustEngine.PKIX [1]: unable to match
subjectAltName, trying TLS CN match
2018-03-02 12:47:35 ERROR XMLTooling.TrustEngine.PKIX [1]: certificate name
was not acceptable
2018-03-02 12:47:35 ERROR OpenSAML.SecurityPolicyRule.XMLSigning [1]:
unable to verify message signature with supplied trust engine

So my question is: does the client need to regenerate the certificate so it
contains valid DN/subjectAltName or are those debug messages of no concern?
The certificate name not being acceptable being the real error, do you have
any pointers on this?

I found very few threads on people setting up Azure based ADFS against SP...

Thanks for any help you can offer!

Regards,
Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180302/93f71ce9/attachment.html>