I'll put some "fuel to the fire" :-)) CAS is excellent software, but it's aging (naturally) and with the modern authentication system requirements like 2fa, multi-stage interactive authentication flows, non-interactive service-to-service authentication, etc. it's becoming kind of difficult to extend without some hackery. Sure, the SWF facilitates extension, but the the current monolithic nature of the CAS API /CASimpl which tightly couples authentication and SSO/protocol concepts does not allow for clean, pluggable customizations without some complex hackery (for example, custom code avoiding CASimpl and directly calling its internal components, fake TGT creation and some "dance" to simulate multi-staged authentication transactions, etc. )
IMHO, CAS.next is kind of due, naturally as a software evolution. The most welcomed architecture would be to decouple authentication and protocol/SSO subsystems, with a set of cohesive micro-services/APIs, authentication transaction concept, as well as employment of a modern implementation architectures like pipes-and-filters, etc. And I totally agree that such re-design would not be possible without some solid financial sponsorship. But with such sponsorship and interest from the community - why not? :-)) Happy Thanksgiving, my USA friends! Cheers, Dmitriy. Sent from my iPhone > On Nov 27, 2014, at 00:49, Misagh Moayyed <mmoay...@unicon.net> wrote: > > Apologies in advance for the rant: > > I am not sure face-to-face meetings, unless if you count google hangouts, > would be a practical solution. Our volunteering is just affected by so many > things that really make this an unviable option. I would however welcome > weekly (or even biweekly) developer calls to review scope, planning and > roadmap for the project. This seems like our best bet moving forward and we > just have to come up with a schedule that works for the majority. > > From a pure technical point of view, I’d welcome any and all design > discussions/suggestions around the roadmap of the project. Using > spring-webflow to model the authentication sequence seems like a reasonable > approach (although before fully moving in that direction I suppose we really > need evaluate the roadmap for SWF and see where it’s headed. Discussions > around SWF3 date back to 2010 which is somewhat alarming). Removing > configuration overhead and identifying knobs and settings that are no longer > actively pursued are most welcome. Decoupling CAS to resolve around a set of > small microservices (which seems to be the buzz word these days) is also > perfectly sound idea. > > From a functional/practical point of view, I am not sure we can, or even need > to afford changes of that magnitude in one shot. Big design only works if we > can afford the time, patience and energy to go through with it and it’s > obvious at least to me that we can’t budget it that way. While it’s perfectly > fine to ponder, elaborate, document and discuss design points and come up > with a big picture, it’s impractical and frankly unnecessary to implement at > this point. I am not sure, personally, if I feel the same pain points as you > do. Sure, there are a few things that could be improved but I am struggling > to find a practical rationale and use case that would actually benefit our > adopters and community through big change. Maybe I am ignorant, but I can’t > find any that would justify this. It’s true that support for multiple > protocols could be vastly improved and rewritten, but I am not sure there is > a demand for this big change or that we have use cases and requirements > available to us that are just presently impossible or super painful to > implement. At least not in one big swoop. I would much prefer if we came up > with a design and a rationale behind that design based on actual use cases > and requirements demanded by the community, and then slowly but surely march > towards the goal. It may seem wasteful upfront, but it’s also unfair to ask > any individual to go off with a design doc and come back with 50000 LOC and a > shiny new system. Now, don’t get me wrong; I would love to spend time to > figure out what CAS NextGen (that just sounded way too commercial, didn’t > it?!) would look like but I do also realize that at this point, with our > budget, time, effort and level of collaboration amongst other obligations > that time spent would mostly just amount to a theoretical exercise. > > Of course, I could be persuaded otherwise. > > Now, I am sure (and I have been guilty of this myself) that we could > communicate our task list and ideas better on the list to give everyone an > overview of and a deep-dive into what we’d each like to work on and what > possible solutions for those might exist, before the presentation of the code > for the ideas! This definitely would be more collaborative, and as Scott > says, would help with the code review process as well. It’s all about giving, > sharing and receiving :) If we all synchronize our watches on the same of > features and changes, it would definitely be progress in the right direction. > I have personally tried to use our issue tracking system to document ideas > and features herw and there and have been using the list less, but I could > change. > > Have a great thanksgiving weekend, everyone. > > > From: Jérôme LELEU [mailto:lel...@gmail.com] > Sent: Friday, November 21, 2014 7:36 AM > To: cas-dev@lists.jasig.org > Subject: Re: [cas-dev] CAS design perspective from the outside > > Hi, > > 2014-11-20 16:20 GMT+01:00 Marvin Addison <marvin.addi...@gmail.com>: > I've been wanting to do some big design work on this project for years, and I > finally got my chance: by contributing CAS protocol support to Shib IdPv3. I > am very pleased with the end result and it's worth noting a few broad design > points that are worth considering for Jasig/Apereo CAS: > > Contributing a full SAML support to CAS server would have been a great design > work as well ;-) > > > 1. Everything is a flow. I proposed this a while back for Jasig CAS and got a > lukewarm response, but I was able to work though all the details to produce a > clear, testable, and extensible implementation. Moreover the experience has > proved that Spring Webflow is an excellent facility for modeling arbitrary > protocol logic for a multi-protocol SSO product. > > I guess we all agree on this. > > > 2. Small set of simple core services, e.g. storage, session, messaging, on > top of which the protocol logic is built. You can see how I leveraged a > stupid simple storage service to model proxy chains [1,2] while avoiding the > huge headaches of Java serialization that have plagued us for years. > > I'm not sure to follow you here. We have used Hibernate for DB persistence > and Kryo also for Memcached (and truly it has caused problems but upgrading > Kryo would help us a lot). A very promising direction we have taken recently > is to use more and more JSON serialization. > > > 3. Configuration points that matter. I think CAS has become too configurable > out of the box. Service ticket usage count is an excellent example of a > configuration point that no one uses, but there are countless others that > have marginal value. We invite support headaches and increase development > costs by allowing configuration in most if not all components. Reduce and > simplify. > > Certainly, so let's remove useless features. I'm sure a PR removing ticket > usage count would have been successfully +1. > > > My sense is that we're spending inordinate amounts of time discussing > relatively minor changes, and anything that touches on design becomes mired > in endless discussion. Here's a few current or recent issues that I thought > were symptomatic: > > https://github.com/Jasig/cas/issues/669 > https://github.com/Jasig/cas/pull/730 > https://github.com/Jasig/cas/issues/695 > > Extensive discussion for small changes is wasteful; we're a small team and we > don't have the resources to suffer inefficiency. > > Spending BIG time on BIG changes, on the other hand, is healthy and > productive. I encourage some BIG design work in the near future, and > face-to-face meetings might be the most productive. A recent cas-pmc thread > suggests Apereo is willing to support F2F meetings, so it seems like an > opportune time to consider some serious in-person design work. > > Yes, we must be efficient and spend most of our times on big changes. I would > not say that these discussions you mentioned are useless, it helps us update > our thoughts and reflection. > > But we could have done better because we really need design meetings to > synchronize together. But because of our time zones and constraints, it has > always been difficult. With Scott trapped at work and me in France, it's > pretty difficult to find the right schedule and I'm willing to do that during > week-ends if it's possible. Moving to US regularly for design meetings is not > possible for me, but I should come to next Apereo conference: I don't know > how other contributors feel to meet in US: is it something easy for them? > Because we can setup video conference: not perfect, but close to a > face-to-face. > > > Your post sounds negative, but it's not how I feel. Involvment in open source > is not easy unless you are alone on your project and if we don't have made > major step lately, I think it was interesting small ones at least. > > > Thanks for sharing your thoughts. > > Best regards, > Jérôme > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > mmoay...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > dkopyle...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
