CAS 認証

概要

JA-SIG は、CAS として知られるエンタープライズ規模のシングルサインオンシステムを作成します。他のイニシアチブとは異なり、JA-SIG の中央認証サービスはオープンソースであり、広く使用され、理解しやすく、プラットフォームに依存せず、プロキシ機能をサポートしています。Spring Security は CAS を完全にサポートし、Spring Security の単一アプリケーションデプロイから企業全体の CAS サーバーで保護された複数アプリケーションデプロイへの簡単な移行パスを提供します。

CAS の詳細については、www.apereo.org (英語) を参照してください。CAS サーバーファイルをダウンロードするには、このサイトにアクセスする必要もあります。

CAS の仕組み

CAS の Web サイトには CAS のアーキテクチャを詳しく説明するドキュメントが含まれていますが、ここでは Spring Security のコンテキスト内で一般的な概要を再度示します。Spring Security 3.x は CAS 3 をサポートしています。執筆時点では、CAS サーバーのバージョンは 3.4 でした。

企業のどこかで CAS サーバーをセットアップする必要があります。CAS サーバーは単なる標準の WAR ファイルであるため、サーバーをセットアップするのは難しくありません。WAR ファイル内では、ユーザーに表示されるログインおよびその他のシングルサインオンページをカスタマイズします。

CAS 3.4 サーバーをデプロイする場合、CAS に含まれる deployerConfigContext.xml で AuthenticationHandler を指定する必要もあります。AuthenticationHandler には、指定された資格情報のセットが有効かどうかについてブール値を返す単純なメソッドがあります。AuthenticationHandler 実装は、LDAP サーバーやデータベースなど、何らかの型のバックエンド認証リポジトリにリンクする必要があります。CAS 自体には、これを支援する多数の AuthenticationHandler がすぐに使用できます。サーバー war ファイルをダウンロードしてデプロイすると、ユーザー名と一致するパスワードを入力したユーザーを正常に認証するようにセットアップされます。これはテストに役立ちます。

CAS サーバー自体とは別に、他の主要なプレーヤーはもちろん、企業全体にデプロイされている安全な Web アプリケーションです。これらの Web アプリケーションは「サービス」と呼ばれます。サービスには 3 つの型があります。サービスチケットを認証するもの、プロキシチケットを取得できるもの、プロキシチケットを認証するもの。プロキシチケットの認証は、プロキシのリストを検証する必要があり、多くの場合、プロキシチケットを再利用できるため、異なります。

Spring Security と CAS 相互作用シーケンス

Web ブラウザー、CAS サーバー、Spring セキュリティで保護されたサービス間の基本的な相互作用は次のとおりです。

  • Web ユーザーはサービスの公開ページを閲覧しています。CAS または Spring Security は関係しません。

  • ユーザーは最終的に、安全なページ、または使用する Bean の 1 つが安全なページをリクエストします。Spring Security の ExceptionTranslationFilter は AccessDeniedException または AuthenticationException を検出します。

  • ユーザーの Authentication オブジェクト（またはその欠如）が AuthenticationException を引き起こしたため、ExceptionTranslationFilter は設定された AuthenticationEntryPoint を呼び出します。CAS を使用する場合、これは CasAuthenticationEntryPoint クラスになります。

  • CasAuthenticationEntryPoint は、ユーザーのブラウザーを CAS サーバーにリダイレクトします。また、Spring Security サービス (あなたのアプリケーション) のコールバック URL である service パラメーターも示します。例: ブラウザーのリダイレクト先の URL は my.company.com/cas/login?service=https%3A%2F%2Fserver3.company.com%2Fwebapp%2Flogin/cas (英語) の可能性があります。

  • ユーザーのブラウザーが CAS にリダイレクトすると、ユーザー名とパスワードの入力を求められます。ユーザーが以前にログオンしたことを示すセッション Cookie を提示した場合、再度ログインするように求められることはありません（この手順には例外があります。これについては後で説明します）。CAS は、上記の PasswordHandler （または CAS 3.0 を使用する場合は AuthenticationHandler）を使用して、ユーザー名とパスワードが有効かどうかを判断します。

  • ログインに成功すると、CAS はユーザーのブラウザーを元のサービスにリダイレクトします。また、ticket パラメーターも含まれます。これは、「サービスチケット」を表す不透明な文字列です。前の例を続けると、ブラウザーがリダイレクトされる URL は server3.company.com/webapp/login/cas?ticket=ST-0-ER94xMJmn6pha35CQRoZ (英語) になる可能性があります。

  • サービス Web アプリケーションに戻ると、CasAuthenticationFilter は常に /login/cas へのリクエストをリッスンしています（これは構成可能ですが、この導入ではデフォルトを使用します）。処理フィルターは、サービスチケットを表す UsernamePasswordAuthenticationToken を構築します。プリンシパルは CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER に等しくなりますが、クレデンシャルはサービスチケットの不透明な値になります。この認証リクエストは、構成された AuthenticationManager に渡されます。

  • AuthenticationManager 実装は ProviderManager になり、ProviderManager は CasAuthenticationProvider で構成されます。CasAuthenticationProvider は、CAS 固有のプリンシパル（CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER など）および CasAuthenticationToken（後述）を含む UsernamePasswordAuthenticationToken にのみ応答します。

  • CasAuthenticationProvider は、TicketValidator 実装を使用してサービスチケットを検証します。これは通常、CAS クライアントライブラリに含まれるクラスの 1 つである Cas20ServiceTicketValidator です。アプリケーションがプロキシチケットを検証する必要がある場合、Cas20ProxyTicketValidator が使用されます。TicketValidator は、サービスチケットを検証するために CAS サーバーに HTTPS リクエストを行います。この例に含まれているプロキシコールバック URL my.company.com/cas/proxyValidate?service=https%3A%2F%2Fserver3.company.com%2Fwebapp%2Flogin/cas&ticket=ST-0-ER94xMJmn6pha35CQRoZ&pgtUrl=https://server3.company.com/webapp/login/cas/proxyreceptor (英語) も含まれる場合があります。

  • CAS サーバーに戻ると、検証リクエストが受信されます。提示されたサービスチケットが、チケットが発行されたサービス URL と一致する場合、CAS はユーザー名を示す肯定レスポンスを XML で提供します。認証にプロキシが関与している場合（後述）、プロキシのリストも XML レスポンスに含まれます。

  • [ オプション ] CAS 検証サービスへのリクエストにプロキシコールバック URL（pgtUrl パラメーター内）が含まれていた場合、CAS は XML レスポンスに pgtIou 文字列を含めます。この pgtIou は、プロキシ許可チケット IOU を表します。CAS サーバーは、pgtUrl への独自の HTTPS 接続を作成します。これは、CAS サーバーとリクエストされたサービス URL を相互に認証するためです。HTTPS 接続を使用して、プロキシ許可チケットを元の Web アプリケーションに送信します。例: server3.company.com/webapp/login/cas/proxyreceptor?pgtIou=PGTIOU-0-R0zlgrl4pdAQwBvJWO3vnNpevwqStbSGcq3vKB2SqSFFRnjPHt&pgtId=PGT-1-si9YkkHLrtACBo64rmsi3v2nf7cpCResXg5MpESZFArbaZiOKH (英語)

  • Cas20TicketValidator は、CAS サーバーから受信した XML を解析します。CasAuthenticationProvider に TicketResponse を返します。これには、ユーザー名（必須）、プロキシリスト（含まれている場合）、プロキシ許可チケット IOU（プロキシコールバックがリクエストされた場合）が含まれます。

  • 次に、CasAuthenticationProvider は構成済みの CasProxyDecider を呼び出します。CasProxyDecider は、TicketResponse のプロキシリストがサービスに受け入れられるかどうかを示します。Spring Security にはいくつかの実装が用意されています: RejectProxyTickets、AcceptAnyCasProxy、NamedCasProxyDecider。これらの名前は、信頼できるプロキシの List を提供できる NamedCasProxyDecider を除いて、ほとんど自明です。

  • CasAuthenticationProvider は、次に Assertion に含まれるユーザーに適用される GrantedAuthority オブジェクトをロードするために AuthenticationUserDetailsService をリクエストします。

  • 問題がなければ、CasAuthenticationProvider は TicketResponse および GrantedAuthority に含まれる詳細を含む CasAuthenticationToken を作成します。

  • 次に、制御が CasAuthenticationFilter に戻り、作成された CasAuthenticationToken がセキュリティコンテキストに配置されます。

  • ユーザーのブラウザーは、AuthenticationException （または構成に応じてカスタムの宛先）を引き起こした元のページにリダイレクトされます。

まだここにいるのは良いことです！ これがどのように構成されているか見てみましょう

CAS クライアントの構成

CAS の Web アプリケーション側は、Spring Security により簡単になりました。Spring Security の使用の基本をすでに知っていることを前提としているため、以下ではこれらについて再度説明しません。名前空間ベースの構成が使用されていると想定し、必要に応じて CAS Bean を追加します。各セクションは前のセクションに基づいています。完全な CAS サンプルアプリケーションは、Spring Security サンプルにあります。

サービスチケット認証

このセクションでは、Spring Security をセットアップしてサービスチケットを認証する方法について説明します。多くの場合、これはすべて Web アプリケーションに必要です。ServiceProperties Bean をアプリケーションコンテキストに追加する必要があります。これは CAS サービスを表しています:

<bean id="serviceProperties"
	class="org.springframework.security.cas.ServiceProperties">
<property name="service"
	value="https://localhost:8443/cas-sample/login/cas"/>
<property name="sendRenew" value="false"/>
</bean>

service は、CasAuthenticationFilter によって監視される URL と等しくなければなりません。sendRenew のデフォルトは false ですが、アプリケーションが特に敏感な場合は true に設定する必要があります。このパラメーターは、シングルサインオンログインが受け入れられないことを CAS ログインサービスに通知します。代わりに、ユーザーはサービスにアクセスするためにユーザー名とパスワードを再入力する必要があります。

CAS 認証プロセスを開始するには、次の Bean を構成する必要があります（ネームスペース構成を使用していると仮定）。

<security:http entry-point-ref="casEntryPoint">
...
<security:custom-filter position="CAS_FILTER" ref="casFilter" />
</security:http>

<bean id="casFilter"
	class="org.springframework.security.cas.web.CasAuthenticationFilter">
<property name="authenticationManager" ref="authenticationManager"/>
</bean>

<bean id="casEntryPoint"
	class="org.springframework.security.cas.web.CasAuthenticationEntryPoint">
<property name="loginUrl" value="https://localhost:9443/cas/login"/>
<property name="serviceProperties" ref="serviceProperties"/>
</bean>

CAS が動作するには、ExceptionTranslationFilter の authenticationEntryPoint プロパティが CasAuthenticationEntryPoint Bean に設定されている必要があります。これは、上記の例で行ったように、entry-point-ref を使用して簡単に行うことができます。CasAuthenticationEntryPoint は、企業の CAS ログインサーバーへの URL を提供する ServiceProperties Bean（上記で説明）を参照する必要があります。これは、ユーザーのブラウザーがリダイレクトされる場所です。

CasAuthenticationFilter には、UsernamePasswordAuthenticationFilter （フォームベースのログインに使用）と非常によく似たプロパティがあります。これらのプロパティを使用して、認証の成功と失敗の動作などをカスタマイズできます。

次に、CasAuthenticationProvider とその協力者を追加する必要があります。

<security:authentication-manager alias="authenticationManager">
<security:authentication-provider ref="casAuthenticationProvider" />
</security:authentication-manager>

<bean id="casAuthenticationProvider"
	class="org.springframework.security.cas.authentication.CasAuthenticationProvider">
<property name="authenticationUserDetailsService">
	<bean class="org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper">
	<constructor-arg ref="userService" />
	</bean>
</property>
<property name="serviceProperties" ref="serviceProperties" />
<property name="ticketValidator">
	<bean class="org.apereo.cas.client.validation.Cas20ServiceTicketValidator">
	<constructor-arg index="0" value="https://localhost:9443/cas" />
	</bean>
</property>
<property name="key" value="an_id_for_this_auth_provider_only"/>
</bean>

<security:user-service id="userService">
<!-- Password is prefixed with {noop} to indicate to DelegatingPasswordEncoder that
NoOpPasswordEncoder should be used.
This is not safe for production, but makes reading
in samples easier.
Normally passwords should be hashed using BCrypt -->
<security:user name="joe" password="{noop}joe" authorities="ROLE_USER" />
...
</security:user-service>

CasAuthenticationProvider は、CAS によって認証されると、UserDetailsService インスタンスを使用してユーザーの権限を読み込みます。ここでは、簡単なメモリ内セットアップを示しました。CasAuthenticationProvider は実際には認証にパスワードを使用しないが、権限を使用することに注意してください。

CAS の仕組みセクションに戻って参照すると、Bean はすべて合理的に自明です。

これで、CAS の最も基本的な構成が完了しました。間違いを犯していない場合、Web アプリケーションは CAS シングルサインオンのフレームワーク内で問題なく動作するはずです。Spring Security の他の部分は、CAS が認証を処理したという事実を心配する必要はありません。次のセクションでは、いくつかの（オプションの）より高度な構成について説明します。

シングルログアウト

CAS プロトコルはシングルログアウトをサポートし、Spring Security 構成に簡単に追加できます。以下は、シングルログアウトを処理する Spring Security 構成の更新です。

<security:http entry-point-ref="casEntryPoint">
...
<security:logout logout-success-url="/cas-logout.jsp"/>
<security:custom-filter ref="requestSingleLogoutFilter" before="LOGOUT_FILTER"/>
<security:custom-filter ref="singleLogoutFilter" before="CAS_FILTER"/>
</security:http>

<!-- This filter handles a Single Logout Request from the CAS Server -->
<bean id="singleLogoutFilter" class="org.apereo.cas.client.session.SingleSignOutFilter"/>

<!-- This filter redirects to the CAS Server to signal Single Logout should be performed -->
<bean id="requestSingleLogoutFilter"
	class="org.springframework.security.web.authentication.logout.LogoutFilter">
<constructor-arg value="https://localhost:9443/cas/logout"/>
<constructor-arg>
	<bean class=
		"org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler"/>
</constructor-arg>
<property name="filterProcessesUrl" value="/logout/cas"/>
</bean>

logout 要素は、ユーザーをローカルアプリケーションからログアウトさせますが、ログインしている CAS サーバーやその他のアプリケーションとのセッションは終了しません。requestSingleLogoutFilter フィルターを使用すると、/spring_security_cas_logout の URL をリクエストして、アプリケーションを構成済みの CAS サーバーログアウト URL にリダイレクトできます。次に、CAS サーバーは、サインインしたすべてのサービスにシングルログアウトリクエストを送信します。singleLogoutFilter は、静的 Map で HttpSession を検索して無効化することにより、シングルログアウトリクエストを処理します。

logout 要素と singleLogoutFilter の両方が必要な理由は混乱するかもしれません。SingleSignOutFilter は HttpSession を静的 Map に保存するだけで、その上で無効化を呼び出すため、最初にローカルでログアウトすることをお勧めします。上記の構成では、ログアウトのフローは次のようになります。

  • ユーザーは /logout をリクエストします。/logout はユーザーをローカルアプリケーションからログアウトし、ログアウト成功ページに送信します。

  • ログアウト成功ページ /cas-logout.jsp は、すべてのアプリケーションからログアウトするために、/logout/cas を指すリンクをクリックするようユーザーに指示する必要があります。

  • ユーザーがリンクをクリックすると、ユーザーは CAS シングルログアウト URL（localhost:9443/cas/logout）にリダイレクトされます。

  • CAS サーバー側では、CAS シングルログアウト URL がシングルログアウトリクエストをすべての CAS サービスに送信します。CAS サービス側では、Apereo の SingleSignOutFilter が元のセッションを無効にすることでログアウトリクエストを処理します。

次のステップは、web.xml に以下を追加することです 

<filter>
<filter-name>characterEncodingFilter</filter-name>
<filter-class>
	org.springframework.web.filter.CharacterEncodingFilter
</filter-class>
<init-param>
	<param-name>encoding</param-name>
	<param-value>UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>characterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class>
	org.apereo.cas.client.session.SingleSignOutHttpSessionListener
</listener-class>
</listener>

SingleSignOutFilter を使用すると、エンコードの問題が発生する場合があります。SingleSignOutFilter を使用するときに文字エンコーディングが正しいことを確認するために、CharacterEncodingFilter を追加することをお勧めします。詳細については、Apereo CAS のドキュメントを参照してください。SingleSignOutHttpSessionListener は、HttpSession の有効期限が切れると、シングルログアウトに使用されるマッピングが削除されるようにします。

CAS を使用したステートレスサービスへの認証

このセクションでは、CAS を使用してサービスに対して認証する方法について説明します。つまり、このセクションでは、CAS で認証するサービスを使用するクライアントをセットアップする方法について説明します。次のセクションでは、CAS を使用して認証するステートレスサービスをセットアップする方法について説明します。

プロキシ許可チケットを取得するための CAS の構成

ステートレスサービスを認証するには、アプリケーションはプロキシ許可チケット（PGT）を取得する必要があります。このセクションでは、thencas-st [Service Ticket Authentication] 設定時に PGT を取得するために Spring Security を設定する方法について説明します。

最初のステップは、Spring Security 構成に ProxyGrantingTicketStorage を含めることです。これは、プロキシチケットを取得するために使用できるように、CasAuthenticationFilter によって取得された PGT を保存するために使用されます。構成例を以下に示します 

<!--
NOTE: In a real application you should not use an in memory implementation.
You will also want to ensure to clean up expired tickets by calling
ProxyGrantingTicketStorage.cleanup()
-->
<bean id="pgtStorage" class="org.apereo.cas.client.proxy.ProxyGrantingTicketStorageImpl"/>

次のステップは、CasAuthenticationProvider を更新してプロキシチケットを取得できるようにすることです。これを行うには、Cas20ServiceTicketValidator を Cas20ProxyTicketValidator に置き換えます。proxyCallbackUrl は、アプリケーションが PGT を受け取る URL に設定する必要があります。最後に、構成は PGT を使用してプロキシチケットを取得できるように、ProxyGrantingTicketStorage も参照する必要があります。以下に行う必要がある構成変更の例を見つけることができます。

<bean id="casAuthenticationProvider"
	class="org.springframework.security.cas.authentication.CasAuthenticationProvider">
...
<property name="ticketValidator">
	<bean class="org.apereo.cas.client.validation.Cas20ProxyTicketValidator">
	<constructor-arg value="https://localhost:9443/cas"/>
		<property name="proxyCallbackUrl"
		value="https://localhost:8443/cas-sample/login/cas/proxyreceptor"/>
	<property name="proxyGrantingTicketStorage" ref="pgtStorage"/>
	</bean>
</property>
</bean>

最後のステップは、CasAuthenticationFilter を更新して PGT を受け入れ、ProxyGrantingTicketStorage に保管することです。proxyReceptorUrl が Cas20ProxyTicketValidator の proxyCallbackUrl と一致することが重要です。構成例を以下に示します。

<bean id="casFilter"
		class="org.springframework.security.cas.web.CasAuthenticationFilter">
	...
	<property name="proxyGrantingTicketStorage" ref="pgtStorage"/>
	<property name="proxyReceptorUrl" value="/login/cas/proxyreceptor"/>
</bean>

プロキシチケットを使用したステートレスサービスの呼び出し

Spring Security が PGT を取得したため、使用して、ステートレスサービスへの認証に使用できるプロキシチケットを作成できます。CAS サンプルアプリケーションには、ProxyTicketSampleServlet の実用的な例が含まれています。サンプルコードは以下にあります:

  • Java

  • Kotlin

protected void doGet(HttpServletRequest request, HttpServletResponse response)
	throws ServletException, IOException {
// NOTE: The CasAuthenticationToken can also be obtained using
// SecurityContextHolder.getContext().getAuthentication()
final CasAuthenticationToken token = (CasAuthenticationToken) request.getUserPrincipal();
// proxyTicket could be reused to make calls to the CAS service even if the
// target url differs
final String proxyTicket = token.getAssertion().getPrincipal().getProxyTicketFor(targetUrl);

// Make a remote call using the proxy ticket
final String serviceUrl = targetUrl+"?ticket="+URLEncoder.encode(proxyTicket, "UTF-8");
String proxyResponse = CommonUtils.getResponseFromServer(serviceUrl, "UTF-8");
...
}
protected fun doGet(request: HttpServletRequest, response: HttpServletResponse?) {
    // NOTE: The CasAuthenticationToken can also be obtained using
    // SecurityContextHolder.getContext().getAuthentication()
    val token = request.userPrincipal as CasAuthenticationToken
    // proxyTicket could be reused to make calls to the CAS service even if the
    // target url differs
    val proxyTicket = token.assertion.principal.getProxyTicketFor(targetUrl)

    // Make a remote call using the proxy ticket
    val serviceUrl: String = targetUrl + "?ticket=" + URLEncoder.encode(proxyTicket, "UTF-8")
    val proxyResponse = CommonUtils.getResponseFromServer(serviceUrl, "UTF-8")
}

代理チケット認証

CasAuthenticationProvider は、ステートフルクライアントとステートレスクライアントを区別します。ステートフルクライアントは、CasAuthenticationFilter の filterProcessesUrl に送信するものと見なされます。ステートレスクライアントは、filterProcessesUrl 以外の URL で CasAuthenticationFilter に認証リクエストを提示するものです。

リモーティングプロトコルには HttpSession のコンテキスト内で自身を提示する方法がないため、リクエスト間のセッションにセキュリティコンテキストを保存するデフォルトのプラクティスに依存することはできません。さらに、TicketValidator によって検証された後、CAS サーバーはチケットを無効にするため、後続のリクエストで同じプロキシチケットを提示しても機能しません。

明らかなオプションの 1 つは、リモートプロトコルクライアントに CAS をまったく使用しないことです。ただし、これは CAS の多くの望ましい機能を削除します。中間として、CasAuthenticationProvider は StatelessTicketCache を使用します。これは、CasAuthenticationFilter.CAS_STATELESS_IDENTIFIER に等しいプリンシパルを使用するステートレスクライアントにのみ使用されます。CasAuthenticationProvider は、結果の CasAuthenticationToken を StatelessTicketCache に保存し、プロキシチケットにキーを設定します。リモーティングプロトコルクライアントは同じプロキシチケットを提示することができ、CasAuthenticationProvider は検証のために CAS サーバーに接続する必要はありません（最初のリクエストを除く）。認証されると、プロキシチケットは元のターゲットサービス以外の URL に使用できます。

このセクションは、プロキシチケット認証に対応するために、前のセクションに基づいています。最初のステップは、以下に示すように、すべてのアーティファクトの認証を指定することです。

<bean id="serviceProperties"
	class="org.springframework.security.cas.ServiceProperties">
...
<property name="authenticateAllArtifacts" value="true"/>
</bean>

次のステップは、serviceProperties と CasAuthenticationFilter の authenticationDetailsSource を指定することです。serviceProperties プロパティは、filterProcessesUrl に存在するものだけではなく、すべてのアーティファクトを認証しようとするように CasAuthenticationFilter に指示します。ServiceAuthenticationDetailsSource は ServiceAuthenticationDetails を作成し、HttpServletRequest に基づいて現在の URL がチケットの検証時にサービス URL として使用されるようにします。サービス URL を生成する方法は、カスタム ServiceAuthenticationDetails を返すカスタム AuthenticationDetailsSource を注入することによりカスタマイズできます。

<bean id="casFilter"
	class="org.springframework.security.cas.web.CasAuthenticationFilter">
...
<property name="serviceProperties" ref="serviceProperties"/>
<property name="authenticationDetailsSource">
	<bean class=
	"org.springframework.security.cas.web.authentication.ServiceAuthenticationDetailsSource">
	<constructor-arg ref="serviceProperties"/>
	</bean>
</property>
</bean>

プロキシチケットを処理するには、CasAuthenticationProvider を更新する必要もあります。これを行うには、Cas20ServiceTicketValidator を Cas20ProxyTicketValidator に置き換えます。statelessTicketCache と、受け入れたいプロキシを設定する必要があります。すべてのプロキシを受け入れるために必要な更新の例を以下に示します。

<bean id="casAuthenticationProvider"
	class="org.springframework.security.cas.authentication.CasAuthenticationProvider">
...
<property name="ticketValidator">
	<bean class="org.apereo.cas.client.validation.Cas20ProxyTicketValidator">
	<constructor-arg value="https://localhost:9443/cas"/>
	<property name="acceptAnyProxy" value="true"/>
	</bean>
</property>
<property name="statelessTicketCache">
	<bean class="org.springframework.security.cas.authentication.EhCacheBasedTicketCache">
	<property name="cache">
		<bean class="net.sf.ehcache.Cache"
			init-method="initialise" destroy-method="dispose">
		<constructor-arg value="casTickets"/>
		<constructor-arg value="50"/>
		<constructor-arg value="true"/>
		<constructor-arg value="false"/>
		<constructor-arg value="3600"/>
		<constructor-arg value="900"/>
		</bean>
	</property>
	</bean>
</property>
</bean>