Proposals to mitigate security risks

Identifier	Scope	Proposal	Development complexity	Efficiency	Backward compatible	Target
SEC_1	Service	By default, we could define a service which does not allow HTTP in its pattern matching, for the in-memory services registry (deployerConfigContext.xml file)	Easy	Not very useful in practice as almost all CAS deployers use their own services registry in production. But it’s a good way to make people aware of the “HTTP risk”	Yes in most cases as almost nobody uses the in-memory services registry in production	4.0 ?
SEC_2a	Service	Add a allowHttpForService flag for the CAS server to define if the service can be in HTTP (/login, /validate, /serviceValidate urls) : false by default	Medium	Useful to make people aware of the fact they need to setup something to allow HTTP services	No, already existing HTTP services could not work any more without enabling this flag
SEC_2b	Service	Reuse the secure flag already used by the proxy handler to define if the service can be in HTTP (/login, /validate, /serviceValidate urls)	Medium	Useful to make people aware of the fact they need to setup something to allow HTTP services	No, already existing HTTP services could not work any more without enabling this flag
SEC_3	Proxy	Change the default value of the allowToProxy flag to false	Easy	Useful. It would avoid any security issue with proxy by disabling it by default	Yes in most cases. Services are already defined with their allowToProxy flag. Only new deployement would be impacted or very specific mechanism using the default allowToProxy flag value	4.0 ?
SEC_4	Proxy	Check proxy callback urls against the services registry	Medium	Useful. If a default truststore is used (all certificates trusted), it would avoid any unexpected proxy callback	No, it can break proxies which are not declared in the services registry (though, services definition should match proxy callback urls generally)
SEC_5	Proxy	Setup by default empty truststore and keystore	Medium	Useful. It would avoid any call to an untrusted proxy	No. For CAS deployers who use proxies, it would stop to work unless they change the default CAS configuration
SEC_6	Service	Check /validate and /serviceValidate urls against the list of the trusted certificates using the checkAgainstCertificates flag defined for each service (true by default)	Medium	Rather useful. It would check the SSL certificate even if the url has already been checked : DNS attack ?	No. All services in HTTPS would stop to work in the appropriate certificates are not in the truststore.
SEC_7	Proxie	Remove critical information from the urls : use POST instead of GET requests for proxy callbacks and /proxy url	Hard (clients must be upgraded as well)	Useful. Avoid criticial information in logs or from being indexed...	No. Very invasive change as clients should be also upgraded.