+1 also for just keeping SAML support in one package. Logout is a little more embedded to attempt to pull it out. Not sure if it would be worth the effort unless we did an actual refactor. I'm on the fence on disabled/enabled by default. We already make it pretty easy to disable via cas.properties (at least according to the cas.properties file) and we do get a decent amount of support questions on it which would indicate usage.
On Tue, Jan 22, 2013 at 9:18 AM, Marvin Addison <marvin.addi...@gmail.com>wrote: > > Since Google SAML2 and CAS Attributes SAML1 really are quite different > > animals, it probably is worth thinking about two separate modules. > > Perhaps something like this: > > * cas-server-support-google-saml2 > > * cas-server-support-attributes-saml1 > > I think there's negligible value for the effort of splitting into two > modules. While the features are likely separate in terms of > consumption by deployers, they _should_ have exactly the same > dependencies on OpenSAML. +1 for Jérôme's initial suggestion of a > single cas-server-support-saml module. > > I'm ambivalent on pulling out the single sign-out features. I would > favor it only if it makes sense in terms of dependencies and effort, > not otherwise. I'm additionally ambivalent on disabling by default. I > do, however, think it remains to be demonstrated with evidence (vote, > folks speaking up) about the extent of use of single sign-out. Judging > by amount of questions on cas-user, it's a widely used feature; > percent use remains to be determined. > > M > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > 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
