既存のアプリケーションを統合していますか、それとも独自のアプリケーションをサポートしたいだけですか?
実際の SSO をお探しですか、それとも単に共有資格情報をお探しですか? SSO は単一のアプリケーションにログインし、その資格情報を別のアプリケーションに伝達します (Gmail にログインして Blogger に自動的にログインするなど)。共有資格情報は、アプリケーション間で同じログイン名とパスワードを使用できますが、資格情報自体は自動的に伝達されません。
LDAP は、共有資格情報の管理に使用される一般的なシステムです。多くのシステムでは、認証ストアを既存の LDAP サーバーに向けることができます。
たとえば、Java EE コンテナに複数のアプリを展開し、さらに電子メール サーバーと Web ベースの電子メール クライアントを展開している場合、これらの多様なアプリケーションのすべてが同じ LDAP サーバーを指すことができ、ユーザーは単一のログインを持つことになります。すべての異なるシステムのパスワード、すべて異なる言語で記述され、すべて異なるマシンに展開されます。これは LDAP のパンとバターの使用例であり、ほとんどすべてのシステムがこれをすぐに処理できます。Glassfish と Tomcat はどちらも、LDAP サーバーに対して容易に検証できます。Apache (Web サーバー)、Postgres (データベース)、Postfix (電子メール) なども同様です。
したがって、単純に共有資格情報が必要な場合は、LDAP サーバーをインストールすることで、今すぐ「無料で」取得できます。LDAP は DBMS のようなものとは少し異なりますが、少し勉強して「理解」すると、非常に便利です。OpenLDAP は一般的な LDAP サーバーですが、私は ApacheDS が好きです。
それをJava EEコンテナに設定する方法は、「レルム」を設定することです。GF と Tomcat は両方とも、すぐに使用できる LDAP レルムを備えています。ただし、Realm を利用するには Java EE セキュリティを使用する必要があります。
ほら、Java EE Realm の詳細は、それがアプリケーションではなく、CONTAINER の側面であるということです。接続プールが、アプリケーションが活用するコンテナー リソースであるのと同じように。ほとんどの人は、セキュリティをアプリケーションの一部にしたいと考えており、セキュリティをより制御できると感じています。
さまざまなアプリケーションの束を取得し始め、すべての人が別々に構成され、個別のユーザー リストやパスワード ポリシーなどを持つまでは、これで問題ありません。
LDAP は、同じ資格情報ストアを使用するようにすべてを構成するため、その多くを修正できます。
Realm は、Java EE サーバーのニーズを満たします。アプリケーションは、コンテナーによって提供される Realm を使用するように構成されています。複数のアプリケーションと 1 つのレルムがある場合、それらはすべてそのレルム内で資格情報を共有できます (レルム タイプに関係なく)。
レルムは、ファイル ベース、データベース ベース、LDAP など、何でもかまいません。コンテナ クラスタの場合、レルムもクラスタ化されます (これは便利です)。
Java EE セキュリティの暗い側面と、ほとんどのアプリがそれを回避する理由は、繰り返しになりますが、Realm はアプリケーションではなくコンテナーの一部であるため、使用するのが少し不格好であり、おそらく必要な機能を提供しない可能性があるためです。ユーザー管理、パスワードポリシーなどに関して。
しかし、Java EE セキュリティの明るい面は、その傘下に入ると、資格情報をコード全体で簡単に活用できることです。ユーザーが Web サイトにログインすると、その資格情報を Web アプリで使用したり、EJB 層 (リモート EJB 層) に自動的に伝播したりできます。情報は常に便利です。
Web アプリケーションをレルム、EJB、Web サービスに向けることができます。それらはすべて同じ部分を活用しています。
両方の長所を活かすには、コンテナー固有のメカニズムを活用してコンテナーのセキュリティにアクセスします。これは、Java EE セキュリティのもう 1 つの暗い側面です。
Realms のようなものや、コンテナー セキュリティへの直接アクセスは、コンテナー間で移植できません。GF と Tomcat は、WebLogic とは異なります。すべて非常に似ていますが、詳細が異なるため、コードをシームレスに移植することはできません。
明るい面は社内アプリの場合です。ほとんどの人は、自分が持っているコンテナーを活用し、コンテナーに依存するコードの周りに合理的な抽象化を配置し、そうです、別のアプリに移動する場合はこれを移植する必要があることに注意して、それを一日と呼びます。容器。しかし、実際には。データベースと同じように、コンテナ プラットフォームが選択されると、人々はそれにぴったりと寄り添い、それに固執する傾向があります。
最後に、サーブレット 3.0 (GF3 および Tomcat 7) では、プログラムによるログインの問題を標準化し、コンテナー間での移植性を高めていますが、基本的な概念は同じです。
さて、SSO。
SSO は別の獣です。しかし、門の外では、GF と Tomcat の両方が Web アプリの SSO をサポートしています。これにより、1 つの Web アプリにログインし、他のアプリにログインしなくても簡単にアクセスできるようになります。ただし、SSO は、アプリケーションの制御下にあるより柔軟なものではなく、コンテナーのセキュリティとそのライフサイクルに大きく依存しているため、少し制限があります。Realms (これは当然のことです) だけでなく、カスタム プログラムによるログインではなく、実際のコンテナ ベースの FORM ログインにも注意してください。FORM ログインは目を見張るものではありませんが、機能的で機能します。Realm を実装し、アプリを Tomcat または GF の単一インスタンス (または GF 3.1 のクラスター) にデプロイすると、無料で SSO を取得できます。バック オフィス アプリケーションのユーザビリティは問題ありませんが、おそらく公共のインターネットではそうではありません。
より洗練された SSO ソリューションが必要な場合は、カスタム実装を検討する必要があります。OpenSSO はその 1 つで、SAML と SAML Web プロファイルに依存しています。ただし、他にもあります。CAS、Atlassian Cloud、Kerberos、および OAuth もあります。これらはすべて、SAML とは異なるプロトコルを使用しています。SAML に固執したい場合は、Shibboleth や SimpleSAML を検討することもできます (SimpleSAML は、とりわけ SAML ID プロバイダーとして機能する PHP サーバーですが、アプリケーション内にサービス プロバイダーが必要です)。
どのプロトコルを選択しても、プロセスは基本的に同じです (詳細はこちら --クロス ドメイン ログイン - あるドメインから別のドメインに転送されたときにユーザーを自動的にログインする方法)。
しかし、悪魔は細部に宿ります。そして、男の子、悪魔はいますか。
これらのシステムはすべて複雑です。SSO は複雑です。たとえば、シングル サイン オンを使用できるようになったので、シングル サイン アウトはどうでしょうか。シングルタイムアウトはどうですか？ユーザーがログインしている間の資格情報の変更はどうなりますか? Web サービスの STS (Secure Token Service) はどうですか? (STS は、Web サービスに対して同様の委任認証メカニズムを提供します。)
SAML は、非常に多くの新しい語彙と多くの構成を紹介します。ドキュメントは優れたものではなく、より高いレベルの一般的なものについて話す標準ドキュメントに大きく依存しているため、簡単には取り上げられません。
本当に必要な SSO が必要ない場合は、中央の LDAP ストアのようなもので満足し、そこから先に進むことができます。
例として、私たちのアプリケーションは DB と LDAP バックエンドの両方をサポートしています。Glassfish と Java EE セキュリティを使用しています。ユーザーエクスペリエンスを完全に制御します。また、SAML 経由の SSO もサポートしています (独自の ID およびサービス プロバイダーを作成しました)。また、コードとサード パーティ コードを使用して、LDAP と SSO を介して Java および他のアプリケーション間で資格情報を共有しています。明るい面は、これがすべて標準ベースであることです。欠点は、標準が英語で伝達され、英語が解釈されることです。
私はこれを単にそれができると言うために言います。シンプルなサーブレット フィルターを使用して、ナプキン SSO 実装の裏で、同じドメインとクロス ドメインの両方 (同じドメインは共有 Cookie でシンプルです) のアドホックも作成しました。パスワード ポリシー、パスワードの回復、キープ アライブ タイマー、複数ウィンドウのタイムアウトとセッション管理 (これはすごいことです)、役割、特権など。
また、Spring と、Spring の上にこれらすべてを提供する Spring Security については触れません。私はそれを使用したことはありません (私は Spring の人ではありません) が、それらの人々は自分が何をしているかを知っているので、一見の価値があります。