security - 認可制約のないセキュリティ制約のあるログイン ページでの「JACC ポリシー プロバイダー: 権限チェックの失敗」

Question

インターネットからログインページへのリクエストが行われると、netbeans glassfish 出力ウィンドウから次の結果が得られます。

情報: JACC ポリシー プロバイダー: 権限チェックに失敗しました: コンテキスト (" WebApplication2/WebApplication2 ") 、権限 (" ("javax.security.jacc.WebUserDataPermission" "/login.xhtml" "GET") ")

これは、要求が LAN または localhost から行われ、ページが必要に応じて HTTPS 経由で提供される場合には発生しません。

ログイン要求時にトランスポート層セキュリティを使用してユーザー パスワードを保護するようにログイン ページを構成しようとしています。web.xml デプロイメント記述子で宣言型セキュリティを備えた Faces サーブレットのみを使用して、これを実現できることを願っています。

request.login メソッドを介したプログラムによるログインのために、非 j_security_check カスタム Facelet フォームでフォームベースの認証を使用しています。ログイン フォームには、web.xml で次のセキュリティ制約があります。

 <security-constraint>
    <display-name>secure login</display-name>
    <web-resource-collection>
        <web-resource-name>login.xhtml</web-resource-name>
        <description/>
        <url-pattern>/login.xhtml</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <description/>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

このフォームは明らかに認証されていないユーザーを対象としているため、承認制約要素はありません。セキュリティ制約が存在する唯一の理由は、サブ要素を CONFIDENTIAL に設定して安全な接続を保証できるようにするためです。

Java EE 6 チュートリアルには、次のように記載されています。

認可制約がない場合、コンテナはユーザー認証を必要とせずにリクエストを受け入れる必要があります

と

ユーザー データ制約は、基本およびフォーム ベースのユーザー認証と組み合わせて使用​​すると便利です。ログイン認証方法が BASIC または FORM に設定されている場合、パスワードは保護されません。つまり、保護されていないセッションでクライアントとサーバー間で送信されるパスワードは、第三者によって表示および傍受される可能性があります。ユーザー認証メカニズムでユーザー データ制約を使用すると、この問題を軽減できます。ユーザー認証メカニズムの構成については、デプロイメント記述子での認証メカニズムの指定で説明されています。

このリソースにアクセスするためにそのようなチェックが必要ないのに、JACC がアクセス権チェックを行うのはなぜですか? LAN ではなく、インターネットからのみ失敗するのはなぜですか?