Apereo CAS - SAML2 Metadata Query Protocol


Collaborate
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.

Overview

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:

Configuration

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:

image

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.

So…

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 Vulnerability Disclosure

Disclosure of a security issue with the CAS software.

CAS Multifactor Authentication with U2F and Bypass

A short walkthrough to demonstrate how one might turn on multifactor authentication with CAS using U2F and default bypass rule.

CAS Vulnerability Disclosure

Disclosure of a security issue with the CAS software.

CAS Release Notes Moved

CAS Release Notes are moved to the CAS site.

CAS 6.2.0 RC5 Feature Release

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

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.