It's been six years, and to be honest I'm a bit surprised at how much pickup RubyCAS has received. Then again maybe I shouldn't be. There's a definite need for centralized, institutional web single sign on, and RubyCAS fills that niche nicely. At the time when I first released RubyCAS-Sever, the only real alternative was Jasig's Java-based server, whose requisite infrastructure (Java servlet container, XML files galore, and all that) was overkill for the majority of potential CAS deployers. It was also obnoxiously hard to customize -- not the Jasig folk's fault, just part and parcel of the joys of the Java ecosystem. Maybe it's no surprise then that a lot of devs and admins opted for RubyCAS, which was designed from the start to be easy to install and customize.
Unfortunately lately I haven't been able to adequately respond to the growing interest by the community to move RubyCAS-Server forward. Fortunately a number of members of that community have stepped up and volunteered to at least partially take over maintainer duties. Matt Campbell took over management of RubyCAS-Client last year, and this has worked out very well. A number of past contributors are now volunteering to help out with the Server side of things. Tyler Pickett (
https://github.com/tpickett66) is spearheading the effort on multiple fronts, dealing with some much needed refactoring, text encoding issues, and compatibility with newer ActiveRecord/Support libs. There are a bunch of new ideas on the horizon too, and I'm hoping that with the new, bigger team of maintainers, we will see those merged in to the Server sooner rather than later.
I'm hoping too that this bigger group of contributors can keep focused on what (I think) made RubyCAS successful in the first place:
- RubyCAS-Server should be easy to install and configure.
If the "INSTALLATION" section of the README reads like a novel or requires esoteric knowledge, we're doing something wrong. Getting a basic version of the original rubycas-server up and running required little more than two lines on the terminal (`gem install rubycas-server` followed by just `rubycas-server`). It's gotten a bit more complicated since then, but I'd like to stick to this simplicity as much as possible. Sure, more advanced deployments will demand a lot more work from the user, but you should have to know next to nothing about the Ruby ecosystem to get a basic server up and running.
- RubyCAS-Server should be easy to customize.
Small things -- like switching your backend authenticator, or changing the theme -- should be easy. Bigger, more complicated things -- like writing a custom authenticator or a custom login form -- can be more harder. Few things make me wonder about the author's judgement than APIs or tools that make doing simple things really complicated (I'm looking at you, Java). I'm not sure how well RubyCAS-Server has stuck to this principle -- some things are harder than they should be -- but lets at least aim for this.
- RubyCAS-Server should be conceptually easy to understand, at least incrementally so.
There are aspects of the CAS protocol that will easily give you a migraine. Proxy ticketing, for example, is hard to get one's head around, and I think this is why few people use it. But that's probably okay, because you don't need to understand proxy ticketing to get some basic useful functionality out of CAS. There's been some push to get stuff like OpenID and OmniAuth integrated into RubyCAS. I've been a bit weary of this because both of these technologies are conceptually thick. Actually, OmniAuth isn't all that complicated (if you can understand CAS you can probably understand OmniAuth), but mixing OmniAuth's model and vocabulary mixed in with RubyCAS' has the potential to make for some thick conceptual soup. I'm not saying lets not do it. Just, lets proceed with caution.
I think that's about it. These are not commandments... probably not even principles. Just a couple of things to keep in mind while we move RubyCAS forward.
Thanks guys for your continued willingness to contribute back,
Matt.