PHP でのシングルサインオン Cookie の分析と実装-PHPチュートリアル-php.cn

シングルサインオン SSO (シングルサインオン) は ID 管理の一部です。 SSO のより一般的な定義は次のとおりです。 SSO とは、同じサーバー上の異なるアプリケーションの保護されたリソースにアクセスする同じユーザーが 1 回ログインするだけで済むこと、つまり、1 つのアプリケーションでセキュリティ検証に合格した後、保護されたリソースにアクセスできることを意味します。他のアプリケーションでリソースを使用するときに、確認のために再度ログインする必要がなくなりました。この記事が皆さんのお役に立てば幸いです。

SSOとは何ですか?

シングルサインオン SSO (シングルサインオン) は ID 管理の一部です。 SSO のより一般的な定義は次のとおりです。 SSO とは、同じサーバー上の異なるアプリケーションの保護されたリソースにアクセスする同じユーザーが 1 回ログインするだけで済むこと、つまり、1 つのアプリケーションでセキュリティ検証に合格した後、保護されたリソースにアクセスできることを意味します。他のアプリケーションでは、リソースにアクセスするときに、確認のために再度ログインする必要はありません

SSO の使用:

現在のエンタープライズアプリケーション環境には、淘宝網、天猫、愛淘宝網などの多くのアプリケーションシステムが存在します。その他の製品およびオフィスオートメーション（OA）システム、財務管理システム、ファイル管理システム、情報照会システムなど。これらのアプリケーションシステムは企業の情報構築に役立ち、企業に良い利益をもたらします。しかしながら、これらのアプリケーションシステムを利用するのは、ユーザにとって不便である。ユーザーはシステムを使用するたびに、本人確認のためにユーザー名とパスワードを入力する必要があり、アプリケーションシステムごとにユーザーアカウントが異なるため、ユーザーは複数のユーザー名とパスワードのセットを同時に覚えておく必要があります。特に、多数のアプリケーションシステムと多数のユーザーを抱える企業では、この問題は特に顕著です。問題の原因はシステム開発のミスではなく、全体的な計画と統一されたユーザーログインプラットフォームの欠如にあります。SSO テクノロジーを使用すると、上記の問題を解決できます

SSO の利点:

ユーザーの利便性: 考慮してください。実際のユーザー利用の観点から

アプリケーションシステムを利用する際、ユーザーは一度のログインで複数回利用することができます。ユーザーは、ユーザー名とユーザーパスワードを毎回入力する必要がなくなり、複数のユーザー名とユーザーパスワードのセットを覚えておく必要もなくなりました。シングルサインオンプラットフォームは、アプリケーションシステムを使用するユーザーエクスペリエンスを向上させることができます。
管理者にとって便利: 日常のメンテナンスと管理の観点から

現在、多くの大手インターネット企業が多くのアプリケーションを持っています。例えば、以下は淘宝網のスクリーンショットです:

Tmall Juhuasuanの見出しなどは、アプリケーションによってはまったく異なるドメイン名を使用する場合もありますが、タオバオに登録されているすべてのユーザーは同じユーザー名とパスワードのセットを使用し、これらのシステム間で直接切り替えてログインステータスを同期できない場合、エクスペリエンスは非常に悪くなります。別の例として、多くの企業には人事システム、財務システム、勤怠システムなどの多くの社内システムがあります。従業員が 1 つのシステムにログインし、別のシステムにジャンプするためにログインする必要がある場合、非常に不快になります。

これに基づいて、SSO (シングルサインオン) が登場しました。もちろん、この要件を実現する方法はたくさんあります。Cookie を使用するのは、最も簡単な方法の 1 つです。解決する必要がある主な問題は、1 つのドメインの Cookie を他のアプリケーションに転送することはできません。同じドメイン内)?

そのため、Cookie のメカニズムに詳しくない場合は、まず Google で検索して、Cookie がドメインを越えないよう設計されている理由やその他の関連する問題について一般的に理解してください。

システム管理者は、統一されたユーザーアカウントのセットを維持するだけでよく、これは便利で簡単です。対照的に、システム管理者は以前は多数のユーザーアカウントのセットを管理する必要がありました。各アプリケーションシステムには一連のユーザーアカウントがあり、管理に不便をもたらすだけでなく、管理の抜け穴が発生しやすくなります。

アプリケーションシステム開発の簡素化: アプリケーション拡張の観点から検討します

新しいアプリケーションシステムを開発する場合、シングルサインオンプラットフォームのユーザー認証サービスを直接利用して、開発プロセスを簡素化できます。シングルサインオンプラットフォームは、統一された認証基盤を提供することでシングルサインオンを実現します。したがって、アプリケーションシステムはユーザー認証手順を開発する必要がありません。
それを達成するにはどうすればよいですか？

SSOは次の方法で実装できます

共有Cookie

サブシステムがすべて親ドメイン名の下にある場合、ブラウザが同じドメイン名の下にあるように親ドメインの下にCookieを植えることができますCookie を共有することで、Cookie の暗号化および復号化アルゴリズムを通じてユーザーのセッション ID を取得し、SSO を実現できます。

しかし、この方法にはいくつかの欠点があることが分かりました:
a. 同じドメイン名を持つすべてのシステムが SessionID を取得できますが、これは簡単に変更され、安全ではありません
b. ドメイン間で使用することはできません。

チケット検証、現在このアプローチを採用しています

この SSO の実装には次の手順があります:

a. ユーザーが特定のサブシステムにアクセスすると、ログインしていない場合は SSO ログインページに移動するよう指示されます。
b. SSO がすでにログインしているかどうかを確認します。、コールバックアドレスに直接ジャンプし、認証チケットに戻ります。
d. ログインしていない場合は、ユーザー名とパスワードを正しく入力すると、認証が成功してコールバックアドレスにジャンプし、認証チケットを返します。サブシステムはチケットを取得し、SSO を呼び出してユーザー UID およびその他の情報を取得し、成功後にユーザーのログインを許可します。

前に述べたように、Cookie を介して SSO を実装する方法は、主にクロスドメインの問題を解決する方法です。まず、Set-Cookie のドメイン属性について説明します。

Cookie ドメイン

HTTP プロトコルがコンテキストをある程度維持できるようにするために、サーバーは Set-Cookie を応答ヘッダーに追加して、Set の

domain フィールドにデータを書き込むことができます。 -Cookie は、この Cookie が配置されているドメインを示すために使用されます。

チェスト:

サーバーが戻りヘッダーに Set-Cookie を追加し、ドメインが指定されていない場合、この Cookie のデフォルトのドメインは www.cookieexm.com になります。クライアントは、www.cookieexm.com にアクセスしたときにのみ、この Cookie をサーバーに返します。

ドメインを .cookieexm.com として指定すると、クライアントは次のドメイン名にアクセスするときに Cookie を返すことができます: www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com。

したがって、クライアントは Cookie のドメインと最後から一致するという結論が導き出されます。これに基づいて、SSO ログインを実装できます。

Cookieの注意点

はhttpのみに設定されています

ログイン認証情報(チケットやユーザー名など)を含むものは暗号化する必要があります

Cookieには個人データは保存できません

特定ソリューション

次のサブシステム間でシングルサインオンを実装するには、**.a1.a2 **.b1.b2 **.c1.c2 が必要であると仮定します。まず、具体的には認証システム (sso.s1.s2) が必要です。シングルサインインの場合。システムが現在ログインしていないと仮定して、例として www.a1.a2 にアクセスします:

各ステップの役割をそれぞれ見てください:

Request www.a1.a2

www.a1.a2 が受け取りますリクエストでは、ログイン Cookie が保持されているかどうかを確認し、まだログインしていない場合は、SSO 認証センターにリダイレクトされます

SSO にはログインウィンドウが表示され、ユーザーはユーザー名とパスワードを入力します。 SSO システムはユーザー名とパスワードを検証します

このステップが重要です。ログインが成功すると、まず SSO システムの Cookie がクライアントに配置され、同時にユーザーの認証情報がビジネスパーティに渡されます。この転送は明らかであることに注意してください。Cookie (異なるドメイン) を介して、通常は暗号化されたクエリ文字列を介して転送することはできません。

事業者側の認証システムはSSO認証情報を受け取り認証を行い、認証結果のCookieを.a1.a2に書き込みます。この時点でSSO認証は完了します。

ビジネスシステム www.a1 .a2 にリダイレクトします。前の結論から、現時点では、.a1.a2 で終わるすべてのビジネスシステムは、この認証済み Cookie を使用できます

応答

注:
ビジネス認証システムは使用できない場合がありますシステムは SSO 認証からビジネスシステムに直接リダイレクトし、そこに SSO 認証情報を持ち込むことができます。

下の図に示すように、この時点でユーザーが www.b1.b2 アプリケーションにアクセスする場合は、上記の操作を続行します。

www.a1.a2 へのアクセスとの違いは、次の操作が必要ないことです。 SSO 認証にリダイレクトします。この時点では sso.s1.s2 にはすでに Cookie があり、Cookie 検証を直接使用するため、ユーザー名を再度入力します。

上記は、単純な Cookie ベースのログインシステムです。

これらの問題のいくつかは解決する必要があります

大量の一時的な信頼データを効率的に保存する方法
情報転送プロセスの改ざんを防ぐ方法

SSO システムにログインシステムを信頼させる方法ログインシステム

最初の質問では、一般に、memcached に似た分散キャッシュソリューションを使用できます。これにより、スケーラブルなデータ量のメカニズムを提供できるだけでなく、効率的なアクセスも提供できます

2 番目の質問では、デジタル署名方法一般的には、デジタル証明書署名または md5 などの方法を使用して、ログイン URL を返すときに検証する必要があるパラメーターを SSO システムが暗号化し、トークンとともに返す必要があります。ログインを免除する必要があるシステムは信頼関係を検証し、このトークンを SSO システムに渡す必要があります。SSO システムはトークンを検証することで情報が変更されたかどうかを識別できます。最後の問題については、次のように処理できます。簡単に言うと、ホワイトリストにあるシステムのみが運用信頼関係を要求できると同時に、ホワイトリストにあるシステムのみがログインを免除されます。