Proposals to mitigate security risks

Identifier	Scope	Proposal	Development complexity	Efficiency	Backward compatible	Target	Feedbacks
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 ?	Bill : +1 for 3.5.3 and 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		Bill : +1 for 3.6 or 4.0
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		Bill : +1 for 3.6 or 4.0
SEC_3	Proxy	Change the default value of the allowedToProxy 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 allowedToProxy flag. Only new deployement would be impacted or very specific mechanism using the default allowedToProxy flag value	4.0 ?	Bill : +1 for 3.5.3 and 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)		This check is more useful if we don't have an empty certificates store (not SEC_5)
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	When calling /validate and /serviceValidate urls, the CAS server should connect back to the application to check against the list of the trusted certificates using the checkAgainstCertificates flag defined for each service (false by default)	Medium	Might be useful. It would check the SSL certificate even if the url has already been checked, to avoid DNS attack.	Yes. This extra security feature must be enabled only in specific cases.		This check makes sense only if there is a empty certificates store (SEC_5)
SEC_7	Proxy	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.
SEC_8	Proxy	Instead of performing a proxy callback to the client to deliver the PGTID and PGTIOU, we could have the PGTID (instead of the PGTIOU) embedded directly in the CAS response and the whole CAS response encrypted by the client public key. This kind of "PGT delivery" would be chosen by service (by default, we would keep the default PGT delivery : using a proxy callback).	Hard (clients must be upgraded as well)	Useful. Provide another way to ensure security with PGT.	Yes. This new kind of PGT delivery would need to be enabled by service.		Proposed by Bill.