2

私は、私たちが作成した 3 つの異なる Web アプリケーションのSSOソリューションに取り組み始めており、同じクライアント用に維持しています。

つまり、3つすべてが、基本的な安らかなAPIサービスを提供する4番目の個別のアプリケーションを介して、ユーザーとログイン情報を同じ場所に保存します. これは基本的に、ログインしようとすると、このユーザー名とパスワードが正しいかどうかを尋ねる残りのサービスを実際に呼び出すことを意味します。

ある意味では、この 4 番目の安らかなものは、私たちが必要とする仕事の少なくとも半分を既に果たしています。

ここで必要なのは、ユーザーが Web アプリ A にログインし、リンクをたどって (または単純にその URL を入力して) Web アプリ B にアクセスし (または単純にその URL を入力して)、既にログに記録されている(またはその逆) にアクセスできるようにする方法です。

私はCASやopenID、さらにはoauthについてたくさん読んできましたが、それについて本当に決心することはできません。このパターンは集中型ですか？分散型？

私の 10,000 フィートのビューは、この「不足している機能」を安静な API サーバーに追加する必要があることを示唆しています。

しかし、どのように？

ps: これら 3 つは完全に分離されています。異なるマシンにデプロイされています (そのうちの 2 つは GlassFish で実行され、もう 1 つは Tomcat で実行されます)。異なるドメインも。

pps: それらはすべてスプリング駆動の Web アプリケーションです (したがって、spring-securityを使用します)

ppps: 今日の時点で、私たちの restul API を使用している他の Web アプリケーションがあります (非スプリング、非 Java)。この sso ソリューションは、それらを処理する準備ができている必要がある場合があります。

4

2 に答える 2

4

ええ、一元化された資格情報リポジトリだけでなく、「真の」シングル サインオン システムが必要なようです。あなたが述べたように、いくつかのオプションがあります：

  1. OpenId - ユーザーがサード パーティによって管理されている資格情報を使用してシステムにログインできるようにするインターネット タイプのアプリケーションにより適しています。Stackoverflow は典型的な例です。Googleアカウントなどでサインインできます。

  2. Oauth は疑似認証と sso を提供します。一方、OpenId は「これはユーザー x です」と言い、oauth は「このユーザーは x の情報にアクセスできる」と言うので、ユーザーが x であると想定できます。

  3. CAS、Cloudseal、OpenAMなどはすべて真のシングル サインオンを提供し、イントラネットまたはエクストラネット環境に適しています。CAS と Cloudseal は特に優れた Spring サポートを備えています。

于 2012-04-16T14:52:57.117 に答える
0
  • 信頼できるサイト (ホワイト リストの証明書利用者 (RP) - この場合はアプリ a、b、c) は、リターン URL を使用してメイン サイト (プロバイダー - 「4 番目の個別のアプリケーション」) に要求 (リダイレクト) を行います。
  • メイン サイトは、リクエスト (returnURL) がドメインのホワイト リストからのものであることを確認します
  • ユーザーをログに記録し (ログに記録されていない場合は、ログイン フォームを表示)、ユーザーをデータベースにログイン済みとしてマークし、一時トークンをユーザー データベースに追加します。
  • トークンを使用してメイン サイトを RP に戻す (リダイレクトする)。
  • RP はトークンを使用してデータベースを調べ、ユーザーをログに記録し、トークンを削除します。

SSOff も簡単です。ユーザー データベースへのすべてのリクエストを bool レコード (userLogged) にチェックするだけです。リダイレクトなし。ログアウト時にレコード (userLogged) を false に変更するだけで、すべてのサイトが認識します。

于 2012-05-04T15:03:42.270 に答える