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! On Thursday, September 10, 2020 at 1:30:40 PM UTC-4 [email protected] wrote: > 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-4728 <(646)%20909-4728> • [email protected] > > > On Thu, Sep 10, 2020 at 12:21 PM Jeremiah Garmatter <[email protected]> > wrote: > >> 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? >> >> On Wednesday, September 9, 2020 at 11:02:20 AM UTC-4 Jeremiah Garmatter >> wrote: >> >>> >>> 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. >>> >> -- >> - 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 [email protected]. >> 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 >> >> <https://groups.google.com/a/apereo.org/d/msgid/cas-user/0460dd87-23e5-4fe0-b6b6-8da3afe6f841n%40apereo.org?utm_medium=email&utm_source=footer> >> . >> > -- - 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/0f6b966a-076c-4ff8-9871-9f271b21a480n%40apereo.org.
