問題タブ [alfa]

XACML ポリシーをチェックインしようとしています。サブジェクト (urn:ch:xxxx:attribute:subject:1.0: participantid )にlongがありますリソース コンテキスト。関数integer-is-in でそれをやろうとしています。

私はこれまでに試しました：

私はこれをテストしましたが、うまくいきました。

では、サブジェクト属性を機能させるにはどうすればよいのでしょうか? または、関数integer-is-inが間違っていますか?

よろしく

クリスティアーノ

私は、プロジェクトに対してどのような承認テクノロジ/方法論を実行するかを決定しようとしていますが、XACML には多くの興味深い機能があります。私が理解できないことの 1 つは、アルゴリズムを組み合わせる必要があることです。それらが必要な複雑なシナリオはありますか?

代わりに、リソース タイプ (またはその他のもの) へのアクセスは、既定では許可または拒否であるとします。ルールは、許可または拒否の条件を定義します (両方ではありません)。

拒否がある場合、それは拒否されます (すぐに)。「デフォルトで拒否」で許可がない場合は、それも拒否されます。ルールには優先度があり、より高いレベルの許可/拒否はそれより下のレベルを上書きします。

ルールは、高度な結合アルゴリズムを使用した 1 つの大きなルールではなく、断片的な許可/拒否になります。

そのようなアプローチではカバーされないいくつかの主要なシナリオ (おそらく) を見逃していますか? 答えるのが難しい質問かもしれません:) XACMLの経験やアクセス制御の経験が豊富な人が、設計思想とそのようなポリシーに関する経験に光を当ててくれることを願っています.

前もって感謝します！

編集：（長すぎるため、ジョージへの返信として）

デビッドに答えてくれてありがとう！あなたの投稿や記事をたくさん読んでください。

私はあなたが言っていることを聞いて、多くの複雑さがあります (いくつかのデザイン決定と評価ロジックに関するメーリングリストを読んで、うわー、毛深いもの:) しかし、階層構造が多くの複雑さを追加しているようにほとんど見えます、なぜそれが必要なのかよくわかりません。

私が書いたロジックによると、これらの2つのルールを持つことができました（XACMLを正しく理解していれば）

• ユーザーがユニット内にいる場合にアクセスを許可する
• 一連の特定の状況下で拒否する
• 全社的なルールである場合は、DENY ルールのビジネス ユニットの制限を削除することもできます。

ルールを 1 つの大きなルールの一部にするよりも、ルールを個別に調整する方が簡単に思えますが、このように書くと本当に 1 つのルールと考える必要があるのでしょうか? 一般的なケースを許可し、例外を拒否するという一般的な考え方があると思います。

2番目のサンプルです。これが、いくつかの問題を解決するために実際に「優先度」が必要だと私が考える理由です。

どの「優先レベル」でも PERMIT または DENY で短絡し、順番に評価されるため、結果は同じではありませんか? また、優先度の低いルールを作成した人は、優先度の高いルールについて知る必要はありません。

最後の例は次のようになります。

（つまり、他のルールもある必要があるということです:)

DENY は Permit をオーバーライドするため、DENY は設定されていることを拒否します。

私はそのようなアプローチでは処理できないエッジケースを見るのに苦労していると思います...多分私は頭のおならをしています:)

申し訳ありませんが、質問の範囲は少し広いです。