Before I complete a deployment, can I get a sanity check of my architecture plan?

[Joe Gullo]

I'm a sysadmin with no spring/java/cas experience, but I've been tasked with taking a cas instance deployed by a vendor in ~2014 and bringing it up to date with modern cas.  I've read the docs extensively, but I'm still feeling like I may be making structural mistakes that I'd like someone with more experienced eyes to consider.

Presently, I'm working with 2 individual servers, one with cas configserver and cas management server, then another 1 (which will ultimately become one of many) cas server.  I am deploying all of them from initializr.  The thought was that the configserver and management server are on their own system and the main cas servers will talk to that.  Presently, they are each operating as their own service under tomcat under their own ports.

The config server currently is presenting 4 profiles which I've separated into their own "application-<profile>.properties" on the cas config server.  Those are "common" "ldap" "dev" and "prod".  Then, in the individual bootstrap.properties files that would go into building the client overlay, I can specify which profiles to use.  This seems to be working well; I'll change the bootstrap.properties and redeploy and I see the changes.

For now, for the dev build out, we're using JMS ticket registry and I'd like to use JSON for my service registry.  Eventually I'd like the json repository to be located on the config server and accessed remotely from the front ends, but for now, it is on the front end configured with "file://etc/cas/services-repo".  In testing, the only service I'm adding now is the management server.  I haven't gotten to the point of adding actual services yet.

Am I approaching this in a sane way?  It seems to be working thus far, but the criticality of the system and my unfamiliarity with this ecosystem makes me want a second opinion.

[Ray Bon]

Joe,

The key is small steps. Make a change and test. And of course, once it is working as expected, commit to your git repo.

For some aspects of Cas, you can create dummy services [in the service registry]. Cas will do its part for authentication and redirect, which will result in a 404. With the right logging settings you can see what cas is doing; such as getting user attributes, checking  service authorizations, multifactor, etc. Even single logout can be observed (cas can show which services are being sent the logout request).

There are a couple of guides available. Although they are for prior version, they will show you steps taken.

https://paulchauvet.github.io/deploying-cas/

https://dacurry-tns.github.io/deploying-apereo-cas/introduction_overview.html

There are management endpoints that may also prove useful.

https://apereo.github.io/cas/6.5.x/monitoring/Monitoring-Statistics.html

This blog may also be helpful

https://fawnoos.com/blog/

Ray

On Tue, 2022-05-31 at 14:59 -0700, Joe Gullo wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@uvic.ca

I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands, and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day.

[Joe Gullo]

Is my understanding correct that the management server overlay goes on the "config server" host, or does it go on each of the "cas-overlay" front ends?  My thought was that it was the hub component of a hub-and-spoke system, but I didn't see that explicitly laid out, or part of a best practices configuration.

[Ray Bon]

Cas-management can be placed where you like. It is a [n optional] web application for managing cas services.

It is fine on the config server; may make lock down config for these two applications a bit simpler.

Ray

[Ray Bon]

Let me clarify. That should read

managing cas service registry.

It does not manage cas nor any application.

Ray

On Wed, 2022-06-01 at 19:38 +0000, Ray Bon wrote:

Notice: This message was sent from outside the University of Victoria email system but is claiming to be from UVic. Please be cautious with links, attachments, and sensitive information.