| Identifier | Scope | Proposal | Development complexity | EfficiencyEffectiveness | 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 Handled by SEC_8 | |||||
| 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 Handled by SEC_8 | ||||||
| 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 Handled by SEC_8 | ||||||
| SEC_3 | Proxy | Change the default value of the | allowToProxyallowedToProxy 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 | allowToProxyallowedToProxy flag. Only new deployement would be impacted or very specific mechanism using the default | allowToProxyallowedToProxy flag value | 4.0 ? | DONE for 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 | 4.1 | Implemented in 4.1 | |||||
| SEC_6 | Service | CheckWhen 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 ( | truefalse by default) | Medium | RatherMight be useful. It would check the SSL certificate even if the url has already been checked | :, to avoid DNS attack | ?. | No. All services in HTTPS would stop to work in the appropriate certificates are not in the truststore. | 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) Handled by SEC_8 | ||
| 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. | Handled by SEC_8 | ||||||
| SEC_8 | Proxy/Validation | Instead of performing a proxy callback to the client to deliver the PGTID and PGTIOU, or when returning attributes in general, 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. Possible for 4.1, 4.x and 5 | ||||||
| SEC_9 | Service+ Proxy | Encrypt/Hash the ticket registry as appropriate to avoid people either stealing or tampering with the registry, either in the wire, in memory or on disk. | Hard | This would be extremely useful to make the ticket registry secure out of the box even if the user does not take pains to encrypt his network traffic or disk storage. | No. Not backward compatible with existing sessions. Not backward compatible to older CAS servers in the same cluster (there may be ways to work around this). Is backward compatible with old clients. | 4.1 | Possible for 4.1, 4.x and 5. Proposed by Jerome | |||||
| SEC_10 | Service + Proxy | Remove/encrypt/truncate sensitive information from the CAS log by default. For example TGT and ST is logged in the CAS log by default. Enable this for debug mode, but for production, this should not be logged by default. (Also consider proxyCallbackURL). | Medium | Removes a simple to exploit way to break CAS security for someone with access to the log files. | Yes | 4.1 | Default logger factory removes TGT. Done for 4.1 |
Page Comparison
General
Content
Integrations