CAS は SSO シングル サインオンの原則を実装します_PHP チュートリアル
- WBOYオリジナル
- 2016-07-12 09:05:501402ブラウズ
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 クライアントは保護されたクライアント アプリケーションと一緒に展開され、保護された 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 リクエストの認証シーケンス図は次のとおりです:
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 プロキシ図に示すように、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 と同じです。
基本モードからわかるように、TGC は CAS サーバーから SSL 経由でエンド ユーザーに送信されるため、CAS のセキュリティを確保するために TGC を傍受することは非常に困難です。
TGT のデフォルトの生存期間は 120 分です。
4.2.ST/PTセキュリティ
ST（サービスチケット）はHTTPを通じて送信されるため、ネットワーク内の他の人は他の人のチケットを盗聴できます。 CAS は、次の側面を通じて ST の安全性を高めます (実際、それらはすべて構成可能です):
1. ST は 1 回のみ使用できます
CAS プロトコルでは、サービス チケットの検証が成功したかどうかに関係なく、CAS は次のように規定されています。サーバーはキャッシュ内のサーバー チケットをクリアし、サービス チケットが 2 回使用されないようにします。
2. ST は一定期間内に期限切れになります
CAS では、ST は一定期間のみ存続できると規定されており、その後、CAS サーバーによって期限切れになります。デフォルトの有効時間は 5 分です。
3. ST は乱数に基づいて生成されます
ST の生成ルールが推測された場合、ハッカーは CAS 認証をバイパスし、対応するサービスに直接アクセスします。
5. 参考文献 1. https://wiki.jasig.org/display/CASUM/概要 2. http://www.jasig.org/cas/protocol/ 3. //www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html 4. http://www.blogjava.net/security/archive/2006/10/02/sso_in_action. 5、http://baike.baidu.com/view/190743.htm
http://www.bkjia.com/PHPjc/1067485.html