| 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) | ||
| 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 | ProxieProxy | 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