對標源碼閱讀博客：http://www.cnblogs.com/jiuzhongguo/category/375405.html
在CAS中很多地方使用了策略模式，那么根據什么方式來確定使用哪種策略呢？在很多策略類中有一個support(Credentials c)的方法，所以可以看出是根據Credentails的類型來決定使用哪種策略的。所以我們在AuthenticationHandler,CredentialsToPrincipalResolver,CredentialsBinder這些都可以看到support(Credentials c)方法。
下面是公用API列表，我們來一個個介紹這些接口的作用吧。
- org.jasig.cas.CentralAuthenticationService:CAS核心，提供給HTTP，Web HTML, Web Services, RMI或者其他請求使用。能夠創建，存儲，驗證和驗證票據信息。
具有幾個方法：
1）String createTicketGrantingTicket(Credentials credentials)
throws TicketException：根據憑證對象來創建一個TGT票據，那么憑證怎么來的呢？就是頁面輸入的信息，現在知道為啥TGT是和用戶相關的憑證了吧。2） String grantServiceTicket(String ticketGrantingTicketId, Service service)
throws TicketException：更具TGT和service來創建ST，從前面我們知道service就是接入的應用系統，那么ST就是用戶（TGT）訪問的service的票據。3） String grantServiceTicket(final String ticketGrantingTicketId,final Service service, final Credentials credentials)
throws TicketException：這個是干嘛的呢？更具TGT和service來創建ST，從前面我們知道service就是接入的應用系統，那么ST就是用戶（TGT）訪問的service的票據。同時會給服務提供驗證的credentials.
4）Assertion validateServiceTicket(final String serviceTicketId, final Service service) throws TicketException：很容易理解是不是，就是驗證ST的，那么怎么返回一個Assertion對象，哦，對了，在前面介紹客戶端配置票據驗證的時候，是不是驗證通過后會有一個xml格式的數據？明白了吧，就是個那個地方使用的。
5） void destroyTicketGrantingTicket(final String ticketGrantingTicketId)：沒啥好說了，票據不會一直創建下去，用戶也不是一直在線，總需要退出，就算不退出也有一個時間限制吧，這個就是給登出或者超時后銷毀和用戶相關的TGT票據使用滴。
6） String delegateTicketGrantingTicket(final String serviceTicketId, final Credentials credentials) throws TicketException：文檔說是給代理使用的，不是很明白，org.jasig.cas.authentication.handler.support.AbstractUsernamePasswordAuthenticationHandler
- org.jasig.cas.authentication.handler.AuthenticationHandler:：這個很好理解，就是實際驗證的，只有兩個方法：boolean authenticate(Credentials credentials)和 boolean supports(Credentials credentials)后面這個是不是很熟悉啊，對了，就是前面提到的策略模式中的supports方法，怎么認證方法只會返回true和false啊，那么用戶信息怎么取得呢？別急嘛，右面有個CredentialsToPrincipalResolver接口專門來做這個事情滴。
- org.jasig.cas.authentication.handler.PasswordEncoder：密碼轉換器
- org.jasig.cas.authentication.principal.Credentials：取得客戶輸入的數據，或者可以理解為用戶認證的憑據。就是需要認證用戶身份需要的數據，每種認證方式需要信息是不一樣的。這個只是一個類型接口，就是沒有任何方法的接口啦。
- org.jasig.cas.authentication.principal.CredentialsToPrincipalResolver：上面我們說到，Credentials對象是從界面或者別的什么地方取得用戶信息，那么用戶信息通過認證后怎么轉換為Principal對象呢，這個就是這個解析器的作用了，由於認證本身是沒有返回用戶信息的，只是確定人中通過還是沒有通過，所以取得用戶信息需要另外一個非常重要的接口PersonAttributeDao，這個接口其實並不在CAS核心接口中的，是在一個叫person-directory-api-1.5.0-RC6.jar中的，這個包里面只有兩個類，兩個接口，那么實現有那些呢？是在person-directory-impl-1.5.0-RC6.jar，這個里面內容很豐富的。基本上你能想到的所有能取得用戶信息的地方都有實現了。這個接口，也是一個策略，只有兩個方法：supports , Principal resolvePrincipal(Credentials credentials),后面這個接口是不是很一目了然了？你可以理解我解析，或者更貼切點叫轉換。
- org.jasig.cas.authentication.principal.Principal：這個主要是保存認證后的用戶信息。擴展信息放在一個Map中的。
- org.jasig.cas.authentication.principal.Service：這個接口定義了和客戶端相關的方法，例如登出服務器logOutOfService等動作。logOutOfService就是單點登出時候，怎么在服務器端登出所有訪問過的客戶端啦。
- org.jasig.cas.authentication.principal.UsernamePasswordCredentials：用戶用戶名和密碼訪問的Credentials實現。
- org.jasig.cas.authentication.Authentication：認證對象，就是一次認證后的結果對象，那么為啥不使用Principal對象來作為認證結果呢？第一不是每次認證都是合法用戶，對於不合法用戶怎么辦呢？其次，認證是一個動作，和這個動作本身相關的信息顯然和用戶信息是沒有關系，例如認證時間。這個接口將Principal對象做了一次包裝。也就是說可以通過Authentication接口可以訪問到Principal對象。
- org.jasig.cas.authentication.AuthenticationManager
- org.jasig.cas.authentication.AuthenticationMetaDataPopulator
- org.jasig.cas.ticket.proxy.ProxyHandler
- org.jasig.cas.ticket.registry.TicketRegistry
- org.jasig.cas.ticket.registry.RegistryCleaner
- org.jasig.cas.ticket.registry.AbstractTicketRegistry
- org.jasig.cas.ticket.ExpirationPolicy
- org.jasig.cas.util.UniqueTicketIdGenerator
- org.jasig.cas.validation.ValidationSpecification
- org.jasig.cas.validation.Assertion：這個接口主要是定義了，驗證服務返回的對象，就是一個斷言，你這個ＳＴ有沒有權限訪問，以及ＴＧＴ訪問的ＳＴ認證對象。
- org.jasig.cas.web.bind.CredentialsBinder：這個是一個綁定器，將用戶輸入的信息或者從IE或者別的地方得到信息綁定到對應的憑證中去。使用spring web flew后，沒有被使用了。