Upload
hedy-sanford
View
36
Download
0
Embed Size (px)
DESCRIPTION
CAS の動作について のまとめ - あくまで私家版という立場をくずしませんが -. 名古屋大学 全学技術センター 太田芳博. シングルサインオンの仕組みである CAS の説明。 よくこんな感じで書かれてる。. ブラウザ (ユーザ). sampleapp. 1. 最初のリクエスト. 2. service= url_back_sampleapp_page をつけて, CAS login ページにリダイレクト指示. CAS サーバ. 3 . 2 を 受けて, CAS login ページにアクセス. 4 . CAS login ページを送信. - PowerPoint PPT Presentation
Citation preview
CAS の動作についてのまとめ- あくまで私家版という立場をくずしませんが -
名古屋大学全学技術センター
太田芳博
1. 最初のリクエスト
2. service=url_back_sampleapp_page をつけて, CAS login ページにリダイレクト指示
ブラウザ(ユーザ)
sampleapp
シングルサインオンの仕組みである CAS の説明。よくこんな感じで書かれてる。
3. 2 を受けて, CAS login ページにアクセス
4. CAS login ページを送信
5. username, password を送信
6. 認証 OK なら, (1)CASTGC を発行し, (2)ST をつけて url_back_sampleapp_page に リダイレクト指示 ( CASTGC: CAS Ticket Granting Cookie ST : Service Ticket)
CAS サーバ
7. 6 を受けて, ticket=ST をもって url_back_sampleapp_page へ
8. ST が正しいものか確認 (Validation)
9. ST が正しいならアクセス OK
10 .これでやっと認証後の sampleapp のページを送信
これで分かる人はここで終了です。
実際の動作に照らし合わせるとかなり端折られているので
全体動作を把握するのは(普通は)難しいと思います
1. 最初のリクエスト
2. service=url_back_sampleapp_page をつけて, CAS login ページにリダイレクト指示
ブラウザ(ユーザ)
sampleapp
だって,動作を理解しようとすると 疑問がいっぱい ...( じゃない?)
3. 2 を受けて, CAS login ページにアクセス
4. CAS login ページを送信
5. username, password を送信
6. 認証 OK なら, (1)CASTGC を発行し, (2)ST をつけて url_back_sampleapp_page に リダイレクト指示 ( CASTGC: CAS Ticket Granting Cookie ST : Service Ticket)
CAS サーバ
7. 6 を受けて, ticket=ST をもって sampleapp へ
8. ST が正しいものか確認 (Validation)
9. ST が正しいならアクセス OK
10 .これでやっと認証後の sampleapp のページを送信
CASTGC?ST?
なにそれ?
実際の認証はどう
なってるの?
CAS サーバにリダイレクトするときとしないときがあるけど,どう
判定してるの?
service= ってなに?どこで設定するの?
ST って毎回もっていく
必要があるの?
認証後, sampleapp へアクセスしたときの流れは?
他の CAS アプリにいくときの流れは?
以下は基本的に最初の図をみながら
追っていって下さい。あ,ほとんど字なので
覚悟して下さい。
1 , 2 のやりとりブラウザ(ユーザ)は: sampleapp にアクセスする。( 1の矢印) この 1 の矢印は, sampleapp 内の,認証ロジックへのアクセスになります。 (→ CAS Login ボタンや CAS Login リンクを押したとか。) sampleapp は: 上のアクセスを受けるのは sampleapp に組み込まれた CAS クライアントです。 (アプリをそう作っておきます。) CAS クライアント内で,認証が済んでいないと判定された場合 (*) , 「 CAS サーバへいって来てね。あ,認証後の戻りの URL はここね」と いう情報を含んだレスポンスをブラウザに返します。( 2の矢印) ◎ 「 CAS サーバの URL 」及び「戻りの URL 」は sampleapp 内で指定されています。◎CAS サーバに誘導するのには, HTTP Redirect を使います。 具体的には HTTP レスポンスの Location ヘッダに,以下のように設定されています。 Location: https:// ( CAS サーバの URL)?service=( 戻りの URL) 「戻りの URL 」は単なる URL パラメータ(文字列)として使用されます。
(*) 判定基準はここで説明するとややこしくなるので,最後に!
3 , 4 , 5 のやりとりブラウザ(ユーザ)は: 「 CAS サーバにいけ」と言われたので,素直にアクセスします。( 3の矢印) https:// ( CAS サーバの URL)?service=( 戻りの URL) そこは CAS ログインのフォームページになります。
CAS サーバは: ブラウザに対し,ログインページ(フォーム)データを生成して返します。( 4の矢印)
CAS サーバは,このログインフォーム生成時に,ワンタイムチケット (LT; Login Ticket) を 発行しており, [ 戻りの URL 」 と共に,フォーム内に hidden 属性で埋め込んで ブラウザに渡しています。(当然,この LT も CAS サーバ内で管理されてます。)
ブラウザ(ユーザ)は: 表示されたフォームに Username, Password をいれて CAS サーバに送ります。( 5の矢印) ユーザは意識してませんが,このとき裏で LT や,「戻りの URL 」情報も一緒に送られてます。 (興味のある人は, CAS ログインフォームのソースを見てみて下さい)
◎ ユーザパスワードは, CAS サーバに対してしか送られません。 CAS 的には,これがセキュリティ上,素敵な実装ということになってます。
6 , 7 のやりとりCAS サーバは: ログインフォームから送られてきた情報で,ユーザ認証を行ない, OK ならば いろんな情報をつけてブラウザにレスポンスを返します。( 6の矢印)
1 ) CASTGC (CAS Ticket Granting Cookie) ブラウザに対して, CAS サーバのクッキーとして送ります。 Set-Cookie: CASTGC=TGC-371119-UndB (略) vdVuFrE
2 ) ST (Service Ticket) これも, CAS サーバが発行するワンタイムチケットです。
3 ) 「 ST を持って,戻りの URL に行ってみな」というレスポンスを返します。
ブラウザ(ユーザ)は: CAS サーバに言われた通り, ST を持って,「戻りの URL 」に Redirect で飛びます。 ( 7の矢印)
◎ ここまででの状態としては,「 CAS サーバに無事認証していただいた」ので, あとは sampleapp アプリにも認証したことを理解していただくだけです。もう少し。
8 , 9 , 10 のやりとりsampleapp は: ブラウザから ST つきのアクセスリクエストがきたら,その ST がちゃんと CAS サーバで 認証された結果として発行されたものか, CAS サーバに問い合わせて検証をします。( 8の矢印)
CAS サーバは: ST の情報が,自分が認証 OK として発行したものか検証し, OK なら sampleapp に 「こいつはアクセスさせて OK だよー」というレスポンスを返してやる。( 9の矢印) ここで, sampleapp に,認証したユーザの情報が送られます。 (何が送られるかは CAS サーバの設定次第。)
sampleapp は: CAS サーバからお墨付きが得られたら, ある場所に認証情報を書き込んだ後, ブラウザに対してやっと認証後のページデータを送り,表示させる。( 10の矢印)
× 「『ある場所』ってなんだよ!」 「あとで!」
これでやっと画面が表示されたよ!
説明長かったですね ... 。でも実際にアクセスしてみるとわかりますが,パスワードを入力するところを除けば処理は一瞬です。
積み残しの疑問解決 その 1 :
Q. あれ? CASTGC は使ってないけどいいの?A. 今回の説明では特に使わない。Q. いつ使うの? そもそも必要なの?A. CASTGC は他の CAS 対応アプリに行く時に必要なんだよ。
CASTGC は, CAS サーバで認証されたあと, CAS サーバからブラウザに対して発行される Cookie でした。
例えば,あるアプリ A で認証したあと,別の CAS 対応アプリ B にアクセスした場合,
CASTGC は 図中の 3 の矢印 でのアクセス時に一緒に CAS サーバに送られます。すると ...CAS サーバ側で,「認証済」と判定されます。(→ CAS サーバは,ブラウザに向けて発行した情報管理をしてるからね。)
その場合,アプリ B へのアクセスでは,図中の 4 , 5 の矢印は端折られるので ...CAS ログイン画面は出ない。これが SSO の実現ってことだね !
当然ですが,別の CAS 対応アプリにいった場合, 6 では, CASTGC は二重発行されません。 ST だけ発行されます。
積み残しの疑問解決 その 2 : Q. 1〜 2 の間や, 7〜 10 の間,そして認証完了後のアクセス(図にはないけど, 言うなら 11〜 12 に相当 ? )は動作が違うと思うんだけど, sampleappp 内では どう判定しているの? 動作判定基準は? A. これは, 10 の矢印の説明時に,「あとで」といっておいた所です。 sampleapp に対して, CAS 認証が一度正しく行なわれた後, JSESSIONID が示すセッションに対して,セッション変数(認証情報)が書き込まれ, それをチェックすることで認証済みかどうかを判定しているようです。
つまり, sampleapp の CAS クライアントは,ブラウザから送られてくるJSESSIONID が 示すセッション中に書き込まれたセッション変数をチェックすることで認証済か 未認証かを調べています。
・未認証なら, CAS サーバへ行ってこい,と redirect を出す。 ( 1〜 2 ) ・リクエストに ST がついてたら, CAS サーバに Validate伺いをする。( 7〜 10 ) ※ 適当な ST を指定すると, org.jasig.cas.client.validation.TicketValidationException と言われて蹴られます。 ・認証済みならそのままページを表示する。
このページの記述は以下を参考にしました。 https://groups.google.com/forum/#!msg/jasig-cas-user/qxjqGpHoKNQ/p3xyk8msLUYJ
ほんとうはログアウト時の処理ももう少し詳しく調べて書きたいのですが疲れたので少しだけ。 (おい)ので,このページは,推測も疑問も含まれたままになっています。信用度低。
あるアプリ上に CAS クライアントライブラリで CAS ログアウト処理を実装した時は,CAS サーバ上にある,認証済みの管理情報が消える動作になると思います。このとき,ブラウザの CASTGC までも消すか?というと,消さないような ... 。(←ここ,詳しく調べてません)
ただ,少なくとも CAS サーバ上で管理されてる認証情報が消えれば,ブラウザに残ってる CASTGC は意味がなくなり,それ以上新しい CAS 対応アプリには SSO ログインできなくなります。この残った CASTGC も,ブラウザを終了すると消えるので,まぁ ...
しかし,その場合でも気をつけないといけないのは,ウインドウを開きっぱなしでどっかいっちゃったときとか。例: (ブラウザの種類は同じなのが前提。) 1 ) アプリ A で初期認証。 2 ) アプリ A はそのままおいといて別ウインドウを開き,アプリ B も SSO で利用。 3 ) アプリ B でログアウト。 この状態で,アプリ A のウインドウが開いたままであれば,アプリ A はまだそのまま使える。 (アプリ A 内では,まだ JSESSIONID に認証済の情報が残ってるから。) でも,アプリ B , C, D をもう一度使うにはもう一度認証が必要。 ここで,アプリ A のウインドウをこのままで,最初に認証した人と別の ID でアプリ B にアクセスすると ... ? アプリ A の動作は最初の人で,アプリ B は 2番目の人となってなんかおかしくなるような。 さらに, 2番目の人が,また別ウインドウでアプリ A にアクセスすると ... ? 最初の人が開いていたアプリ A のウインドウはどうなるんでしょ?
とりあえずの結論: CAS ログアウト実装は各アプリに依存するような気がするので, 共用の PC で,席を離れるときは,確実にブラウザを終了しましょう。 終了すれば, CASTGC が消えるから。それが安全。
間違ってるとこがあったら是非是非ご連絡ください。