SSO Cookie ログインの分析と PHP での実装

SSOとは何ですか?

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

SSO の使用:

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

SSO のメリット:

ユーザーの利便性: という観点から検討してください。実際のユーザー利用状況

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

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

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

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

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

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

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

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

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

共有Cookie

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

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

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

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

a. ユーザーが特定のサブシステムにアクセスし、ログインしていない場合はジャンプするように誘導されます。 SSO ログイン ページに移動します。
b. SSO がログインしているかどうかを確認します。
ログインしている場合は、認証チケットを返します。 、認証が成功すると、コールバック アドレスに移動して認証チケットを返します。e. サブシステムはチケットを取得し、SSO を呼び出してユーザー UID とその他の情報を取得し、成功後にユーザーがログインできるようにします。

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

Cookie ドメイン

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

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

栗:

www.cookieexm.com にアクセスすると、サーバーが戻りヘッダーに 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 メソッドなどを介して、SSO システムがログイン URL を返すときに検証する必要があるパラメータを md5 で暗号化し、最後にシステムがトークンとともに返す必要があります。ログインを免除するには信頼関係を検証し、このトークンを SSO システムに渡す必要があります。SSO システムはトークンを検証することで情報が変更されたかどうかを識別できます

最後の質問については、ホワイトリストを通じて対処できます。簡単に言うと、ホワイトリストにあるシステムだけが本番の信頼関係を要求できます。同様に、ホワイトリストにあるシステムだけが本番の信頼関係を要求できます。

PHP での SSO Cookie ログイン分析と実装に関連するその他の記事については、PHP 中国語 Web サイトに注目してください。