問題タブ [declarative-security]

私はこれを約1日半いじり、.NETリフレクターとMSDNのドキュメントをふるいにかけましたが、何もわかりません...

.NET フレームワークでは、次のようにメソッドをマークすることで、現在のプリンシパルがメソッドを実行できるロールに属していることを要求できます。

「読み取り専用」ロールが既に定義されている既存のセキュリティ モデルを使用しているため、上記とは正反対のことを行う必要があります... ユーザーが「読み取り専用」ロールにある場合は、Save() メソッドをブロックします。問題ありませんよね？SecurityAction を .Deny に切り替えるだけです。

さて、これはまったく何もしないことがわかりました。メソッドは引き続き正常に実行されます。PrincipalPermissionAttribute が定義しているようです:

ただし、属性が SecurityAction.Deny に設定されている場合、このメソッドは呼び出されないため、IPermission オブジェクトは作成されません。.Deny を機能させる方法を知っている人はいますか? カスタム セキュリティ属性を作成しようとしましたが、それでも機能しません。私はトリッキーになってやろうとしました：

属性コンストラクターが常に SecurityAction.Demand を渡すことに注意してください。これは、以前は機能していたアクションの 1 つです。ただし、この場合でも、属性が .Deny ではなく .Demand に設定されている場合にのみ、CreatePermission() メソッドが呼び出されます。ランタイムは、CodeAccessSecurityAttribute コンストラクターに渡された SecurityAction ではなく、実際に属性をチェックしているのではないでしょうか?

ここで他に何を試すべきかわかりません...誰かアイデアはありますか? メソッドへのアクセスを要求するだけでなく、ロールに基づいて拒否することはそれほど難しいとは思わないでしょう。デフォルトの PrincipalPermission が .Deny を実行しても問題ないように IDE 内から表示され、MSDN ドキュメントには、それが機能しないことを示唆する 1 ライナーのようなものがあることに本当に悩まされました。.Demand 以外のものが指定された場合、PrincipalPermissionAttribute コンストラクターはすぐに例外をスローすると思うかもしれません。これは、大きなセキュリティ ホールを作成する可能性があるためです。単体テストをしていなかったら、.Deny がまったく何もしないことに気がつかなかったでしょう。

繰り返しますが、これはすべて、アクセスを拒否する必要がある "ReadOnly" ロールを持つ既存のセキュリティ モデルに対処しなければならないことに起因しています。

助けてくれてありがとう！

迅速なフォローアップ:

これを行うことで、実際にカスタム属性を機能させることができます。

そしてメソッドを飾る：

しかし、同じ属性で Demand と Deny の両方を指定しているので、これはひどく醜いです。しかし、それは機能します...

もう 1 つの興味深い点: 私のカスタム クラスは CodeAccessSecurityAttribute を拡張し、さらに SecurityAttribute のみを拡張します。SecurityAttribute を直接拡張するようにカスタム クラスを変更すると、何も機能しなくなります。そのため、ランタイムは間違いなくメタデータ内の CodeAccessSecurityAttribute インスタンスのみを探しており、カスタム コンストラクターがそれをオーバーライドしたとしても、指定された SecurityAction で何かおかしなことをしているようです。

次の段落が間違っている理由を誰か教えてください。

デプロイメント記述子が BASIC の認証タイプを正しく宣言している場合、コンテナーは、ユーザーが新しいセッションを開始するたびにユーザー名とパスワードを自動的に要求します。

.NET3.5を使用しています。特定のファイルと特定のレジストリキーにアクセスするメソッドがあるとします。メソッドを制限する宣言型のセキュリティ定義を追加して、指定されたファイルとレジストリキーにのみアクセスできるようにし、他には何もアクセスできないようにします。

私が試してみると：

...ファイルパスは読み取れますが、レジストリキーは読み取れません-セキュリティ例外が発生します。

私が使用する場合：

...ファイルとレジストリキーを読み取ることができますが、他のファイルにアクセスすることもできます。

この効果を達成するためにこれらの方法をどのように使用すべきかについて何かが欠けていますか？

編集：

レジストリキーにアクセスするために使用しているコードは次のとおりです。

したがって、許可宣言は次のようになります。

ありがとう。

2つの質問について、私はあなたに相談したいと思います。

背景：テスト、Java EEアプリケーションを作成し、宣言型セキュリティを追加しました。アプリケーションはGlassfish3.1にデプロイされます。単体テストでは、ローカルインターフェイスを持つすべてのBeanに組み込みコンテナを備えたJUnitを使用しました。アプリケーションのエントリポイントである、唯一のリモートインターフェイスを持つSessionFacde Beanについては、SessionFaceBeanへの参照を取得する単純なクライアントを作成しました。SessionFacadeBeanにのみ適用したセキュリティアノテーション。

（質問1：セキュリティ付きの推奨される単体テスト戦略は何ですか？sessionFacadeに単純なアプリケーションクライアントを使用しても大丈夫ですか？（セキュリティ注釈が適用されていないため、他の（ローカル）Beanは影響を受けません。））

質問2：アプリケーションクライアントからSessionFacdeにアクセスするにはどうすればよいですか？ここにapplication-client.xmlのコードサンプルをコピーして、JNDIサービスへの参照を取得していただければ幸いです。これは私に多くの時間を節約するでしょう。質問はJavaEE6アプリケーションクライアントログインの質問と似ていますが、実際には推奨されないという説明（http://docs.oracle.com/cd/E18930_01/html/821-2418/beacm.html ）を見つけました。フレームワークではなく開発者にセキュリティの負担を戻すためです。以下のテキストを参照してください。

「[...]プログラムによるログインにより、アプリケーション開発者はGlassFishサーバーでサポートされる認証メカニズムをバイパスし、認証データをセキュリティサービスに直接フィードできます。柔軟性はありますが、セキュリティの問題をある程度理解していない限り、この機能を使用しないでください。

このメカニズムはコンテナ管理の認証プロセスとシーケンスをバイパスするため、アプリケーション開発者は、制限されたリソースやメソッドにアクセスする前に、認証が確立されていることを確認する際に細心の注意を払う必要があります。ログイン試行のステータスを確認し、それに応じてアプリケーションの動作を変更することも、アプリケーション開発者の責任です。

プログラムによるログイン状態は、必ずしもセッションで持続したり、シングルサインオンに参加したりする必要はありません。[...] "

これまでお読みいただきありがとうございます。よろしく、タマス

備考：元の投稿を書いてから返答がないので、2番目の質問に答えれば十分だと思います。それは私が続けるのを助けるでしょう。ありがとう、タマス

私は最近、会社の Active Directory に関連付けられた宣言型セキュリティ (server.xml/web.xml) を使用する JSP で tomcat Web アプリを開発しました。駆け出しのプロジェクトに JSF サポートを追加するように依頼されました。ログイン フォームを jsf に変換するのは簡単なことで、セキュリティ モデルは引き続き機能します。

アソシエイトは、より多くの聴衆がレポートの 1 つを表示できるようにし、アクション ボタンを少数のグループにのみ表示できるかどうかを尋ねました。JSF は初めてなので、調査を行う必要がありました。

「jsfボタンのセキュリティ」や「jsfボタンのアクセス許可」などをグーグルで調べ、さまざまな提案を試みましたが、ほとんど行き止まりでした。別のアソシエイトは、Spring セキュリティ モデルの使用を提案していましたが、より簡単な方法があれば、たくさんの Spring ライブラリを扱いたくありませんでした。

やがて、信じられないほど簡単な答えにたどり着きました。HttpServletRequest メソッドの isUserInRole() を使用して、現在ログオンしているユーザーがアクション ボタンを表示する権限を持っているかどうかを判断するだけで済みました。過去 10 年間、私は HttpServletRequests をたくさん使用してきましたが、その方法について学んだことを思い出したことはありません。jsf を使用すると、以下に示すように、そのメソッドに到達するのは簡単です。

私の質問は具体的には次のとおりです。このアプローチについて知っておくべき落とし穴はありますか?それを行うための別の簡単な方法はありますか?

web.xmlの宣言型セキュリティエントリに問題があります。

私はグループのメンバーですが、以下のエントリではページにアクセスできません*ADL - Education Group。login-noauthページに移動することになります。

私はこれがうまくいくはずだと知っています-私がそれを別のグループ（のようなAT - Tech Support）に変更すると、それはうまくいきます。グループ名の先頭の「*」が疑わしく、web.xmlでCDATAを使用しようとしましたが、機能しませんでした。Active Directoryエントリを制御できないため、グループの名前を変更できません。ダッシュとスペースを含む他のグループ名は正常に機能します。

私はグループのメンバーであることを確認しました*ADL - Education Group。

これは単純なtomcat6.0サーバー上にあります。

誰かが問題が何であるか、そしてそれを修正する方法を知っていますか？

この質問は Java EE 宣言型セキュリティに似ており、アプリケーション クライアントからセキュア Bean への参照を取得しますが、より具体的です。

Glassfish 組み込みコンテナーを使用してローカル Bean を単体テストできます。リモート Bean については、アプリケーション クライアントを作成しました。これは、セキュリティがリモート Bean に適用されるまでは実行可能なソリューションでした。ここで、Glassfish 3.1.1 に対してアプリケーション クライアントを認証する際に問題が発生しました。

現象：

• アプリケーション クライアントを使用してセキュリティなしでリモート Bean をテストしても問題ありません。
• ProgrammaticLogin のアプリケーションでセキュリティを使用するアプローチは機能せず、単体テストで問題を解決する正しい方法であるかどうかはわかりません。（冒頭のリンク先をご覧ください。）

質問：

• リモート Bean を使用したセキュリティの単体テストはどのように行うべきだと思いますか?
• glassfish-ejb-jar.xml はどこに置く必要がありますか? (私の場合、これは間違っている可能性があり、これが ProgrammaticLogin が機能しない理由です。)