PHP での SSO Cookie ログインの分析と実装、ssocookie_PHP チュートリアル

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

SSO とは何ですか?

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

SSO の目的:

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

。

SSO の利点:

ユーザーフレンドリー: 実際のユーザー使用の観点から検討してください

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

現在、多くの大手インターネット企業が多くのアプリケーションを提供しています。たとえば、以下は Taobao のスクリーンショットです。

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

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

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

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

アプリケーションシステム開発の簡素化：アプリケーション拡張の観点から検討してください

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

どのように達成するか?

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

Cookieを共有する

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

ただし、この方法にはいくつかの欠点があることが後でわかりました。

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

チケット認証、これが現在採用している方法です

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

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

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


Cookieドメイン

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

にデータを書き込むことができます。

ドメインフィールドは、この 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 にアクセスしてください:

各ステップの機能を個別に見てみましょう:

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.s1.s2 にはこの時点ですでに Cookie があり、Cookie 検証を直接使用するため、SSO 認証にリダイレクトするときにユーザー名を入力する必要がなくなったことです。

上記はシンプルな Cookie ベースのログイン システムです。

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

大量の一時的な信頼データを効率的に保存する方法

情報転送プロセスの改ざんを防ぐ方法

SSO システムにログイン システムとログイン システムを信頼させる方法
最初の質問では、通常、memcached に似た分散キャッシュ ソリューションを使用できます。これにより、スケーラブルなデータ量のメカニズムを提供できるだけでなく、効率的なアクセスも提供できます

2 番目の質問については、デジタル証明書署名または md5 などの方法によるデジタル署名方法が一般に採用されます。これには、SSO システムがログイン URL を返すときに検証する必要があるパラメーターを md5 で暗号化する必要があります。ログインする必要があるシステムが最終的に信頼関係を検証するときに、トークンが SSO システムに渡される必要があります。SSO システムは、トークンを検証することで情報が変更されたかどうかを識別できます。

最後の問題については、ホワイトリストを通じて解決できます。簡単に言うと、ホワイトリストにあるシステムのみが本番信頼関係を要求でき、同様に、ホワイトリストにあるシステムのみがログインから除外されます。

http://www.bkjia.com/PHPjc/1068821.html

www.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/1068821.html技術記事 SSO Cookie ログインの分析と PHP での実装、ssocookie SSO とは何ですか? シングル サインオン SSO (シングル サインオン) は ID 管理の一部です。 SSO のより一般的な定義は次のとおりです: SSO とは...