CAS3.4エージェント・モードの詳細構成
5007 ワード
バージョン#バージョン#
CASサーバーバージョン:3.4.2
CASクライアントfor JAVAバージョン:3.1.10
前言
CAS3.4バージョンの資料はネット上で本当に少ないのがかわいそうで、幸いにも公式サイトが提供した資料は私に代理モードの配置を完成させてくれたが、E文を読むのは本当に骨が折れる.
詳細な構成の前にエージェントモードの認証についてお話ししますが、ネットで資料を調べると、エージェントモードはC/Sアーキテクチャにサービスするプログラムだという人がいて、例えば映画を見るなど、もちろん誰もが異なる見方をしていますが、私は本当に以上の言い方に賛成しません.
次に、エージェントモデルに対する簡単な認識を話します.もし不適切があれば、レンガを撮ることができます.
エージェント:その名の通り、他の人の代わりに何かをします.では、CASの環境では、エージェントがしなければならないことは、アプリの代わりにticket(proxy ticket)を申請することです.まず、B/Sアーキテクチャの用途を話します.
B/Sアーキテクチャのアプリケーションシーンでは、CASの動作原理を知っているはずですが、実際にエージェントを使わなくてもアプリケーション全体の環境の動作に影響を与えません.各アプリケーションがCAS Clientを実現すれば、自動的にCASサービス側に行って手形を申請しますが、エージェントモデルを使用するとアプリにどのような変更がありますか?実は簡単で、CASクライアントのソースコードを見ることでその理由がわかります.APPがCASクライアントを実現するには少なくとも2つのFilterを追加する必要があります.1つ目は認証Filterです.そのFilterの中にはセッションにAssertionオブジェクトがあるかどうかをチェックするものがあります.もしあれば終了すると、CASサーバにリダイレクトして認証を行い、認証後にAPPに戻って手形の両替を行います.プロセス全体は問題ありませんが、このFilterを見てください.要求パラメータにticketがある場合も同様にこのFilterを終了します.つまり、アプリにアクセスする際にパラメータにticketがある場合は、直接手形検証Filterに到着し、検証手形のFilterでは最下位で行うということです.よく考えてみると、このプロセスは2つのリダイレクトのプロセスを省くことができます.では、パフォーマンスの向上はどれくらい必要ですか.最も典型的な例は、ユーザー個人portalであり、ユーザーがCAS認証を経てportalに入った後、portalを通じて他の業務にアクセスすると、アクセスする前に、portalがアクセスされた業務の代わりに手形(PT)に申請し、ticketをパラメータとしてアクセスされた業務に渡されると、アクセスされた業務が直接手形検証Filterを行い、どんなに完璧なプロセスであるかである.
次に、エージェント・モードがC/Sアーキテクチャのプログラムに与えるメリットについて説明します.
最初にCASはC/Sアーキテクチャプログラムをサポートしていません.CASは手形に基づいて認証されているため、手形(TGC)はCOOKIEに格納されているため、C/SプログラムはまずCASの認証インタフェースを実現できないが、CASの手形検証インタフェースを実現することができる.C/Sプログラムを統合すると、ユーザーはまずブラウザでPortalにログインしてCASの検証を経て、PortalでリソースにアクセスしてSSOの効果を達成し、統合されたC/Sプログラムが実CASの手形認証インタフェースが現れて、それでは訪問する時普通はアカウント/パスワードを提供して、PTはC/Sプログラムのパスワードに取って代わって、使い捨てのパスワードとして使って、これによってユーザーの需要を満たしてC/Sプログラムの単点登録を実現して、これもとてもきれいな1つの流れです
詳細設定
最後に,CASのエージェントモードはC/Sプログラムのみにサービスするものではなく,B/Sプログラムに与えるメリットも刺激的である.CASエージェントモード全体の構成は伝説ほど複雑ではありません.
環境:合計3つのエンジニアリング(CASサービスシステム、エージェントシステム(cas-client-proxy)、一般ビジネスシステム(cas-client)
cas-client-proxyとcas-clientはCASクライアント、cas-client-proxyのwebを実現しなければならない.xml構成は
検証手形Filterを追加:
CAS Validation Filter org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter casServerUrlPrefix http://localhost:8080/cas serverName http://localhost:8080 proxyReceptorUrl /proxyCallback proxyCallbackUrl http://localhost:8080/cas-client-proxy/proxyCallback
検証手形Filterで落札された赤い2つのパラメータは、このアプリがエージェントモードにされているかどうかを決定する鍵です.
proxyCallbackUrlパラメータは、絶対パスであるPGTチケットを受信するアドレスを表す
proxyReceptorUrl:トレースコードを経て、パラメータが空でない場合、パラメータ値が示す絶対URL、すなわちproxyCallbackUrl値を取り出します.
以上の情報を設定したら、filter-mappingで「proxyCallbackUrl」にurlマッピングを追加することを覚えておいてください.
CAS Validation Filter
/proxyCallback
proxyCallbackという接尾辞のurlにアクセスすると、手形検証Filterに入ることを示します.
注意しなければならないのは、アプリケーションが単一のログアウト機能を統合している場合、単一のログアウトfilter-mappingは一番前に置くべきで、次にこれです.
構成全体が完了しました
PTの取得
キーコード:
パラメータサービスはエージェントされるビジネス・システム・アドレスであり、サービス・パラメータには最後にCASクライアント・エージェントを追跡した後、ビジネス・システムがチケットを検証するときに送信されるサービス・パラメータの後ろに反スラッシュがあることが分かったため、「/」が必要であることに注意してください.
一般的なビジネスシステムの構成は基本的に似ていますが、検証手形Filterでは異なり、一般的なビジネスシステムがエージェントモードとして再実行する必要がない場合は、proxyCallback UrlとproxyReceptorUrlパラメータを削除して追加できます.
プロキシ手形による検証として表示されます.
OK、全体の配置は完成して、今実験をすることができて、もし普通の業務の住所は"http://localhost:8080/cas-client/」は、まずportalシステムを行い、それからassertionオブジェクトを通じてPT手形を申請し、それから新しいブラウザを開き、cas-clientのアドレスを入力し、後にパラメータ「ticket=PT-xxx-cas」を追加し、通常は直接システムに入ることができ、ブラウザがリダイレクトしていない動作を感じることができます.
注意:テストのためにhttpプロトコルを使用していますが、httpを使用するにはCASサービスシステムの2つの場所を変更する必要があります.
1:変更するxmlファイル、cookieSecureをfalseに変更
2:deployerConfigContext.を修正するxmlファイル、authenticationHandlersプロパティ、
p:httpClient-ref="httpClient" p:requireSecure="false"/>
赤の属性を追加します.
CASサーバーバージョン:3.4.2
CASクライアントfor JAVAバージョン:3.1.10
前言
CAS3.4バージョンの資料はネット上で本当に少ないのがかわいそうで、幸いにも公式サイトが提供した資料は私に代理モードの配置を完成させてくれたが、E文を読むのは本当に骨が折れる.
詳細な構成の前にエージェントモードの認証についてお話ししますが、ネットで資料を調べると、エージェントモードはC/Sアーキテクチャにサービスするプログラムだという人がいて、例えば映画を見るなど、もちろん誰もが異なる見方をしていますが、私は本当に以上の言い方に賛成しません.
次に、エージェントモデルに対する簡単な認識を話します.もし不適切があれば、レンガを撮ることができます.
エージェント:その名の通り、他の人の代わりに何かをします.では、CASの環境では、エージェントがしなければならないことは、アプリの代わりにticket(proxy ticket)を申請することです.まず、B/Sアーキテクチャの用途を話します.
B/Sアーキテクチャのアプリケーションシーンでは、CASの動作原理を知っているはずですが、実際にエージェントを使わなくてもアプリケーション全体の環境の動作に影響を与えません.各アプリケーションがCAS Clientを実現すれば、自動的にCASサービス側に行って手形を申請しますが、エージェントモデルを使用するとアプリにどのような変更がありますか?実は簡単で、CASクライアントのソースコードを見ることでその理由がわかります.APPがCASクライアントを実現するには少なくとも2つのFilterを追加する必要があります.1つ目は認証Filterです.そのFilterの中にはセッションにAssertionオブジェクトがあるかどうかをチェックするものがあります.もしあれば終了すると、CASサーバにリダイレクトして認証を行い、認証後にAPPに戻って手形の両替を行います.プロセス全体は問題ありませんが、このFilterを見てください.要求パラメータにticketがある場合も同様にこのFilterを終了します.つまり、アプリにアクセスする際にパラメータにticketがある場合は、直接手形検証Filterに到着し、検証手形のFilterでは最下位で行うということです.よく考えてみると、このプロセスは2つのリダイレクトのプロセスを省くことができます.では、パフォーマンスの向上はどれくらい必要ですか.最も典型的な例は、ユーザー個人portalであり、ユーザーがCAS認証を経てportalに入った後、portalを通じて他の業務にアクセスすると、アクセスする前に、portalがアクセスされた業務の代わりに手形(PT)に申請し、ticketをパラメータとしてアクセスされた業務に渡されると、アクセスされた業務が直接手形検証Filterを行い、どんなに完璧なプロセスであるかである.
次に、エージェント・モードがC/Sアーキテクチャのプログラムに与えるメリットについて説明します.
最初にCASはC/Sアーキテクチャプログラムをサポートしていません.CASは手形に基づいて認証されているため、手形(TGC)はCOOKIEに格納されているため、C/SプログラムはまずCASの認証インタフェースを実現できないが、CASの手形検証インタフェースを実現することができる.C/Sプログラムを統合すると、ユーザーはまずブラウザでPortalにログインしてCASの検証を経て、PortalでリソースにアクセスしてSSOの効果を達成し、統合されたC/Sプログラムが実CASの手形認証インタフェースが現れて、それでは訪問する時普通はアカウント/パスワードを提供して、PTはC/Sプログラムのパスワードに取って代わって、使い捨てのパスワードとして使って、これによってユーザーの需要を満たしてC/Sプログラムの単点登録を実現して、これもとてもきれいな1つの流れです
詳細設定
最後に,CASのエージェントモードはC/Sプログラムのみにサービスするものではなく,B/Sプログラムに与えるメリットも刺激的である.CASエージェントモード全体の構成は伝説ほど複雑ではありません.
環境:合計3つのエンジニアリング(CASサービスシステム、エージェントシステム(cas-client-proxy)、一般ビジネスシステム(cas-client)
cas-client-proxyとcas-clientはCASクライアント、cas-client-proxyのwebを実現しなければならない.xml構成は
Filter:
CAS Authentication Filter
org.jasig.cas.client.authentication.AuthenticationFilter
casServerLoginUrl
http://localhost:8080/cas/login
serverName
http://localhost:8080
検証手形Filterを追加:
CAS Validation Filter org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter casServerUrlPrefix http://localhost:8080/cas serverName http://localhost:8080 proxyReceptorUrl /proxyCallback proxyCallbackUrl http://localhost:8080/cas-client-proxy/proxyCallback
Filter:
CAS HttpServletRequest Wrapper Filter
org.jasig.cas.client.util.HttpServletRequestWrapperFilter
CAS Assertion Thread Local Filter
org.jasig.cas.client.util.AssertionThreadLocalFilter
検証手形Filterで落札された赤い2つのパラメータは、このアプリがエージェントモードにされているかどうかを決定する鍵です.
proxyCallbackUrlパラメータは、絶対パスであるPGTチケットを受信するアドレスを表す
proxyReceptorUrl:トレースコードを経て、パラメータが空でない場合、パラメータ値が示す絶対URL、すなわちproxyCallbackUrl値を取り出します.
以上の情報を設定したら、filter-mappingで「proxyCallbackUrl」にurlマッピングを追加することを覚えておいてください.
CAS Validation Filter
/proxyCallback
proxyCallbackという接尾辞のurlにアクセスすると、手形検証Filterに入ることを示します.
注意しなければならないのは、アプリケーションが単一のログアウト機能を統合している場合、単一のログアウトfilter-mappingは一番前に置くべきで、次にこれです.
構成全体が完了しました
PTの取得
キーコード:
Assertion assertion = (Assertion) session.getAttribute(CONST_CAS_ASSERTION));
String pt = assertion.getPrincipal().getProxyTicketFor(service);パラメータサービスはエージェントされるビジネス・システム・アドレスであり、サービス・パラメータには最後にCASクライアント・エージェントを追跡した後、ビジネス・システムがチケットを検証するときに送信されるサービス・パラメータの後ろに反スラッシュがあることが分かったため、「/」が必要であることに注意してください.
一般的なビジネスシステムの構成は基本的に似ていますが、検証手形Filterでは異なり、一般的なビジネスシステムがエージェントモードとして再実行する必要がない場合は、proxyCallback UrlとproxyReceptorUrlパラメータを削除して追加できます.
acceptAnyProxy
true
プロキシ手形による検証として表示されます.
OK、全体の配置は完成して、今実験をすることができて、もし普通の業務の住所は"http://localhost:8080/cas-client/」は、まずportalシステムを行い、それからassertionオブジェクトを通じてPT手形を申請し、それから新しいブラウザを開き、cas-clientのアドレスを入力し、後にパラメータ「ticket=PT-xxx-cas」を追加し、通常は直接システムに入ることができ、ブラウザがリダイレクトしていない動作を感じることができます.
注意:テストのためにhttpプロトコルを使用していますが、httpを使用するにはCASサービスシステムの2つの場所を変更する必要があります.
1:変更するxmlファイル、cookieSecureをfalseに変更
2:deployerConfigContext.を修正するxmlファイル、authenticationHandlersプロパティ、
p:httpClient-ref="httpClient" p:requireSecure="false"/>
赤の属性を追加します.