Migrating from CAS 3.5.2 to CAS 6.1.0

[The Jej]

Hello everyone, 

I'm planning to upgrade our (very) old CAS 3.5.2 to the lastest version 6.1.x 

Since 3.5.x a lot have changed. I managed to make a developement version working but I'm a little bit confused on some aspects.

Before thinking of pushing a version to production, I would like to make sure to have covered all my needs.

Here is a quick summary of how we're using CAS:

We're using CAS for students to access our different applications. Most of the time we only use 1 server.

They're is 1 month were we are publishing some competitive examination results and during that period our host adds a second CAS server. Load balancing is managed by a F5 loadbalancer.

our current configuration uses oracle to retrive user/password and to share tickets (TGT / ST ...)

What I've done so far with CAS 6.1.x :

- Getting default overlay to work :)

- Configuring my database witch is oracle (using cas.authn.jdbc.query[0].x config) to retreive login/password

- Enabled JSON services and creating a service for my apps

- Using custom theme for my services

I keep reading as much as I can on CAS and common uses, so I have come with several questions:

1. Ticket registry management:

If I understand correctly, if I want to make things work like we have today, I have to configure a jpa ticket registry.

I've read that a lot of cas users are using hazelcast for ticket registry. 

Is it a better way to go ? If so, I have to install hazelcast IMDG on the server itself ?

2. Performance optimization: Is there common optimization params that can be set to optimize database access ?

3. For production, is it prefered to use an embedded tomcat or a generated cas.war deployed on a tomcat instance ?

4. Do I have miss something important ? :)

Thanks for your help !

Jeremy

[Ray Bon]

Jeremy,

1. If you are using a database for username/password, that would be fine for ticket registry. Hazelcast is easy because it comes with CAS (when dependency and config are present), no need to install a separate server (unless you want). If you are periodically increasing you CAS server count, Hazelcast would have to be set for auto discovery of its peers.

2. I have not used database.

3. I use stand alone tomcat because that is the way things were done when I arrived.

Ray

-- 
Ray Bon
Programmer analyst
Development Services, University Systems
2507218831 | CLE 019 | rb...@uvic.ca

[David Curry]

1. If you're only using a single server, then you don't need a ticket registry at all beyond the in-memory one that CAS uses by default. If you're using multiple servers, then the ticket registry lets the servers cross-validate each others' issued tickets. But there is no need for this registry to reside on disk, so disk-based databases are kind of overkill for the problem.

Up until this morning, we were using MongoDB for our ticket registry (because it had replication and we were already using it for the service registry). Yeah, it worked just fine most of the time. But we had problems last fall when class registration was going on (lots and lots of people logging in at the second the window opens). People would log in and get their TGT, but then when the target application came back to validate the TGT it would fail, because the data hadn't made it to disk yet. This could "probably" be fixed with some advanced performance tuning of our MongoDB setup, but we don't have a MongoDB wizard, and Mongo's documentation of the topic frankly sucks.

So instead, based on the experiences of some other members of this group with volumes much, much higher than ours, we are as of this morning using Hazelcast on our production CAS servers (we've been running it for a few weeks in test). It was dead simple to configure across our five CAS servers, and so far anyway, it seems to be working fine. Registration opens in a few weeks, so we'll know more then, but we're anticipating that it will be better.

2. For MongDB most of these settings are on the MongoDB side (in its config file), not the CAS side. But it may be different for other databases.

3. I don't think there's a right answer here; both methods work fine, and people are doing both today. IMHO external Tomcat is better because you get more control over the configuration and you can deploy multiple apps (CAS and CAS-mamagement, for example) to the same server. But there are good arguments for the embedded option, too. Use whichever way you're more comfortable with, or fits into your system/application management processes better.

--Dave

--

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

71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003
+1 212 229-5300 x4728 • david...@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/CAEhrmrwcYdNLq4g1zFjggkEH_8mFkiAA4FP0FKD4E41PmaKjnQ%40mail.gmail.com.

[The Jej]

Thanks for your answers, 

I'm gonna try both solution for tickets and will decide after that.

Have a nice day !

Jeremy

[Paul Bransford]

We use CAS 5.2.x with Oracle via JDBC query/attributes. Sounds very similar :)

In my case, I went with a 3-node redis/sentinel cluster for my ticket registry, as I am the only one maintaining this deployment and I'm completely unfamiliar with hazelcast. Redis, with sentinel and an *odd number* of nodes, is a solid HA-capable solution.

I build a war that I run in a jetty docker container, personally. Embedding the server application just seems icky to me. This tightly couples that with the build artifact of CAS, which means you couldn't touch one without touching the other.

[The Jej]

Hi Paul,

thanks for your input. It's very informative. 

I haven't got a lot of time last days to try out different ticket registry but I'll check redis / sentinel too.

I'm also agree about embedding the server, I prefer to have server and app separated.

Thanks

--

- 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/6519df53-f26a-45ae-8820-03885fda06ab%40apereo.org.