OpenSSO / OpenAMの代替
警告！私はここで少し釣り旅行に行っています。私が尋ねている質問が完全に意味があるかどうかさえわかりません。あなたの返事に親切にしてください！ :)
私は最近Java + Linux + Tomcat + MySQL）に基づいているプロジェクトを引き継ぎました。現在、システムは基本的にいくつかのcronジョブがバックグラウンドにあるWebサイトですいくつかのデータを移動する、など。優先順位付けされたバックログを開発するために製品マネージャーと協力して、彼が何をしたいかから、サービス指向アーキテクチャー（SOA <-話題のWord警告！）の開発を開始する必要があることは明らかです。最終的には、Webサーバーとアプリケーションサーバーが混在することになります注：Glassfish v3への移行を強く検討しています。
現在、認証と承認はJavaコードで処理され、MySQLデータベースにユーザー情報が保存されています。最低限、これを別の認証に分割する必要があるようです。サービス（それ以外の場合は、ユーザーの認証と承認を処理するために、至る所に大量の重複コードができてしまいます）。
シングルサインオン（SSO）typeソリューションを調査し、いくつかの調査を行っています。私が集めることができるものから、OpenSSOはオラクルによって正式に削除されましたが、ForgeRockによって取り上げられ、現在はOpenAMと呼ばれています。これは私が望んでいるものに非常に近いようですが、すでにMySQLベースのシステムを持っているので、それをサポートするもの（または他の種類のRDBMS）が欲しいです。 Stack Overflowでこれを見つけましたが、基本的にLDAPか何もないことを示しているようです。
OpenSSO/OpenAMに認証と承認のためにデータベースと通信させる方法はありますか？
私の質問は：
OpenSSO/OpenAMには他にどのようなオプションがありますか？ LDAPを使用する方法はありますか？注：「OpenAM vs」のGoogle検索を実行しても、それほど多くの結果は得られません。人々は単に「自分でロール」する傾向がありますか？
私を教育するのに役立つこのトピックに関するどんな考え/提案/リンクも大歓迎されます。お待ちいただき、ありがとうございます。
既存のアプリケーションを統合していますか、それとも独自のアプリケーションをサポートしたいだけですか？
実際のSSOを探していますか、それとも単に共有資格情報を探していますか？ SSOは単一のアプリケーションにログインし、その認証情報を別のアプリケーションに伝播させます（GmailにログインしてBloggerに自動的にログインするなど）。共有資格情報は、アプリケーション間で同じログイン名とパスワードを使用できますが、資格情報自体は自動的に伝播されません。
LDAPは、共有資格情報を管理するために使用される一般的なシステムです。多くのシステムでは、認証ストアを既存のLDAPサーバーにポイントすることができます。
たとえば、Java EEコンテナにデプロイされた複数のアプリがあり、メールサーバーとウェブベースのメールクライアントもある場合、これらの多様なアプリケーションはすべて同じLDAPを指すことができます。サーバーとユーザーは、すべて異なるシステムで1つのログインとパスワードを使用し、すべてが異なる言語で記述され、すべて異なるマシンにデプロイされます。これはLDAPの基本的な使用例であり、ほとんどすべてのシステムでこれを処理できます。 GlassfishとTomcatはどちらもLDAPサーバーに対して簡単に検証できます。Apache（Webサーバー）、Postgres（データベース）、Postfix（メール）なども検証できます。
したがって、単純に共有資格情報が必要な場合は、LDAPサーバーをインストールすることで、今すぐ「無料」で取得できます。 LDAPは、DBMSのようなものとは少し異なる動物ですが、少し勉強して「理解する」と、それは本当に非常に素晴らしいことです。 OpenLDAPは人気のあるLDAPサーバーですが、私はApacheDSには不慣れです。
これをJava EEコンテナに設定する方法は、「レルム」を設定することです。GFとTomcatはどちらもLDAPレルムをそのまま使用できます。他の人がやると思いますが、Java EEセキュリティを使用してレルムを活用する必要があります。
Java= EEレルムの詳細は、それがアプリケーションではなくCONTAINERの一部であることです。接続プールがアプリケーションが利用するコンテナリソースであるように、ほとんどの人がセキュリティを望んでいます。自分のアプリケーションの一部になり、より制御できると感じます。
さまざまなアプリケーションを入手し始め、すべてのユーザーが異なる方法で構成され、個別のユーザーリストやパスワードポリシーなどを持っているまでは、これで問題ありません。
LDAPは、すべて同じクレデンシャルストアを使用するように設定するため、多くの問題を修正できます。
レルムは、Java EEサーバーで必要なものを満たします。アプリケーションは、コンテナーによって提供されるレルムを使用するように構成されます。複数のアプリケーションと1つのレルムがある場合、それらはすべて共有されます。そのレルム内の資格情報（レルムタイプに関係なく）。
レルムは何でもかまいません。ファイルベース、データベースベース、LDAPなどです。コンテナがクラスター化されている場合、レルムもクラスター化されます（これは便利です）。
Java EEセキュリティの欠点、およびほとんどのアプリがこれを回避する理由は、ここでも、レルムはコンテナーではなくアプリケーションの一部であるため、ユーザー管理、パスワードポリシーなどの観点から、必要な機能を使用し、おそらく提供しない。
しかし、Java= EEセキュリティの明るい面は、いったん傘下に入ると、コード全体で資格情報を簡単に活用できることです。ユーザーがWebサイトにログインすると、資格情報はそこでWebアプリで使用するか、EJB層（リモートEJB層は常に）に自動的に伝播して戻すことができ、情報は常に便利です。
Webアプリをレルム、EJB、Webサービスに向けることができます。それらはすべて同じ部分を活用します。
両方の利点を最大限に活用するには、コンテナ固有のメカニズムを活用してコンテナのセキュリティにアクセスします。これは、Java EEセキュリティのもう1つの欠点です。
レルムのようなもの、およびコンテナーのセキュリティへの直接アクセスは、コンテナー間で移植できません。 GFは、Tomcatとは異なりますが、WebLogicとは異なります。非常に近いですが、詳細が異なるため、コードがシームレスに移植されません。
明るい面は社内アプリです。ほとんどの人は、自分の持っているコンテナーを活用し、コンテナー依存コードを合理的に抽象化し、それを呼び出します。別のアプリケーションに移動する場合は、移植する必要があります。容器。しかし、実際には。データベースのように、コンテナプラットフォームが選択されると、人々は密に寄り添い、それに固執する傾向があります。
最後に、サーブレット3.0（GF3およびTomcat 7）は、プログラムによるログインの問題の多くを標準化して、コンテナー間での移植性を高めていますが、基本的な概念は同じです。
さて、SSO。
SSOは別の獣です。ただし、GFとTomcatはどちらもWebアプリのSSOをサポートしています。これにより、1つのWebアプリにログインして、ログインしなくても他のWebアプリに簡単にアクセスできるようになります。しかし、SSOは、アプリケーションの制御下にあるより柔軟なものではなく、コンテナのセキュリティとそのライフサイクルに大きく依存しているため、少し制限されています。レルム（それは当然のこと）だけでなく、実際のカスタムのプログラムによるログインではなく、コンテナベースのFORMログイン。FORMログインは壮観ではありませんが、機能的で機能します。レルムを実装し、アプリをTomcatの単一インスタンスにデプロイするか、GF（またはGF 3.1）のクラスタであり、無料でSSOを取得できるので、それが重要であれば、それは本当にいいことです。バックオフィスアプリの使いやすさは問題ありませんが、おそらく公衆インターネットはそうではありません。 。
より高度なSSOソリューションが必要な場合は、カスタム実装を確認する必要があります。 OpenSSOはその1つであり、SAMLおよびSAML Webプロファイルに依存しています。ただし、他にもあります。 CAS、Atlassian Cloud、Kerberos、およびOAuthもあります。これらはすべてSAMLとは異なるプロトコルを使用しています。SAMLを使いたい場合は、ShibbolethまたはSimpleSAML（SimpleSAML PHP SAML IDプロバイダーとして機能するサーバーですが、アプリケーション内にサービスプロバイダーが必要です）。
どのプロトコルを選択しても、プロセスは基本的に同じです（ここで詳しく説明します クロスドメインログイン-あるドメインから別のドメインに転送されたときにユーザーを自動的にログインさせる方法 ）。
しかし、悪魔は詳細にあります。そして、少年、悪魔がいます。
これらのシステムはすべて複雑です。 SSOは複雑です。たとえば、シングルサインオンを使用している場合、シングルサインアウトはどうでしょうか。シングルタイムアウトはどうですか？ユーザーがログインしている間の資格情報の変更についてはどうですか？ WebサービスのSTS（Secure Token Service）はどうですか？ （STSは、Webサービスに同様の委任認証メカニズムを提供します。）
SAMLは、多くの新しい語彙と多くの構成を紹介します。ドキュメンテーションは優れたものではなく、より高いレベルの一般的なことについて話している標準ドキュメントに大きく依存しているため、簡単には取り上げられません。具体的には、あなたやあなたのアプリケーションではありません。
本当にSSOが必要ない場合は、中央のLDAPストアのようなコンテンツが存在し、そこから続行される可能性があります。
そうは言っても、例として、私たちのアプリケーションはDBとLDAPの両方のバックエンドをサポートしています。これらはGlassfishを使用し、Java EEセキュリティ。ユーザーエクスペリエンスを完全に制御します。SAMLを介したSSOもサポートします（独自のIDおよびサービスプロバイダーを作成しました）。また、LDAPを介して両方の共有資格情報を持っていますJavaおよびその他のアプリケーションでのコードとサードパーティのコードを使用したSSOです。明るい面は、すべて標準に基づいていることです。悪い面は、標準が英語で伝達され、英語が対象であることです解釈に。
私はこれができると言うだけでこれを言います。ナプキンSSO実装の裏側で、同じドメインとクロスドメイン（同じドメインは共有Cookieを使用してシンプルです）の両方を、単純なサーブレットフィルターを使用してアドホックで記述しました。パスワードポリシー、パスワードの回復、キープアライブタイマー、複数のウィンドウタイムアウト、セッション管理（これはちょっとしたことです）、ロール、特権など。
また、Springに加えてこれらすべてを提供するSpringとSpring Securityについては言及しません。私はそれを使用していません（私はSpringの人ではありません）が、それらの人々は彼らが何をしているかを知っているので、一見の価値があります。
「 OpenSSO/OpenAMに認証と承認のためにデータベースと通信させる方法はありますか？ は間違った表現になっていることに注意してください。質問の詳細と回答はauthorizationの側面のみを扱います。 OpenAMは、ユーザーとパスワードのMySQLデータベース（authentication）と連携して機能し、ポリシーやその他の設定を保存するために非表示/組み込みLDAPサーバーを使用できます。
まだセキュリティモデルを具体化する必要があるようですが、OpenAMのようなものはまったく必要なく、コンテナ/フレームワークが提供するセキュリティを使用するだけで済む場合があります。
OpenAmのカスタムユーザーリポジトリの構築に成功しました。この質問はしばらくの間有効ではなく、ここではその方法を詳細に説明するには長すぎるため、いくつかのヒントを示します。詳細についてサポートが必要な場合は、遠慮なく私に尋ねてください。
- 基本的なエントリポイントは、com.Sun.identity.idm.IdRepoを拡張する必要があります。
- Ssoadm.jsp？cmd = add-sub-schemaを使用してカスタムリポジトリを登録する必要があります。
この時点から、レルムのデータストアを作成すると、リポジトリタイプが他のタイプの中でリストされます。
幸運を ！
RDBMでOpenAmを使用できます。 OpenAmでJBDCベースのユーザーストアを使用しています
OpenAMには、ユーザーと付随するすべてのプロパティが格納されるユーザーストアと、構成を保持する構成ストアの2つの別個のストアがあります。 OpenAMで利用できるデータベースユーザーストアがありますが、私は試したことはありません。 SOあなたが指摘していた質問は、主にLDAPのみであるがOpenAMに埋め込まれている（したがって、直接管理を必要としない）構成ストアを参照していました）。
個人的には、Glassfishを介したTomcatのファンです。それは、完全なJ2EEコンテナーに関連するすべての関連する膨張がない、高速で軽量のサーブレットコンテナーであるためです。
OpenAMは 独自の認証モジュールをプラグインできる のようです。
おそらく、AMLoginModuleの拡張内からDB呼び出しを行うことができます。
このリストは、出発点として適しています。
http://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
[〜＃〜] josso [〜＃〜] および Shibboleth が思い浮かびます。