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.
Our starting position is as follows:
6.5.x
11
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].identity-provider-url=https://${adfshost}/adfs/ls/
cas.authn.wsfed[0].identity-provider-identifier=http://${adfshost}/adfs/services/trust
cas.authn.wsfed[0].relying-party-identifier=urn:cas:test
cas.authn.wsfed[0].name=My ADFS Server
cas.authn.wsfed[0].id=myadfs
cas.authn.wsfed[0].identity-attribute=upn
cas.authn.wsfed[0].signing-certificate-resources=file:/etc/cas/config/adfs-signing.cer
A few tips for the enlightened:
adfhost
with your ADFS domain as appropriate.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-signing.cer
.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.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:
cas.authn.wsfed[0].auto-redirect-type=CLIENT
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:
cas.authn.wsfed[0].auto-redirect-type=SERVER
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:
cas.authn.wsfed[0].signing-certificate-resources=file:/etc/cas/config/adfs-signing.cer
Of course, it’s possible to use more than one:
cas.authn.wsfed[0].signing-certificate-resources=file:/etc/cas/config/adfs-signing-1.cer,\
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:
cas.authn.wsfed[0].signing-certificate-resources=https://${adfshost}/federationmetadata/2007-06/federationmetadata.xml
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,
Monday-Friday
9am-6pm, Central European Time
7am-1pm, U.S. Eastern Time
Monday-Friday
9am-6pm, Central European Time