JavaEE 7 チュートリアルのパラグラフ50.3で説明されているように、(WildFly 8.2 を使用して) 独自の JDBC レルムを作成しました。私の理解では、JDBCレルム認証は、ユーザー資格情報がサーバーによって読み取られてチェックされることを意味し、アプリケーションは認証予約DBの座標さえ知りません。
「新しいユーザーのサインアップ」の場合、私が想像できる唯一のことは、アプリケーションの内部から古典的なソリューションを実装することです。認証DBにアクセスし、選択したユーザー名が既に存在するかどうかを確認し、テーブルに行を挿入します...しかしそうではありませんこれは「コンテナ管理認証」のパラダイム全体に違反しているのではなく、セキュリティ ホールを挿入する可能性があります。
私が無視するサーバー実装のメカニズムはありますか?
しかし、これは「コンテナ管理認証」のパラダイム全体に違反していませんか?おそらくセキュリティホールを挿入していますか?
はい、多かれ少なかれ。アプリケーションが認証メカニズムをまったく認識せず、アイデンティティ ストア (ユーザー データが実際に保存される場所) が、アプリケーションに独自のユーザー サインアップ/サインアップがあるユース ケースを実際に考慮しない、コンテナー管理セキュリティの概念登録機能。
このアイデアは、外部から入手したアプリケーション (たとえば、Sonar または JIRA インスタンスなど) を既存の企業構造に統合することをより意図しているようです。ユーザーは、LDAP などの中央システムを使用して管理者によって作成されるか、場合によってはアプリケーション サーバーの管理 UI を使用して作成されます。
残念ながら、一般的なパブリック Web アプリケーションの多くは、このような種類ではありません。これらはスタンドアロン アプリであり (既存の社内のエンタープライズ インフラストラクチャとは統合されません)、独自のユーザーを効果的に管理します。
古典的な概念はそこには適合しません。そのため、Java EE Security EG は現在、これに対処する最善の方法を模索しています。
それまでの間、基本的に3つの「解決策」があります。
Java EE の観点からは、本当に理想的なものはありません。1 つ目は定義が重複しており、実際には原則に多少違反しています。2 つ目はそれ自体は問題ありませんが、JASPIC はやや低レベルであり、2 つ目は機能豊富なソリューションですが、既存の Java EE セキュリティとうまく統合されていません。