web-dev-qa-db-ja.com

Javaを使用した異なるドメインでのシングルサインオン[SSO]

異なるドメインと異なるサーバーでホストされている複数のアプリケーションにシングルサインオン[SSO]を実装しています。

enter image description here

写真に示されているように、LDAPと実際に対話してユーザーを認証する認証サーバーを導入しています。 Authenticate Serverと使用/通信するアプリケーションは、異なるサーバーとドメインでホストされます。

sSOの場合、セッション変数は使用できません。サーバーやアプリケーション、ドメインが異なるため、ドメインレベルのCookie /セッション変数は役に立ちません。

私はそれらの間でSSOに使用できるより良いソリューションを探しています。実証済みの実装はありますか？もしそうなら、それを投稿するか、このための正しい方向に私を向けてください。

javaauthenticationservletssingle-sign-onmultiple-domains
22
Reddy

これは、すべてのログインを認証サーバーで実行することで実現できます。他のアプリケーションは、バックチャネルを介して認証サーバーと通信できます。一般的な原則は次のとおりです。

  1. ユーザーがアプリケーション1にアクセスします。
  2. アプリケーション1はユーザーがサインオンする必要があるため、バックチャネルを介して認証サーバーにトークンを送信します。次に、アプリケーション1は、リクエストのパラメーターとしてトークンを使用して、ユーザーを認証サーバーのログインページにリダイレクトします。
  3. ユーザーが認証サーバーにログインします。認証サーバーはCookieを設定し、トークンを認証済みとしてフラグを立て、ユーザーの詳細をそれに関連付けます。次に、認証サーバーはユーザーをアプリケーション1にリダイレクトします。
  4. アプリケーション1は、ユーザーからリクエストを取得し、バックチャネル経由で認証サーバーを呼び出して、トークンに問題がないかどうかを確認します。ユーザーの詳細を含む認証サーバーの応答。
  5. これで、アプリケーション1は、ユーザーが承認され、基本的なユーザー詳細を持っていることを認識します。

これがSSOビットの出番です。

  1. ユーザーがアプリケーションにアクセス2。
  2. アプリケーション2では、ユーザーがサインオンする必要があるため、バックチャネルを介して認証サーバーにトークンを送信します。次に、アプリケーション2は、リクエストのパラメーターとしてトークンを使用して、ユーザーを認証サーバーのログインページにリダイレクトします。
  3. Authサーバーは、Cookieに有効なログがあることを確認するため、ユーザーが既に認証されていることと、ユーザーが誰であるかを知ることができます。認証サーバーはトークンに認証済みのフラグを立て、ユーザーの詳細をそれに関連付けます。次に、認証サーバーはユーザーをアプリケーション2にリダイレクトします。
  4. アプリケーション2はユーザーから要求を取得し、バックチャネル経由で認証サーバーを呼び出して、トークンがOKかどうかを確認します。ユーザーの詳細を含む認証サーバーの応答。
  5. これで、アプリケーション2はユーザーが承認されていることを認識し、基本的なユーザー詳細がいくつかあります。

[〜＃〜] cas [〜＃〜] （Central Authentication Service）など、このメソッドにはいくつかの既存の実装があります。 CASは、すぐに Spring Security でサポートされることに注意してください。独自の実装を作成するのは難しいため、既存の実装を使用することをお勧めします。私は答えを単純化しましたが、これが初めての場合はセキュリティホールを導入する可能性がたくさんあります。

38
Qwerky

OAuthをチェックすることをお勧めします。これは、facebook、google、windows liveなどを含むいくつかの大規模な組織で使用される優れた認証および承認プロトコルです。最初の学習曲線がありますが、製品グレードのソリューションです。

また、Java、Ruby、PHP、および他のプログラミング言語の範囲用のライブラリもあります。

たとえば、次のサーバー側の実装はJavaで利用できます。

  • Apache Amber（ドラフト22）
  • OAuthのSpring Security
  • Apis Authorization Server（v2-31）
  • Restlet Framework（ドラフト30）
  • Apache CXF

次のクライアント側Javaライブラリも利用可能です：

  • Apache Amber（ドラフト22）
  • 春のソーシャル
  • OAuthのSpring Security
  • Restlet Framework（ドラフト30）

詳細については、こちらを参照してください。

3
Gursev Kalra

大きな問題は、シングルサインオンをどのように実装するかです。多くのオープンソースや独自の（IBM Tivoli）製品は、その価値があり、クロスドメインのシングルサインオン機能を提供しています。これは、クロスドメインSSOを実装する最も簡単で最良の方法です。選択したssoサーバーで使用するLDAPサーバーを構成できます。

たとえば、オープンssoを例にとると、クロスドメインシングルサインオンを構成するための記事があります http://docs.Oracle.com/cd/E19681-01/820-5816/aeabl/index.html

オープンssoでLDAPを構成するには、 http://docs.Oracle.com/cd/E19316-01/820-3886/ghtmw/index.html

問題に関するリファレンスは、ここのきちんとした図に示されています http://docs.Oracle.com/cd/E19575-01/820-3746/gipjl/index.html

使用するオファリングに応じて、クロスドメインシングルサインオンを構成できます。

これにより、図は次のようになります。認証サーバーは、選択したssoサーバーと対話するためのユーティリティです。

Ssoと通信する認証サーバーを持つことは、健全なアーキテクチャの原則です。異なるアプリケーションからhttp経由で呼び出すことができるREstエンドポイントとして認証するための呼び出しを行うことをお勧めします。

Cross Domain single sign on

1
Ravi