Apereo CAS Delegated Authentication with ADFS

Posted by Misagh Moayyed on January 12, 2022 · 6 mins read ·

The integration between the CAS Server and ADFS delegates user authentication from CAS Server to ADFS, making CAS Server an ADFS client. Delegation, of course, is just a fancy word that ultimately means, whether automatically or at the click of a button, the browser is expected to redirect the user to the appropriate ADFS endpoint, and on the return trip back, CAS is tasked to parse the response and extract claims, etc to establish an authentication session, issue tickets, etc. In other words, in delegated scenarios, the main identity provider is an external system such as ADFS in this case and CAS simply begins to act as a client or proxy in between.

Usage Warning
If you are trying to figure how you may log into ADFS while CAS plays the role of a SAML2 identity provider, you are in the wrong place. Please read this post instead.

Our starting position is as follows:


Once you have included the property extension module in your build per the documentation page, the following settings should instruct CAS to hand off authentication to ADFS:

cas.authn.wsfed[0].name=My ADFS Server

A few tips for the enlightened:

  • Surely, swap out adfhost with your ADFS domain as appropriate.
  • Remember to register CAS as a client of ADFS by setting up a relying party trust under the id urn:cas:test. You can choose any identifier you prefer, so long as CAS and ADFS both agree to use the same value. If you make changes, please be generous and share the value with both systems.
  • ADFS tends to sign responses using a signing certificate. The certificate will need to be obtained and shared with the CAS server with you physically defining its home and sharing that path with CAS, as is done in my example above with adfs-signing.cer.
  • Of course, CAS somehow needs to figure out the authenticated username from the ADFS-produced response. To do this, it tends to look at a specific claim within that response typically released as upn. That is to say, you need to ensure ADFS is releasing this attribute (or anything else you prefer) to CAS and then ensure CAS is using the same claim name when it begins to do its extraction magic.

Auto Redirection

The above configuration by default allows the user to select the ADFS identity provider manually from the CAS login page:

It is possible to also instruct CAS to automatically redirect to ADFS. The browser could be instructed to execute the redirect, allowing the user the visibility to see the redirect with a little bit of visual clue and instructive text, i.e. Please wait while we redirect you…. This option can be achieved by the following setting:


The opposite is also possible, where CAS is instructed to automatically redirect to ADFS on the server-side, thereby making itself completely invisible to the enduser. This option can be achieved by the following setting:


Assertion Signature Validation

The validity of ADFS-issued assertions is verified using the provided signing certificates which one may obtain directly from the ADFS management console and instruct CAS to use them:


Of course, it’s possible to use more than one:

  file:/etc/cas/config/adfs-signing-2.cer, file:/etc/cas/config/adfs-signing-3.cer

In advanced scenarios, you may also allow CAS to obtain the signing certificate directly from the federation metadata thereby removing the need to manually replace certificates once they are rotated by ADFS:


Need Help?

If you have questions about the contents and the topic of this blog post, or if you need additional guidance and support, feel free to send us a note and ask about consulting and support services.


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 feel free to engage and contribute as best as you can.

Happy Coding,

Misagh Moayyed