| 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 ? | |
| 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) | 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. |
Page Comparison
General
Content
Integrations