SSO は、複数のアプリケーション システムにおいて、ユーザーは一度ログインするだけで、相互に信頼されているすべてのアプリケーション システムにアクセスできることを意味します。では、PHP で SSO シングル サインオンを実装するにはどうすればよいでしょうか?次の記事では、シングル サインオン SSO の実装について詳しく説明します。
SSO (Single Sign On)、つまりシングル サインオンは、複数の関連する独立したシステムを制御するアクセス権限の一種です。単一の ID とパスワードで 1 つ以上のシステムにアクセスし、異なるユーザー名やパスワードの使用を回避したり、各システムにシームレスにログインできるように構成したりできます。
大規模システムの場合、シングル サインオンを使用すると、ユーザーの多くのトラブルを軽減できます。 Baidu を例に挙げると、Baidu の下には、Baidu Experience、Baidu Knows、Baidu Library などの多くのサブシステムがあります。これらのシステムを使用する場合、各システムは一度ログインするためにユーザー名とパスワードを入力する必要があります。ユーザーエクスペリエンスは確実に低下します。
SSO と対話する要素は 2 つあります: 1. ユーザー、2. システム。その特徴は次のとおりです: 1 つのログイン、すべてのアクセス。 SSO はアクセス制御の一種であり、ユーザーがログインできるかどうか、つまりユーザーの身元を確認するかどうかを制御し、その他すべてのシステム認証はここで実行されます。SSO をシステム全体レベルで見ると、その核心は次の 3 つの要素です。 1. ユーザー、2. システム、3. 認証センター。
弊社のサイトが次の場合展開されているドメイン名:
両方のサイトが同じドメイン onmpw.com を共有しています。
デフォルトでは、ブラウザは Cookie が属するドメインに対応するホストを送信します。つまり、sub1.onmpw.com からの Cookie のデフォルト ドメインは .sub1.onmpw.com です。したがって、sub2.onmpw.com は、sub1.onmpw.com に属する Cookie 情報を取得しません。それらは異なるホスト上にあり、サブドメインも異なるためです。
setcookie(‘token’, ’xxx’, '/', ’.onmpw.com’);复制代码
sub2.onmpw.com システムにアクセスすると、ブラウザはリクエストとともに Cookie 内の情報トークンを sub2.onmpw.com システムに送信します。このとき、システムはまずセッションにログインしているかどうかを確認します。ログインしていない場合は、Cookie 内のトークンを検証して自動ログインを実現します。
sub2.onmpw.com ログインに成功した後、セッション情報を書き込みます。今後の検証のために、独自のセッション情報を使用して検証してください。
ここで問題が発生します。sub1 システムがログアウトした後、自身のセッション情報と所属するドメイン .onmpw .com Cookie 情報。サブ2システムのセッション情報はクリアされません。そのsub2はまだログインしています。つまり、この方法ではシングルサインオンは実現できますが、同時ログアウトは実現できません。その理由は、sub1 と sub2 は setcookie 関数の設定を通じて Cookie を共有できますが、それらの sessionId が異なり、この sessionId もブラウザーに Cookie の形式で保存されますが、それが属するドメインが .onmpw ではないためです。 .com。
それでは、この問題をどうやって解決すればいいのでしょうか?この場合、2 つのシステムの sessionId が同じである限り、この問題は解決できることがわかります。つまり、sessionId を格納する Cookie が属するドメインも .onmpw.com になります。 PHP では、session_start() が呼び出された後に sessionId が生成されます。 sub1 と sub2 に同じ sessionId を持たせたい場合は、session_start() の前に sessionId が属するドメインを設定する必要があります:
ini_set('session.cookie_path', '/');
ini_set('session.cookie_domain', '.onmpw.com');
ini_set('session.cookie_lifetime', '0');复制代码
- #1。上記の手順により、次のことができます。異なる第 2 レベルのドメイン名を実現する シングル サインオンとサインアウト。
- 2. ただし、さらに簡略化することもできます。たとえば、sessionId が同じであることを確認することで、異なる第 2 レベル ドメイン名のシングル サインオンとログアウトを実現できます。
- 参考記事: https://www.onmpw.com/tm/xwzj/network_145.html
次のステーション
上記の解決策は機能しません。
#現在、オープン ソースの SSO ソリューションが github にあります。実装原理は、メインストリーム SSO の実装原理と似ています: https://github.com/jasny/sso# #核となる原則:
同じルート ドメイン名がドメイン ルート ドメイン名を指定していない場合、最初の認証が必要です毎回認証サービスにジャンプする必要がありますが、ドメインを指定すると、同じルート ドメイン名のいずれかが正常に認証されていれば、その Cookie を共有できます。次回からは、ユーザー情報を直接リクエストできます。
A への最初の訪問:
B への 2 回目の訪問:
。その後、ユーザーがシステム アプリケーションにアクセスするときに、すべてのアプリケーション リクエストにログインするかどうかを認証センターに確認することは不可能であり、これは非常に非効率であり、単一の Web アプリケーションでは考慮する必要がありません。 システム アプリケーションとユーザーのブラウザの間に
ローカル セッションを確立できます。ローカル セッションは、クライアントとシステム アプリケーションのログイン ステータスを維持します。ローカル セッションはグローバル セッションに依存します。グローバル セッションが消滅し、ローカル セッションも消滅する必要があります。 ユーザーがアプリケーションにアクセスすると、まずローカル セッションが存在するかどうかが確認されます。存在する場合は、ログインしているとみなされ、確認のために認証センターに行く必要はありません。存在しない場合、
はグローバル セッションが存在するかどうかを判断するために認証センターにリダイレクトされます。存在する場合、アプリケーションに通知され、アプリケーションとクライアントはローカル セッションを確立します。次回申請が要求されるとき、申請は認証センターに行って確認する必要はありません。
2.2 終了認証センターは終了通知を受信後、グローバルセッションを終了することができ、ユーザーが他のアプリケーションにアクセスするとログアウト状態が表示されます。
ローカル セッションを確立しているすべてのサブシステムに直ちに通知し、ローカル セッションを破棄する必要があるかどうかは、実際のプロジェクトに応じて決定できます。推奨学習: 「PHP ビデオ チュートリアル
以上がPHP での SSO シングル サインオンの実装方法の詳細な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
