Deployment SAML Certificate Changes

75 views
Skip to first unread message

Jeremiah Garmatter

unread,
Sep 9, 2020, 11:02:20 AM9/9/20
to CAS Community

Hello,

I am getting close to deployment of my CAS 6.2.1 instance. I would like some advice on updating the idp-encryption{.crt,.key}, idp-metadata, and the idp-signing{.crt,.key} for my production servers.

I have two servers (we'll call them server-1.onu.edu and server-2.onu.edu) that I would like to host as a HA cluster. I will be using DNS to send requests made to server.onu.edu to both server-1.onu.edu and server-2.onu.edu.

My questions are, how should I generate the certificates and metadata for deployment to server.onu.edu? Previously, I let CAS auto generate the certificates and metadata so I do not know the process. Would I need subject alt names of server.onu.edu, server-1.onu.edu and server-2.onu.edu  or would only server.onu.edu suffice? Are there any specific fields I should set in my new certificate? I noticed the auto-generated .crt files have a SAN of DNS name and URI to server1.onu.edu/idp/metadata, how can I add a URI to my custom certificate and should I include both servers' metadata endpoints in it or just server.onu.edu's?

I know there is a lot there, I appreciate you taking the time to read through it.

Jeremiah Garmatter

unread,
Sep 10, 2020, 12:21:39 PM9/10/20
to CAS Community
Hello all,

Please does anyone have familiarity with the SAML certificate and metadata generation process? Specifically how to create them for a HA deployment where users will sign in to server.onu.edu and authentication will be performed on either server-1.onu.edu or server-2.onu.edu?

David Curry

unread,
Sep 10, 2020, 1:30:40 PM9/10/20
to CAS Community
In our case, we run five servers (cas-srv01, cas-srv02, etc.) behind an F5 load balancer. The VIP on the F5 identifies as "sso.newschool.edu". We use one "regular" SSL/TLS certificate for "sso.newschool.edu" and install it both on the F5 AND on each of the CAS servers (in the Tomcat keystore) so that every individual CAS server identifies itself as "sso.newschool.edu" as well. Our SAML2 metadata also identifies itself as "sso.newschool.edu," and is installed on all five servers.  So the only server name the outside world ever sees is "sso.newschool.edu" -- the individual server names are only used internally.*  

To handle getting the metadata files to be the same on all the servers, the process is basically:
  1. Configure the CAS server to be a SAML2 IdP (cas.properties)
  2. Start ONE of the servers (it doesn't matter which one). This will create a bunch of files in /etc/cas/saml whose names all start with "idp-" (idp-encryption.crt, idp-encryption.key, idp-metadata.xml, idp-signing.crt, idp-signing.key).
  3. Shut the server back down and COPY those files to your overlay so that every time you rebuild your server, those files will be included in the installable package.
  4. Install the package (with the idp-* files) on all your servers.
Note that, unless you're using a distributed database of some sort to store your SP metadata files, you will also need to make sure that each time you set up a new client (SP), you copy its metadata file to /etc/cas/saml/metadata/ on all of your servers, or you'll get weird behavior depending on which server they're talking to.

You can find some more detail here: https://dacurry-tns.github.io/deploying-apereo-cas/building_server_saml_overview.html but realize that this was written for CAS 5.x (with Maven overlay instead of Gradle) so you'll have to adapt it to CAS 6.x.

--Dave

* I lied above about the certificate. We also use MongoDB as our service registry, and MongoDB talks using SSL/TLS as well. We used to use a self-signed certificate for this, but at one time we had that certificate expire on us and nobody noticed -- people were still able to log in, but adding new services didn't behave correctly because the MongoDBs were not replicating. So the last time we renewed the "sso.newschool.edu" certificate we added all the individual server names to it as Subject Alternative Names and now we use that one certificate for everything. This is NOT required, but it's easier to manage.

--

DAVID A. CURRY, CISSP
DIRECTOR • INFORMATION SECURITY & PRIVACY
THE NEW SCHOOL  INFORMATION TECHNOLOGY

71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003
+1 646 909-4728david...@newschool.edu



--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/0460dd87-23e5-4fe0-b6b6-8da3afe6f841n%40apereo.org.

Jeremiah Garmatter

unread,
Sep 11, 2020, 8:10:00 AM9/11/20
to CAS Community
David,

Thank you for the reply. I ended up using an ssl/tls cert containing each of the names of the server for general browser security. I realized the issue I was having was due to the generated SAML certs and metadata being inconsistent across each server. Your advice on starting up one server and copying the idp-* files to the other got me up and running.

Have a great weekend!
Reply all
Reply to author
Forward
0 new messages