The future of RubyCAS

607 views
Skip to first unread message

Matt Zukowski

unread,
Nov 21, 2012, 2:03:09 PM11/21/12
to rubycas...@googlegroups.com
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.

t.pickett66

unread,
Nov 28, 2012, 9:18:03 AM11/28/12
to rubycas...@googlegroups.com
Matt,

Thank you for all of the hard work you've put into this project over the last six years, I know it can't be easy to relinquish some control over a project you've worked so hard on for so long.  I think the ideas you've put forth regarding the future of the project are things that everyone will agree are worthy goals, in fact I'd be happy to adopt them as guiding principals for the community. To those ends I have a few ideas that have been bouncing around in my head and I have experimented with a bit that I'd like to share with the community at large.

The first thing I think we can do to simplify our product and increase customizability is to split the interesting core logic into a separate gem that the server depends on similar to what Matt Campbell has started with the client. At first this may seem like a step in the opposite direction but please bear with me for a moment. There are several items that this would actually end up simplifying as well as novel applications that would be enabled by this approach. First it would simplify the existing Sinatra app so that it only deals with the actual presentation and the bits of logic governing it. Second it would allow us to target a Rails engine or perhaps some other as yet unknown framework simultaneously with ease. This increased abstraction in the web layer will then present a clear, distilled picture of the protocol without getting bogged down in the implementation details. Then when they're ready they can dive down into the core modules to see exactly how we have solved the problems encountered in the construction of the app. There has also been some discussion regarding a move to using DataMapper (I do have some reservations about DM but we can discuss that in another thread) for persistance flexibility, I think this transition would fit nicely with the modularization of the project.  I'll post a quick Gist later to give everyone a better idea of how I think some of this can be accomplished and hopefully spark a discussion of the ideas presented.

Tyler

Andreas Haller

unread,
Jun 5, 2013, 1:07:04 PM6/5/13
to rubycas...@googlegroups.com
Hi

i just discovered the rubycas-server and rubycas-server-core on Github. Especially rubycas-server-core interests me, because rubycas-server looks a little bloated. So i think i really like what you are doing with rubycas-server-core. Could explain a little more about your goals with rubycas-server-core, maybe in it's README? Could you roughly describe how you want people to use it (in a Rack/Sinatra app and maybe where people could help?

Thanks for all your work on this project!

Andreas
Reply all
Reply to author
Forward
0 new messages