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:
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. 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. 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. 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. Unfortunately, supporting the CAS protocol capabilities in Shib will consume my available open source development time. I will continue to be vigilant on CAS mailing lists, but far less active if not completely inactive on development in the near future. Best wishes, M [1] http://svn.shibboleth.net/view/java-identity-provider/trunk/idp-cas-impl/src/main/java/net/shibboleth/idp/cas/ticket/SimpleTicketService.java?view=markup [2] http://svn.shibboleth.net/view/java-identity-provider/trunk/idp-cas-impl/src/main/java/net/shibboleth/idp/cas/flow/BuildProxyChainAction.java?view=markup -- 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
