CAS は SSO シングルサインオン原則を実装します

1. CAS の概要

1.1.CAS とは何ですか?

CAS (Central Authentication Service) は、イェール大学によって開始されたエンタープライズレベルのオープンソースプロジェクトで、Web アプリケーションシステムに信頼性の高いシングルサインオンソリューション (Web SSO に属する) を提供することを目的としています。

CAS は 2001 年に開始され、2004 年 12 月に正式に JA-SIG のプロジェクトとなりました。

1.2. 主な機能

1. オープンソースのマルチプロトコル SSO ソリューション; プロトコル: カスタムプロトコル、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0 など。

2. 複数の認証メカニズムをサポートします: Active Directory、JAAS、JDBC、LDAP、X.509 証明書など。

3. サポートされる認証プロトコルを実装するためにチケットを使用します。どのサービスがサービスチケット (サービスチケット) を要求および検証できるか。

5. 高可用性の提供: TicketRegistry コンポーネントに認証済みステータスデータを保存することにより、これらのコンポーネントの多くは、BerkleyDB、Default、EhcacheTicketRegistry などの分散環境をサポートする実装を備えています。、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry など

6 さまざまなクライアントをサポートします: Java、.Net、PHP、Perl、Apache、uPortal など。

2.SSO シングルサインオンの原則

この記事の内容は主に Web SSO を対象としています。

2.1. SSO とは

シングルサインオン (SSO) は、現在エンタープライズビジネス統合に役立つ最も一般的なソリューションの 1 つであり、ユーザーは複数のアプリケーションシステムにログインするだけで、相互に信頼されているすべてのアプリケーションシステムに一度にアクセスできます。

2.2. SSO の原則

2.2.1. SSO システムの役割

一般に、SSO システムには 3 つの主要な役割があります:

1. Web アプリケーション (複数)

3. SSO 認証センター (1)

2.2.2. SSO 実装モデルの原則

SSO 実装モデルには、一般に次の 3 つの原則が含まれます:

1. すべての認証ログインは SSO 認証センターで実行されます。 SSO 認証センターは、いくつかの方法を使用して、現在のアクセスユーザーが認証されたユーザーであるかどうかを Web アプリケーションに伝えます。つまり、Web アプリケーションは認証センターを信頼する必要があります。。 (単一信頼点)

2.2.3. SSO の主な実装方法

SSO の主な実装方法は次のとおりです:

1. 共有 Cookie

同一ドメインの共有に基づく Cookie は、初期に使用された方法です。さらに、Cookie 自体はクロスドメインではありませんが、クロスドメインの問題に関しては、同じドメイン名の閲覧間で Cookie を自動的に転送するメカニズムを使用しています。これらを使用して、クロスドメイン SSO を実装できます。例: プロキシ、SSO トークン値の公開など。

短所: 柔軟性が低く、安全上の危険が多いため、放棄されました。

2. Broker-based（ブローカーベース）

この技術の特徴は、一元的な認証とユーザーアカウント管理サーバーを備えていることです。ブローカーは、さらなるリクエストに使用される電子 ID アクセスを提供します。中央データベースの使用により、管理コストが削減され、認証のための公的で独立した「第三者」が提供されます。たとえば、Kerberos、Sesame、IBM KryptoKnight (資格情報ライブラリのアイデア) などです。 Kerberos は、MIT によって発明されたセキュリティ認証サービスであり、UNIX および Windows のデフォルトのセキュリティ認証サービスとしてオペレーティングシステムに統合されています。

3. エージェントベース

このソリューションには、さまざまなアプリケーションのユーザーを自動的に認証するエージェントがあります。このエージェントはさまざまな機能を備えて設計する必要があります。たとえば、パスワードテーブルや暗号化キーを使用して、認証の負担をユーザーから自動的に移すことができます。エージェントはサーバー上に配置され、サーバーの認証システムとクライアントの認証方法の間の「トランスレーター」として機能します。例えばSSHなど。

4. トークンベース

例えば、FTPやメールサーバーのログイン認証など、現在広く使われているパスワード認証を実現するシンプルで使いやすい方法です。複数のアプリケーションで。

5. ゲートウェイに基づく

6. SAML に基づく

SAML (Security Assertion Markup Language) の出現により、SSO が大幅に簡素化され、SSO 実装標準として OASIS によって承認されました。オープンソース組織 OpenSAML は SAML 仕様を実装しています。

3. CAS の基本原則

3.1. 構造システム

構造システムの観点から見ると、CAS は CAS サーバーと CAS クライアントの 2 つの部分で構成されます。

3.1.1.CAS サーバー

CAS サーバーはユーザーの認証を完了する責任があり、CAS サーバーはユーザー名/パスワード (認証情報) などの認証情報を処理する必要があります。

3.1.2.CAS クライアント

は、クライアントの保護されたリソースへのアクセス要求を処理する責任を負い、要求者を認証する必要がある場合、認証のために CAS サーバーにリダイレクトされます。 (原則として、クライアントアプリケーションはユーザー名やパスワードなどの資格情報を受け入れなくなります)。

CAS クライアントは、フィルターモードで保護されたリソースを保護するために、保護されたクライアントアプリケーションとともにデプロイされます。

3.2. CAS の原則とプロトコル

3.2.1. 基本モード

基本モードの SSO アクセスプロセスには主に次の手順があります:

1. サービスへのアクセス: SSO クライアントは、提供されるサービスリソースにアクセスするためのリクエストを送信します。アプリケーションシステム。

2. ダイレクト認証: SSO クライアントはユーザーのリクエストを SSO サーバーにリダイレクトします。

3. ユーザー認証: ユーザーの身元認証。

4. チケットの発行: SSO サーバーはランダムなサービスチケットを生成します。

5. チケットの検証: SSO サーバーはサービスチケットの有効性を検証し、検証に合格すると、クライアントはサービスへのアクセスを許可されます。

6. ユーザー情報の送信: SSO サーバーはチケットを検証した後、ユーザー認証結果情報をクライアントに送信します。

以下は CAS の最も基本的なプロトコルプロセスです:

CAS は SSO シングルサインオンの原則を実装します_PHP チュートリアル

基本プロトコル図

上に示すように: CAS クライアントは保護されたクライアントアプリケーションと一緒に展開され、保護された Web アプリケーションはによって保護されます。メソッドリソースをフィルタリングし、クライアントからのすべての Web リクエストをフィルタリングします。同時に、CAS クライアントは HTTP リクエストにリクエストサービスチケット (上の ST の図のチケット) が含まれているかどうかを分析します。含まれていない場合は、ユーザーがサービスチケットを受け取っていないことを意味します。認証されるため、CAS クライアントはユーザー要求を CAS サーバーにリダイレクトし (ステップ 2)、サービス (アクセス先リソースアドレス) を渡します。ステップ 3 はユーザー認証プロセスです。ユーザーが正しい資格情報を提供した場合、CAS サーバーは、かなりの長さの、一意で偽造不可能なサービスチケットをランダムに生成し、将来の検証のためにキャッシュし、ユーザーをサービスのアドレスにリダイレクトします。サービスチケット（サービスチケットを生成したばかり））、クライアントブラウザにチケット許可 Cookie（TGC）を設定します。CAS クライアントはサービスと新しく生成されたチケットを取得した後、ステップ 5 とステップ 6 で CAS サーバーとの ID 検証を実行して、合法的なサービスチケット。

このプロトコルでは、CAS サーバーとのすべてのやり取りで SSL プロトコルが採用され、ST と TGC のセキュリティが確保されます。プロトコルの作業プロセス中に 2 つのリダイレクトプロセスが発生します。ただし、CAS クライアントと CAS サーバーの間のチケット検証プロセスは、ユーザーに対して透過的です (HttpsURLConnection を使用)。

CAS リクエストの認証シーケンス図は次のとおりです:

CAS は SSO シングルサインオンの原則を実装します_PHP チュートリアル

3.2.1. CAS が SSO を実装する方法

ユーザーが別のアプリケーションのサービスにアクセスし、再び CAS サーバーにリダイレクトされると、CAS サーバーはこの TGC Cookie をアクティブに取得し、次のことを実行します。

1) ユーザーが TGC を保持しており、有効期限が切れていない場合は、基本プロトコル図のステップ 4 に進み、SSO 効果を実現します。

2) TGC の有効期限が切れても、ユーザーは引き続き再認証する必要があります (基本プロトコル図のステップ 3 を実行してください)。

3.2.2.CAS プロキシモード

このモードの形式は、ユーザーが App1 にアクセスし、App1 が App2 に依存して情報を取得するというものです (ユーザー -->App1 -->App2 など)。

この場合、ユーザーエクスペリエンスに影響を与えないように (過剰なリダイレクトによりユーザーの IE ウィンドウが点滅し続けるため)、App2 もアクセスする前にユーザーを認証する必要があると想定し、CAS はプロキシ認証メカニズムを導入します。 CAS クライアントは、ユーザーが他の Web アプリケーションにアクセスするためのプロキシとして機能します。

プロキシの前提条件は、CAS クライアントがユーザーの ID 情報 (資格情報と同様) を持っている必要があるということです。前に説明した TGC は、ユーザーの ID 情報のために保持される資格情報です。ここでの PGT は、ユーザーの ID 情報のために CAS クライアントによって保持される資格情報です。 TGC を使用すると、ユーザーはパスワードを入力せずに他のサービスにアクセスするためのサービスチケットを取得できるため、PGT を使用すると、Web アプリケーションがユーザーを代理して、フロントエンドユーザーの参加なしでバックエンド認証を実現できます。

プロキシアプリケーション (helloService) によって PGT を取得するプロセスは次のとおりです: (注: PGTURL はプロキシサービスを表すために使用され、コールバックリンクです。PGT はプロキシ証明書に相当します。PGTIOU は、プロキシ証明書であり、PGT 関係と関連付けるために使用されます;)

CAS は SSO シングルサインオンの原則を実装します_PHP チュートリアル

上記の CAS プロキシ図に示すように、CAS クライアントは、ST を検証するときに追加の PGT URL (SSL への入り口) を CAS サーバーに提供します。基本プロトコルの最上位にあるため、CAS サーバーは PGT URL を通じて CAS クライアントに PGT を提供できます。

CAS クライアントは PGT (PGTIOU-85…..ti2td) を取得しており、PGT を通じてバックエンド Web アプリケーションを認証できます。

プロキシ認証とサービス提供のプロセスは次のとおりです:

上の図に示すように、プロキシ認証は実際にはステップ 1 と 2 は通常の認証とほとんど変わりません。基本モードの 2 と 2 の唯一の違いは、さらに、プロキシモードでは TGC の代わりに PGT が使用され、サービスチケットの代わりにプロキシチケット (PT) が使用されることです。

3.2.3. 補助命令

CAS の SSO 実装方法は、1 つの Cookie と N つのセッションとして理解できます。 CAS サーバーは Cookie を作成し、それをすべてのアプリケーションの認証に使用して、ユーザーがログインしているかどうかを識別する独自のセッションを作成します。

アプリケーションでユーザーが認証された後、今後ユーザーが同じブラウザーでアプリケーションにアクセスすると、クライアントアプリケーションのフィルターがセッション内のユーザー情報を読み取るため、認証のために CAS サーバーには送信されません。このブラウザで他の Web アプリケーションにアクセスし、クライアントアプリケーションのフィルタがセッション内のユーザー情報を読み取ることができない場合、認証のために CAS サーバーのログインインターフェイスに移動しますが、このとき、CAS サーバーはブラウザのユーザー情報を読み取ります。 Cookie (TGC) はサーバーによって渡されるため、CAS サーバーはユーザーにログインページへのログインを要求しませんが、サービスパラメータに基づいてチケットを生成し、Web アプリケーションと対話してチケットを検証します。

3.3. 用語の説明

CAS システムで設計されたチケットには、TGC、ST、PGT、PGTIOU、PT の 5 種類があります。

?チケット許可 Cookie (TGC): ユーザー ID 認証資格情報を保存する Cookie は、ブラウザと CAS サーバーの間で通信するときにのみ使用されます。 CAS サーバーがユーザーの身元を明らかにするための証明書。

? サービスチケット (ST): サービスの一意の識別コードが CAS サーバーによって発行され (HTTP 送信)、クライアントを通じてビジネスサーバーに到達します。 ;

?プロキシ許可チケット (PGT): CAS サーバーによって ST 資格情報を持つサービスに発行され、ユーザーの特定のサービスをバインドし、CAS サーバーに適用できるようにします。 PT;

?Proxy-Granting Ticket I Owe You (PGTIOU) の取得: この機能は、証明書検証に合格した応答情報を CAS サーバーから CAS クライアントに返すと同時に、PGTIOU に対応する PGT を返します。コールバックリンクを通じて Web アプリケーションに渡されます。 Web アプリケーションは、PGTIOU と PGT 間のマッピング関係のコンテンツテーブルを維持する責任があります。

?プロキシチケット (PT): ターゲットプログラムにアクセスするためのアプリケーションプロキシユーザー ID の資格情報です。

?チケット認可チケット (TGT): KDC の AS によって発行されるチケット認可チケット。つまり、このようなチケットを取得すると、今後、他のさまざまなサービスチケット (ST) を申請する際に、KDC に本人認証情報 (Credentials) を提出する必要がなくなります。

?認証サービス (AS) ----- ----認証サービスの場合、資格情報を要求し、

?チケット認可サービス (TGS) を発行します。----------チケット認証サービスの場合、TGT を要求し、

?KDC (キー配布) を発行します。センター) ---- ------キー発行センター;

4.CAS セキュリティ

CAS セキュリティは SSL のみに依存します。安全なCookieが使用されます。

4.1.TGC/PGT セキュリティ

CAS ユーザーにとって最も重要なことは、TGC が CAS サーバー以外のエンティティによって誤って取得された場合、ハッカーが TGC を見つけてなりすますことができることです。すべての許可されたリソースにアクセスするには、CAS ユーザーである必要があります。 PGT の役割は TGC と同じです。