cc'ing cas-appsec-public to pull in some of our more security minded colleagues into this discussion.
My response to this issue is partly the result of past personal experience being accountable for a fairly large CAS deployment, and more recent experience reviewing numerous other CAS deployments via Unicon clients. I've seen everything from "test" config deployed to "prod" to folks simply leaving SimpleTestAuthenticationHandler in the chain. People aren't perfect...mistakes will happen, and I think the project team has some responsibility to help minimize the risk. My main objection is with the current practice of leaving the SimpleTestAuthenticationHandler available for execution in a production build. I'd rather see it excluded by default to minimize the risk of misconfiguration. Seems like we have two paths/requirements: 1) Reduce the risk of misconfiguration in production. 2) Preserve the ability to quickly get a integration/testing/demoing cas server running. Perhaps we could add a test-cas.war with the SimpleTestAuthenticationHandler enabled to the build to preserve ease of integration/testing/demoing. And remove SimpleTestAuthentiationHandler from the default cas.war that folks are overlaying for their production deployment. Thoughts? Best, Bill On Thu, Apr 4, 2013 at 11:29 AM, Misagh Moayyed <[email protected]> wrote: > Team, > There is a pending pull [1] that proposes the > SimpleTestAuthenticationHandler be renamed to something that is bit more > descriptive. The motivation for the pull/JIRA is not only to communicate > the actual purpose of the handler, but hopefully in doing that, it would > be clearer that the handler should never be used in production. > > IMO, ideally, the objective might be to not even allow folks to use the > handler at all and simply keep it for internal dev and testing purposes. > > There have a been a number of suggestions on the pull that I'd like to > summarize here first and see if we can all reach an agreement on the most > appropriate option: > > 1. Rename this default handler to > MatchingUsernamePasswordAuthenticationHandler: communicates intent, but > loses sight that this is a test handler not be used > 2. Display a warning on the login page much the http/nonsecure warning > that the handler is only for testing purposes and should never be used in > production > 3. Figure out a way to do away with the handler in the final war: one > possible idea might to be force users to explicitly configure handlers and > by default, CAS would ship with no handlers at all? > > -Misagh > > [1] https://github.com/Jasig/cas/pull/215 > > -- > 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
