Skip to main content

Migrate to InCommon MDQ Apereo CAS Server

InCommon is a widely used federation in Higher Education. They have recently created the Metadata Distribution Query service and protocol (MDQ). The benefits of this new service are numerous. At Unicon we’ve seen clients experience half the memory usage in popular open source Single Sign On applications such as Shibboleth Identity Provider and Apereo CAS server after switching. 

On Monday March 1st, 2021 InCommon  changed the url for the InCommon aggregate file, as a result current configuration that downloads the file from a remote url and checks the signature won’t work without a change. While you can continue to use the url download functionality for up to 5 years, we recommend switching to the InCommon MDQ service. For more information please see: https://spaces.at.internet2.edu/display/MDQ/migrate-to-mdq. In this article we’ll cover switching your Apereo CAS server to use the InCommon MDQ service.

Configuration of InCommon MDQ in Apereo CAS Server

CAS_logo-200First you’ll need to navigate to InCommon’s website and download the metadata signature for MDQ in production. As of this article’s writing it’s available here: https://spaces.at.internet2.edu/display/MDQ/production+metadata+signing+key. Once you have that certificate we’re ready to configure your Apereo CAS server.

Navigate to your Apereo CAS server’s Service Registry storage location. This guide will show an example using the file based storage for the CAS JSON service definitions. If you’ve configured a different Server Registry storage type and location then you’ll need to find the InCommon definition(s) there. The configuration itself should be the same.

Once in your InCommon JSON definition, we’ll only need to change the metadataUrl and the metadataSignatureLocation configuration and an example is provided below. Note that the metadataUrl must be exactly as shown below, but the metadataSignatureLocation should point to the MDQ InCommon signing certificate downloaded in the step above.

{
  "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
  "serviceId" : ".+",
  "id" : "456",
  "name" : "InCommon_SP",
  "description" : "InCommon",
  "evaluationOrder" : "1400",
  "metadataLocation" : "https://mdq.incommon.org/entities/{0}",
  "metadataSignatureLocation" : "file:/etc/cas/services/sp-metadata/inc-md-cert-mdq.pem",
  "attributeReleasePolicy": {
"@class": "org.apereo.cas.services.ChainingAttributeReleasePolicy",
"policies": [ "java.util.ArrayList", [
    {"@class": "org.apereo.cas.support.saml.services.EduPersonTargetedIdAttributeReleasePolicy",
        "salt": "mysalthere",
        "attribute": "uid"
    },
    {"@class": "org.apereo.cas.support.saml.services.InCommonRSAttributeReleasePolicy"},
    {"@class": "org.apereo.cas.support.saml.services.RefedsRSAttributeReleasePolicy" ]]
  }
}

After making the change Apereo CAS server should reload the service definition automatically (by default after 2 minutes) and you should be able to test an InCommon service.

Thanks for reading and I hope this proves useful to you. If you have any questions or additional needs reach out to Unicon! We’re happy to help and provide a full set of services and support around Apereo CAS server.

Paul Spaude

Paul Spaude

Senior Software Engineer
Paul Spaude is a Senior Software Engineer and Identity and Access Management (IAM) Consultant for Unicon Inc., a leading provider of IT consulting, services, and support for education technology. Mr. Spaude has extensive experience in creating, designing, and improving software solutions and services with an emphasis on IAM web development and systems integration. He has deployed and supported web Single Sign on systems such as Shibboleth IdP and SP, Apereo CAS server, ADFS, and Azure AD SSO. He’s also deployed Group Management systems such as Internet2’s Grouper, and Identity Management systems such as midPoint and Okta.