A combined "saml-support" module has the following potential issues:
* "CAS Attributes via SAML1" really has little to do with "SAML support" in the sense of providing interoperability outside of CAS system components. For all intents and purposes it is an internal CAS implementation detail. It also is not required by or related to providing Google SAML2 support. * Mixing these two concerns will needlessly complicated the CAS server for deployers that only want one or the other, but not both. This is both a complexity issue and a security issue. * A "saml-support" module begs the question, "What exactly is SAML support?". SAML is a large and complicated spec with a variety of profiles, bindings, options, etc. "SAML support" is not sufficient to communicate clearly what the modules intent is, and would likely be the source of endless confusion. * Having focused modules with well defined boundaries is more consistent with the CAS project generally. Putting them in the same package is like mixing LDAP support with JDBC support. * Pragmatically it probably makes sense to just start with trying to pull one or the other into a separate module to assess the work required and some of these issues. Best, Bill On Tue, Jan 22, 2013 at 9:23 AM, Scott Battaglia <[email protected]> wrote: > +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 <[email protected]> > 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 [email protected] as: >> [email protected] >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
