原文地址：https://apereo.github.io/cas/4.2.x/planning/Security-Guide.html
Security Guide
CAS是一个安全软件，它为基于Web的应用提供了基于Web的安全单点登录(SSO)。SSO同时保证了安全和便捷：把密码输入减少到单点，提供可信的凭证中间人来透明地访问多个应用而不需要多次登录。
系统安全
安全传输(https)
所有的交互必需使用安全频道，有两个主要的理由：
认证过程需要进行安全凭证的传输。
CAS的TGT是一个bearer token。
因为这些数据的暴露可能会遭到中间人攻击，所以CAS客户端和服务器传输的安全是极其重要的。
实际上，这意味着所有CAS的URL必需使用HTTPS，也意味着所有从CAS服务器到应用的连接必需使用HTTPS：
当ST通过service URL回传给应用时。
当访问代理(proxy)回调URL时。
依赖系统的链接
CAS一般要求连接数据库等其他系统，我们一般建议使用安全传输(SSL/TLS, IPSec)，有严格访问控制的私有网络和企业网络是个例外，但是我们依然建议使用安全传输。LDAP客户端认证是一个好的解决方案，可以带来足够的安全。
部署驱动的安全特性
CAS支持多种安全特性，他们可以通过多种安全策略实现。下面的特性由CAS的配置和客户端集成提供。很多特性默认不支持，需要额外安装。
Forced Authentication(强制认证)
很多CAS客户端和支持的协议支持强制认证的概念，用户访问一个特定的服务必须通过认证。CAS协议通过renew参数支持强制认证。强制认证在SSO会话的认证策略中提供了额外的保证，因为用户访问前必需通过验证TA的凭证。强制认证适合高安全性的应用。通常，强制认证配置是每个应用的基础。它可以和多阶认证结合使用。
Passive Authentication(被动认证)
一些CAS协议支持被动认证，当访问时可以匿名访问被CAS保护的服务。CASv2和CASv3协议可以通过gateway特性具有这个能力。被动认证补充了强制认证。
Proxy Authentication
Proxy认证或者delegated认证，为CAS提供了一种强大、重要、有潜力的特性。CASv2和CASv3协议支持Proxy认证，它们通过proxy tickets在用户的支持下请求。服务为用户代理认证，通常用于服务不直接和用户交互的情况下。
然而，proxy tickets在那些接受proxy tickets的服务中引起了一些安全风险。(the list of services through which the end-user’s authentication have been delegated to arrive at the ticket validating service). Services can opt out of accepting proxy tickets entirely (and avoid responsibility for validating proxy chains) by simply validating tickets against the /serviceValidate validation endpoint, but experience has shown it’s easy to be confused about this and configure to unintentionally use the /proxyValidate endpoint yet not scrutinize any proxy chains that appear in the ticket validation response. 所以proxy认证要求合适的安全控制和谨慎的配置。如果不需要，建议禁用proxy代理组件。
以前任何服务都可以包含代理认证票据并且从它可以访问任何其他的应用。换句话说分布式的安全模型好于集中式的安全模型。服务管理工具提供了一些集中式的代理认证，可以通过一个设置启用和禁用。默认注册的服务是不授权代理认证能力的。
Multi-factor Authentication(多阶认证)
CAS提供了multi-factor认证的支持：全局的和分服务的。
全局的比较简单：在登录界面总是要求多个凭据，用户界面被修改为接受多个凭据和已经被配置为要求提供所有凭据的认证组件。
分服务的更复杂一些：
Levels of identity assurance (LOA) for credentials and groups of credentials must be established.
Security policy versus credential LOA must be established per service.
Service access policy must be configured via the service management facility.
The first two tasks are vital but outside the scope of this document. Application of service access policy via the service management facility is implemented by declaring the authentication handlers that must successfully authenticate credentials in order to permit access; for example, an LDAP authentication handler and an RSA SecureID authentication handler.
Since multi-factor authentication requires development of institutional security policy, advanced component configuration (and possibly custom component development), and UI design, it should be regarded more as a framework than a feature. See the multi-factor configuration section for detailed discussion of configuration concerns and implementation recommendations.
Credential Caching and Replay
The ClearPass extension provides a mechanism to capture primary authentication credentials, cache them (encrypted), and replay on demand as needed to access legacy services. While proxy authentication is recommended in lieu of password replay, it may be required to integrate legacy services with CAS. See the ClearPass documentation for detailed information.
Service Management(服务管理)
服务管理设施提供多个具体服务的配置控制，可以更改安全策略。并且提供一些中心和的安全策略支持。(注意CAS之前是支持分布式的安全策略模型的)。一些好的服务管理控制:
Authorized services
Forced authentication
Attribute release
Proxy authentication control
Theme control
Multi-factor service access policy
服务管理设施是由一个包括一个或多个注册服务的注册器组成的。每个都指定了下面的管理控制，服务注册器可以由静态的配置文件、Web页面控制。
Authorized Services(认证服务)
基于经验，强烈建议严格限制这个列表为已知的应用，否则可能会产生安全攻击的机会。
SSO Cookie Encryption(SSO Cookie加密)
一个ticket-granting cookie是一个HTTP cookie，由CAS设置。标记着SSO会话的建立。这个cookie值默认由cas.properties文件中的定义加密和签名。每次部署必需重新生成。详见这个指导。
Ticket Expiration Policies(票据失效策略)
票据失效策略是安全策略中一个主要的机制。票据有效期策略允许控制SSO会话一些重要的行为：
SSO会话时长 (sliding expiration, absolute)
Ticket 重用
看这一章获得更多细节导论，包括多种失效策略和配置指导.
Single Sign-Out(单点注销)
又可写做single log-out (SLO)。通过一个SSO会话主发布停止访问服务的期望，CAS服务被通知SSO会话结束。尽管这可以提高安全，但根本上并不会结束访问。下面的控制可以用来降低SLO带来的风险:
敏感服务要求强制认证
减少应用会话超时时间
减少SSO会话时长
SLO可以以两种方式实现:从CAS服务器(back-channel logout)或从浏览器(front-channel logout)。从服务器的话，SLO过程依赖SimpleHttpClient类有一个线程池：它的大小必需合适的定义来处理所有的注销请求。未被处理的注销请求会临时存储在一个队列里。队列的大小一般是全局线程池容量的20%. 这两个值是重要的设置，都不可以超过实际的容量。
Login Throttling(登录限制)
CAS支持策略驱动的特性来限制登录的尝试次数，用来避免暴力攻击。详见这个章节。
Credential Encryption(凭证加密)
一个开源的产品叫做Java Simplified Encryption，允许你在运行期间替换文件中的明文密码Jasypt可以被集成到Spring配置框架中，所以当配置文件加载的时候它的属性值可以被读取。Jasypt’s approach replaces the the property management technique with one that recognizes encrypted strings and decrypts them. This method uses password-based encryption, which means that the system still needs a secret password in order to decrypt our credentials. We don’t want to simply move the secret from one file to another, and Jasypt avoids that by passing the key as an environment variable or even directly to the application through a web interface each time it is deployed.
这个能力非常好，因为它不需要把明文凭证放在配置文件中，并且允许适配者安全的跟踪所有加密的设置，安全的和其他人共享配置。敏感的数据仅限制在部署环境。
CAS Security Filter(安全过滤器)
The CAS project provides a number of a blunt generic security filters suitable for patching-in-place Java CAS server and Java CAS client deployments vulnerable to certain request parameter based bad-CAS-protocol-input attacks. The filters are configured to sanitize authentication request parameters and reject the request if it is not compliant with the CAS protocol in the event that for instance, a parameter is repeated multiple times, includes multiple values, contains unacceptable values, etc.
It is STRONGLY recommended that all CAS deployments be evaluated and include this configuration if necessary to prevent protocol attacks in situations where the CAS container and environment are unable to block malicious and badly-configured requests.
Security Response Headers
As part of the CAS Security Filter, the CAS project automatically provides the necessary configuration to insert HTTP Security headers into the web response to prevent against HSTS, XSS, X-FRAME and other attacks. These settings are presently off by default, and may be enabled via the following settings:
# httpresponse.header.cache=false
# httpresponse.header.hsts=false
# httpresponse.header.xframe=false
# httpresponse.header.xcontent=false
# httpresponse.header.xss=false
To review and learn more about these options, please visit this guide.
Spring Webflow Sessions
The CAS project uses Spring Webflow to manage and orchestrate the authentication process. The conversational state of the webflow used by CAS is managed by the client which is then passed and tracked throughout various states of the authentication process. This state must be secured and encrypted to prevent session hijacking. While CAS provides default encryptions settings out of the box, it is STRONGLY recommended that all CAS deployments be evaluated prior to production rollouts and regenerate this configuration to prevent attacks.
User-Driven Security Features
The following features may be employed to afford some user control of the SSO experience.
Long Term Authentication
The long term authentication feature, commonly referred to as “Remember Me”, is selected (usually via checkbox) on the CAS login form to avoid reauthentication for an extended period of time. Long term authentication allows users to elect additional convenience at the expense of reduced security. The extent of reduced security is a function of the characteristics of the device used to establish a CAS SSO session. A long-term SSO session established from a device owned or operated by a single user is marginally less secure than a standard CAS SSO session. The only real concern would be the increased lifetime and resulting increased exposure of the CAS ticket-granting ticket. Establishing a long-term CAS SSO session from a shared device, on the other hand, may dramatically reduce security. The likelihood of artifacts from previous SSO sessions affecting subsequent SSO sessions established by other users, even in the face of single sign-out, may increase the likelihood of impersonation. While there are no feasible mitigations for improving security of long-term SSO sessions on a shared device, educating users on the inherent risks may improve overall security.
It is important to note that forced authentication supercedes long term authentication, thus if a service were configured for forced authentication, authentication would be required for service access even in the context of a long-term session.
Long term authentication support must be explicitly enabled through configuration and UI customization during the installation process. Thus deployers choose to offer long-term authentication support, and when available users may elect to use it via selection on the CAS login form.
Warn
CAS supports optional notification of service access during an established SSO session. By default CAS transparently requests tickets needed for service access and presents them to the target service for validation, whereby upon successful validation access to the service is permitted. In most cases this happens nearly instantly and the user is not aware of the CAS authentication process required to access CAS-enabled services. There may be some security benefit to awareness of this process, and CAS supports a warn flag that may be selected by the user on the CAS login screen to provide an interstitial notification page that is displayed prior to accessing a service. By default the notification page offers the user an option to proceed with CAS authentication or abort by navigating away from the target service.
0 Comments