Apereo CAS - SAML2 Metadata Query Protocol

This blog is managed and hosted on GitHub. If you wish to update the contents of this post or if you have found an inaccuracy and wish to make corrections, we recommend that you please submit a pull request to this repository.


Per-entity metadata allows CAS acting as a SAML2 identity provider to consume only metadata for specific service providers as needed instead of having to load the entire XML aggregate. Metadata is delivered through a protocol called MDQ (“Metadata Query” resulting in a significantly lower memory footprint in addition to quicker startup times by not having to verify the entirety of the XML aggregate at startup.

In this blog post, we will take a look at InCommon MDQ server and how Apereo CAS may be configured to fetch and validate service provider metadata on demand using MDQ and family.

Preview Phase
The signing certificate (public key) for the Technology Preview version of this service may be changed with little notice. The production public key and its certificate will be stable and long-lived.

Our starting position is based on:


Once you have configured CAS to act as a SAML2 identity provider, the following service definition can be a reasonable starting template for fetching service provider metadata from InCommon’s MDQ server:

  "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
  "serviceId" : ".+",
  "name" : "SAMLMDQ",
  "id" : 1,
  "requireSignedRoot": true,
  "evaluationOrder" : 1000,
  "metadataSignatureLocation": "file:/etc/cas/incommon-mdq.pem",
  "metadataLocation" : "http://mdq-preview.incommon.org/entities/{0}"

The serviceId field above indicates that all SAML2 service provider entity ids are recognized and accepted by CAS so long metadata associated with entity ids can be found and fetched from the MDQ server.

Evalaution Order
If you have more than one metadata provider, you will want to carefully examine the evaluationOrder of the above service definition to make sure it executes after all other metadata providers. If you do not do this, CAS will try to fetch your static entities from InCommon each time it is requested before falling back to your static metadata providers.

So if you could imagine that a service provider with the entity id of https://studypages.com/saml-sp sends an authentication request to CAS, the following picture is what you should expect:


Not the prettiest picture in the world for sure, and with a little bit of CSS magic it can be as glamorous as you could want.


I hope this review was of some help to you and I am sure that both this post as well as the functionality it attempts to explain can be improved in any number of ways. Please know that all other use cases, scenarios, features, and theories certainly are possible as well. Feel free to engage and contribute as best as you can.

Happy Coding,

Misagh Moayyed

Related Posts

CAS 6.2.0 RC4 Feature Release

...in which I present an overview of CAS 6.2.0 RC4 release.

CAS 6.2.0 RC3 Feature Release

...in which I present an overview of CAS 6.2.0 RC3 release.

Apereo CAS - Bootiful CAS Client

Easy to use CAS Client

CAS Vulnerability Disclosure

Disclosure of a security issue with the CAS software.

Checking Out Pull Requests Locally

Check out GitHub pull requests as local branches using a simple bash function.

CAS 6.2.0 RC2 Feature Release

...in which I present an overview of CAS 6.2.0 RC2 release.

Apereo CAS - Authentication Handler Resolution

Learn how to resolve and select authentication handlers based on configurable and flexible filtering criteria.

CAS Vulnerability Disclosure

Disclosure of a security issue with the CAS software.

Apereo CAS - SAML2 Metadata Overrides

Learn how to manage SAML2 service provider registrations in CAS and override metadata artifacts on a per-application basis.

Apereo CAS - Managing Configuration Metadata

Learn how to manage CAS configuration and properties using Spring Boot Configuration metadata.