PHPのシングルサインオンの問題

シングルサインオンをしたところ、問題が発生しました。例えば、システムA、B、Cの3つがある場合、ログインがない場合、Sシステムにジャンプしてログインしてしまいます。ログインが成功すると、 、トークンが生成され、同時にトークンが redis に保存されます。しかし、システム B と C はどのようにしてそのトークンを取得するのでしょうか?

返信内容:

シングルサインオンをしたところ、問題が発生しました。例えば、システムA、B、Cの3つがある場合、ログインがない場合、Sシステムにジャンプしてログインしてしまいます。ログインが成功すると、 、トークンが生成され、同時にトークンが redis に保存されます。しかし、システム B と C はどのようにしてそのトークンを取得するのでしょうか?

この token之后，用curl或者header的方式把值分别发送到另外两个B、C系统的接口中，接口中GET或则POST接收发送过来的token パラメータを取得し、このトークン値を処理します。たとえば、トークン値を Redis、セッションなどに保存します

あなた、redis了，B、C链接上redis然后直接从redisに入金したものをすべて出金してもらえますか？

現在のベストアンサーに反対します。たとえば、シングル サインオンが 100 のシステムへのログインを担当する場合、ユーザーがログインした後、各システムは 99 回要求する必要がありますか?他にシングル サインオンと呼ばれるものは何ですか?

Redis からトークンを直接読み取ると言っている他の人は、どのユーザーがどのキーを読み取るべきか知っていますか?

いわゆるシングル サインオンは、ユーザーが A にログインすると B と C にもログインできるという意味ではなく、S にログインすると A、B、およびC.

したがって、次の 2 つのことが必要です:

1. S システム自体の Cookie/セッション。ユーザーが S システムにログインしている限り (S に直接アクセスする場合でも、A にログインしたいために S にアクセスする場合でも)、そのユーザーの Cookie/セッション。 S システムが生成されます。クロスドメイン処理は必要ありません。

2. ログイン チケット。ユーザーはシステム A から来ています。システム S は、ユーザーがシステム S にログインしているかどうかを判断します。ログインしていない場合は、ログインするように求められます。ログイン後、またはすでにログインしている場合は、固有のチケットが発行されます。チケットが生成され、ユーザーとチケットがデータベースに保存されます。その後、チケットはユーザーのブラウザーを介してシステム A に返され、システム S はユーザーのブラウザーが
にジャンプできるようにします。このとき、システム A はチケットを取得し、内部でシステム S の検証インターフェイスを要求します。システム S はチケットとデータベース内のチケットを比較し、対応するユーザー情報を見つけてシステム A に返します。その後、システム A はユーザーを認識します。ログインしたいのは誰ですか? http://AAA.com/login/callback?ticket=xxxxx

対象者には CAS プロトコル https://apereo.github.io/cas/... を確認することをお勧めします。

採用された回答に反対する理由はたくさんあります。

まず第一に、チケットの発行と検証のプロセスが間違っています（このシステムは通常、単一点障害を防ぐためにデュアルマシンのホットバックアップが必要であるか、分散されています）

他の人が言ったように、100のシステムが100をプッシュすることを意味しますか？タイムアウトなどが発生した場合はどうすればよいですか?
1 つのシステムがログアウトした場合、他のシステムもログアウトする必要がありますか?
権限が変更され、ログイン A のみが許可され、ログイン B が許可されない場合、どうすればよいですか?そうしますか？

クロスドメインの問題はありません。

システム a に入ったら、システム s にジャンプします。
システムがアカウントを検証した後、ブラウザーはチケット (url パラメーター) を使用してシステム a に戻ります。
この時点で、a システムはチケットを受け取りました。
3. システムは、curl などのメソッドを使用して s システムにアクセスし、チケットを検証します (この検証の正当性を証明するには、独自のシステムのキーも持参する必要があります)。 aシステムの)

   で、チケットを認可する(sシステムにログインしてもaシステムにログインできるわけではありません。発行されるチケットのログイン許可はsシステムが判断します)、入力しないと、システムのログイン インターフェイスに戻ります。

投稿者は、特定の Java バージョンのオープンソース シングル サインオン システムをデプロイして、具体的な使用法とプロセスを理解できます。 OAUTH2.0などの認証システムを開発することもできます。

b と c は、ログインに成功した後にリセットするだけのインターフェイスを提供します。

保存と配信に Cookie の使用を検討できます

マスターステーションがログインを完了した後、ログインサーバーがジャンプバックした後のページにクロスドメインコードを追加し、同時にスレーブステーション（または他のサイト）に送信します。コードは次のとおりです

。 リーリー

このようにして、xxx​​xでトークンを取得し、検証を行うことができます

シングルサインオンを簡単に実現できるUCenterまたはOpenCenterの使用をお勧めします

ポスターの意味は次のとおりです: 3 つのシステム、ドメイン間でセッション ID を保存する方法がわかりません。 UCenter または PHP で P3P を使用してクロスドメインを実現することを検討できます。

通常、トークンは何らかの暗号化アルゴリズム + ソルトによって計算されます。B と C は、トークンを受け取るときに同じ暗号化アルゴリズムを使用して検証できます。

トークンはシステム B と C に戻されませんでしたか? Redis に直接接続することができます。標準的なポイントは、パラメーターまたはヘッダーにトークンを配置して、S システムの特別なインターフェイスをリクエストすることです。

、、、、、、、、、