AAD + SAML: Application-specific certificates and metadata

0
votes

I am quite confused about setting up SAML SSO for an application in Azure Active Directory.

I already have SAML metadata downloaded from the "general" endpoint https://login.microsoftonline.com/[Unique_ID]/FederationMetadata/2007-06/FederationMetadata.xml

However, when I configure my application in AAD, it sets up a signing certificate for the application and there is another link to SAML metadata, which slightly differs from the first, "general", metadata:

  • The general one contains 3 signing certificates, while the concrete application-specific metadata contains just one: the certificate configured especially for the application on AAD side. The application-specific certificate in not any of the 3 certificates from the general metadata.
  • The general one is digitally signed, the specific one is not.
  • Both have the same Entity ID.

I am quite confused about this concept, I haven't seen it on any other IdP server yet. I have already realized I must use the application-specific metadata to configure my Service Party, otherwise the digital signature of SAML assertions will not be verified.

So, my questions are:

  • Why does AAD provides the option to have application-specific signing certificates and SAML metadata? Why can't I simply use the global metadata/certificates and have all assertions for all applications signed with the same certificate?
  • Is it somehow possible to disable this feature and only use the global metadata for all Service Parties? The benefit would be clear: having just one IdP metadata instead of N.
1
azure-active-directory

1 Answers

0
votes

Why does AAD provides the option to have application-specific signing certificates and SAML metadata?

One reason this is useful is that you control the certificate rollover. (Not all apps are "well-behaved" and deal correctly with planned certificate rollovers.)

Is it somehow possible to disable this feature and only use the global metadata for all Service Parties?

Sort of.

If you create a new App registration (as opposed to going via Enterprise apps > New app > Custom app), you can do SAML 2.0 against that app, with the details exposed in the "global" federation metadata.

The downside to this approach is that you won't get access to the Enterprise Apps > (app) > Single sign-on section, so you won't be able to do things like choose which attribute is used as the NameID, or have a UI interface to do claims customization (though you can still do custom claims mapping policies).