cas伺服器源碼閱讀筆記，對标部落格

對标源碼閱讀部落格：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後，沒有被使用了。

本文轉自二郎三郎部落格園部落格，原文連結：http://www.cnblogs.com/haore147/p/7172177.html，如需轉載請自行聯系原作者