Hi Hao,
The solution as proposed was exampled on an assumption that access is
denied unless a specific rule is applicable to the request, in which
case the rule will be to Permit.
However, this was only a simplifying assumption to get started, but it
should cover the standard J2SE case for Permissions, at least those
that can be represented by hierarchical names.
Once that use case is firmed up, then one can look at options to handle
a mix of permits and denies, that I mentioned also in this email thread
to which you are replying (see below):
"If the situation involves more complex rules, such as
mixing permits
and denies, then the returned lists will have to specify whether they
are permits or denies, and a combining algorithm, such as
permit-overrides or deny-overrides, which then puts responsibility on
the PEP to understand how to execute the individual regexps and combine
the results.
I have not analyzed this more complex use case, but it
seems to me to be manageable for a set of well defined hierarchies,
where the rules are all defined in terms of a syntax used for those
hierarchies."
Thanks,
Rich
hao chen wrote:
404213.95535.qm@web51102.mail.re2.yahoo.com"
type="cite">
Hi Rich,
If I understand you right, what you try to do is to let
PDP returns a list of resources that might be applicable to a given
subject for a given action. I have the following question for you:
Does the list of resources returned by the PDP contain
only allowed access for the given subject and the given action or
contain both allowed or may-not allowed access for the given
subject and the given action? If the list of resources returned by the
PDP are the resources only allowed access by the given subject and the
given action, then looks like you want to get all persmission s for the
given subject and the given action. Even though those information are
defined in access control policies, it might not be proper for a PDP to
provide the list of permissions if the access request does not query
the PDP for access decision on those permissions.
Best Regard
--- On Thu, 4/22/10, Rich.Levinson <rich.levinson@oracle.com>
wrote:
From: Rich.Levinson <rich.levinson@oracle.com>
Subject: Re: [xacml-users] retrieving a list or query filter of
resources the caller is authorized for
To: "Yoichi Takayama" <takayama.yoichi@gmail.com>
Cc: "Ralf Lorenz" <rol@mms-dresden.de>, "Tyson, Paul H"
<PTyson@bellhelicopter.textron.com>, "Oleg Gryb"
<oleg@gryb.info>, xacml-users@lists.oasis-open.org
Date: Thursday, April 22, 2010, 10:43 PM
Hi Yoichi,
A couple of quick points in response inline.
Thanks,
Rich
Yoichi Takayama wrote:
On 20/04/2010, at 3:57 PM, Rich.Levinson wrote:
Hi Yoichi,
Some thoughts in response to your comments inline.
Thanks,
Rich
Yoichi Takayama wrote:
Hi Rich,
(A) The use of Obligations or Advice
An interesting preposition, although I don't agree
with using the <Obligations> for any such purpose.
There are two components (or phases) in XACML
Access Control.
(1) All factors that the PDP can determine from
Target, Policies and Attributes.
(2) Additional factors only the user or the PEP
can supply.
The latter uses the Obligations. Therefore, it is
not fit to include any Responses about what PDP should/can determine
into the <Obligations>.
The suggestion to use <Advice> is not
satisfactory, either. Because this is defined as an element that the
PEP can safely ignore.
An example in the OASIS XACML 3.0 specification
contains a Policy that requests the Obligation that the PEP should send
an email to the patient contact before the access is to be granted.
Since such an Obligation cannot be met by PDP, it is a job for the PEP.
Another example commonly used is a case, in which
the end user must read and agree with the Conditions and Terms. This
also cannot be performed by PDP. When the Decision comes back and the
PEP gets back to the end user who triggered PDP decision, the PEP has a
chance to collect the user response whether the user agrees with the
condition of the use.
From my perspective, the query can be regarded as a request for a list
of resources. The Obligations that the Policy returns in response may
be regarded as: the PEP MUST execute these queries against the resource
store in order to return the list that has been requested.
The PDP cannot, in principle, return a list of resources, because it
has no direct knowledge of the resources. Furthermore, the resource
store may be in a state of constant change as resources are added and
removed to the repository. What the PDP has is the PolicySets governing
access to the resource repository. It is able to do this because, in
general, a repository has language semantics that can be used to define
scopes of resources within the repository. When the XACML Request is
for the list of resources, it is only the PDP that knows how to
generate this list, and at the same time the PDP is unable to generate
the list, and therefore, to satisfy this request, can only return the
instructions to the PEP for how the PEP can generate the list.
In the model you have suggested that:the PDP determines its response
from the Target, Policies, and Attributes, I think the proposed
solution is in that category, as what is returned is the set of
applicable expressions from the Policies as determined by the Targets.
For each applicable PolicySet, if the request is for the resource, then
the rule is applied to the resource-id, but if the request is for the
"list" of resources, then what is returned is the rule that would have
been applied to the resource-id if it had been provided. It is only the
PEP or other external entity that can produce the list and it is only
the PDP that can provide the command that will produce the list.
My point is that one does not have to return the list
of <Obligation>s. Since if you simply include multiple Resources
in the Target of the XACML Query, it returns a list of Resources with
multiple permission Decisions.
I am looking at this from the perspective of 3 XACML modules: the PEP,
the ContextHandler (CH) as defined in XACML 2.0, section 3.1, and the
PDP. In the scenario I am describing, the PDP returns the Obligations
to the CH initially. In profiles, such as the Multiple Resource
profile, it is briefly explained (Multiple section 1 lines 46-56,
section 1.1, lines 77-81) that the CH may be reasonably regarded as the
module that breaks up a single request for multiple resources into
multiple single resource request/Result pairs that can be returned in a
single ResponseContext.
Therefore, I can envision scenarios where the CH takes the PDP query
string responses, and uses them to query PIP stores to get resource
lists.
The point of querying the PDP first is to shorten the list. If you have
a system with a 1,000 users and 1,000,000 resources, then if you ask
what resources the user can access, I don't think it makes sense to ask
the pdp for an answer for all 1,000,000 resources. By just asking for
the query strings applicable to the particular user, the CH may be
returned on the order of 10 query strings which define the scopes the
user is permitted to access. The CH can run these queries against the
PIP and construct a full list of results, one for each resource the
user is permitted to access, and return that list to the PDP.
It seems your statement should be other way around.
PDP should be always able to return a list of Resources, whose PIP must
know about them. Otherwise, how can it make any decision about the
Resources?
This should be answered by my prev comment that if we assume that the
query as I constructed in prev emails returns obligations with the
query strings that define the scopes to which the user has access in a
hierarchical scheme, then the decision is already known about the
resources on the list being constructed by the queries to the PIP.
On the other hand, the PEP must make the list of
Resources in order to be able to make the multi-question Query. We do
that in our system that uses XACML. Before making the Query, the PEP
must use PIP (not via PDP), to get a list of Resources relevant to the
interface or situation where the Action- and Resource lists are
required. What Actions and Resources are required differ from interface
to interface.
In the scheme I have demo'd the PEP makes a single request for a single
resource-type with a single pre-defined resource-id indicating query,
namely the string "/-" in the provided examples.
In terms of defining the actions to which the user has access to with
this scheme, there is at least one possibility that I think would work,
and that is to return the set of action-ids that this policy also
allows.
Again, this is all premised on the policy designers using a policy
definition tool that will automatically fill in the details to produce
the necessary xacml constructs. For small cases, such as the one I
demo'd, I did all the work by hand, but for production one would need a
tool that would constrain the allowed constructs, at least within a
pre-defined domain, such as a single resource-type.
In a generalised case, however, whether PEP can do it
or how PEP does it, is questionable.
Note that, since the list is included in the Response
to PEP, there is no need to return any list of <Obligation>s.
(B) Theoretical considerations as to the nature of
rules resulting from the Policies and how to query over them
The XACML Target, Attributes, logics (combining
algorithms and conditions etc.) and Permissions may be thought of a
Function:
f (Target | Policies) -> Decision
i.e. Permit or Deny
More precisely, f is,
f (Target | Policies, a1, a2, a3, ...)
-> Decision i.e. Permit or Deny
where a1, a2, a3, ... are Attribute values that
are used in the Request's Target and relevant Policies. They contain
subject-id, action-id, resource-id, etc. which are literal values, not
variables. The id values inside the Target may be of the ANY value (or
not defined).
The problem we are trying to solve is to find a
kind of inverse function: (Note that we are not looking for an exact
inverse function of f).
g (Permit | Policies, subject
Attributes) -> {[action-id, resource-id] , ...}
where action-id and resource-id are literals or
the ANY value. It returns a set of 2-tuple elements. The ANY value will
make it unnecessary for any more element with a different value for the
element in the list. The subject Attributes can be a sub-set of all the
subject Attributes. It may contain only the subject Attributes that
appear in relevant Policies that are considered for the subject.
More precisely, g is,
g (Permit | Policies, subject Attributes,
a1, a2, a3, ... ) -> {[action-id, resource-id] , ...}
where a1, a2, a3, ... are Attribute values for
Actions, Resources and Environment, which appear in all the Policies
that are the matches in the context of the function, dependent on the
given parameters.
Since there is no general solution for this
problem (for non-specific, i.e. generalised, Policies, Actions and
Resources), we can solve this only on the cases where all entities,
i.e. Policies, Actions, Resources and Environment are finite.
From the given Policies and the subject (and the
other Attributes) of the query context, the problem is to identify the
relevant subsets and see what [action-id, resource-id] tuples are the
elements of those subsets. Since Attributes are often expressed as
variables in Policies, there would be situations where there may be no
element in some subsets.
Assume that all [action-id, resource-id] tuples
are sorted and categorised into subsets as the Policies dictate (how to
do this is considered later), the question is whether finding the right
subsets and the elements is equivalent to using the fixed value Prefix
and a single wildcard Suffix for RegEx to search for the [action-id,
resource-id] tuples.
Assumptions:
1. A Policy can be interpreted as a single RegEx
for Resources
2. The RegEx consists of a fixed value Prefix
(e.g. /A/B/C) and a wildcard Suffix (i.e. *).
3. Resource Handles (a mapping of the real
Resources references in order to enable the RegEx search) can be
searched with RegEx properly to return a set of matched Resources
properly.
4. A Resource can be mapped to a Resource Handle.
The mapping is maintained somewhere.
5. We are interested in the Permit outcomes only.
1'. Since a Policy may contain multiple Attributes
and conditions, the RegEx must have a capability to accommodate all
these that are essential to give the Permit outcome only. (We are not
interested in Deny or others).
2'. In the example given, each level inside the
PATH expression seems to correspond to a condition and its value that
the RegEx can examine. E.g. A Resource may be in a condition /A/B/C,
while another one in /a/B/c. It indicate that the predicates used are
the same but the predicate values are different.
2''. The Suffix represents each Resources within
that privilege subset.
2'''. The necessary Attributes values are
expressed as 2'.
3' & 4'. The Resource Handle represents all
subsets exist plus a specific Resource Id for an individual Resource.
5'. Since a Policy may contain multiple Permit
outcomes, the RegEx must have a capability to accommodate all Permit
occurs into one RegEx syntax, e.g. must use logical OR.
6. It is expecting a list of Resources but this
should be amended to get a list of [action-id, resource-id] tuples in
our case.
Proof
If we can demonstrate that any of the XACML Policy
syntax capabilities cannot be done with RegEx, that is an anti-Proof to
deny the conjecture.
It, however, seems it can done in case of a single
Policy. It also seems possible to express the Policy-combining
algorithms, e.g. Permit-overrides, Deny-overrides,
Ordered-Permit-overrides, First-applicable, and so on.
Direct Proof may be given to demonstrate whether
all XACML syntax may be expressed in RegEx. That can be done but I will
skip such an effort.
I am not sure I agree with the problem statement here. It appears to be
saying that in order to provide a response to a query, that response
must return a function that is the exact inverse of whatever constructs
could conceivably put into a Policy.
To me, that is an academic problem, as opposed to a real world problem.
If an enterprise places constraints on the manner in which Policys are
allowed to be specified, then I think it is reasonable to be able to
produce responses that are within the scope of those constraints.
For example, my suggestion was to define the query for hierarchical
resources. For a single hierarchy, the solution is fairly simple if
access is only allowed to permitted resources - just return the list of
regexps, and the pep can execute the queries and return the collected
list.
If the situation involves more complex rules, such as mixing permits
and denies, then the returned lists will have to specify whether they
are permits or denies, and a combining algorithm, such as
permit-overrides or deny-overrides, which then puts responsibility on
the PEP to understand how to execute the individual regexps and combine
the results.
I have not analyzed this more complex use case, but it seems to me to
be manageable for a set of well defined hierarchies, where the rules
are all defined in terms of a syntax used for those hierarchies.
Also, I think one must consider that at some point, making the policies
too complex actually reduces the effectiveness of the system because it
becomes very difficult to understand the rationale for decisions that
are made by the system, which represents a loss of control by
management over the organization.
Just a slight correction, the part of the problem is
that it is not the exact inverse function. It is asking a different
question. It is easy to prove the the exact inverse function exists.
My previous description was not accurate, but it is
more like:
f(S, [A1, A2, ...], [R1, R2, ...]) ->
[D1(A1, R1), D2(A1, R2), ...]
where S: subject, A: action,
R: resource, D: decision.
The actual question is this:
g(S, D=Permit) -> [(A1, R1), (A1, R2), ...]
I am not mathematically inclined. I am just trying to
describe in a simple way to myself to clear up the problem.
Also, to prove whether RegEx works or not, I had to
see how the RegEx solution maps to all necessary bits and pieces that
should be there.
My conclusion is the same as yours. Unless the RegEx
can handle complex syntax, e.g. logical AND, OR, and something like IF
and FOR look within its syntax, it may not be an equivalent of XACML
Policies.
However, as I said, I know RegEx syntax that can do
AND and OR. The first question is whether the RegEx employed does it.
The second is that whether it can do something equivalent to express
XACML combining algorithm. As I said, I am not certain about the latter.
However, as you said, since we are dealing with a
finite example, we may be able to deal with it simple and empirically.
E.g. theoretically, we could use a Truth table to have all Policy
Targets vs Decisions under all conditions at hand. By tracing the table
from all Permit decisions under the given conditions and for the given
Subject, we can arrive at the solution (which is a list). This is an
exhaustive approach.
As you said, this is not a complex problem where the
Actions and Resources are not complex. However, the table must be
dynamically created where the Policies, Resources and Attributes may be
dynamically changed.
With a complex Policies and Resource Attributes, the
table may get too big or the practicality of making the table
dynamically may become a problem.
I will have to take more time to get deeper into this issue, but it
sounds like we have some region of agreement. Generally, with
hierarchical resources, my sense is that an exhaustive approach is
rarely needed, as a set of well defined scopes, like the "Immediate",
"Children", and "Descendants" in section 4.1 of Multiple, lines
326-336, is a robust mechanism for defining scopes that remain intact,
regardless of the changes to the members of the resource collection.
(C) Modifications/comments
The Resource Handle mapping for RegEx is not a
part of XACML. Although it can be done by the PIP to return such a vlue
as an Attribute and use it in the Policies, it is better if one can
write Policies without using Handles.
By any rate, how to construct Handles encompassing
all Predicates may not be trivial (depending on the number of Policies).
This type of query should be done not as an XACML
Query but outside its scope. How the [action-id, resource-id] listing
is done should be a blackbox.
One other thought is that the query could conceivably be done in 2
phases:
- based on the returned regexps, the PEP can obtain a
potential list of concrete resources.
- the PEP can then, one at a time, submit the entries
from the potential list to the PDP which can apply the more complex
predicate to the individual resource, and based on the returns the PEP
will remove specific items from the list to be returned to the caller.
This is similar to what I said above. PEP can obtain
the lists of Actions and Resources first, then it can ask a single
multi-questin Query to the PDP. The difference is that it does not have
to ask one-by-one questions.
However, I do not understand how the "PEP can obtain the lists of
Actions and Resources first" without querying the PDP, which is the
only entity that "knows" by its set of regular expressions how to
produce the list of "applicable" Resources and Actions. That is the
step 1 defined above.
Step 2, can submit the list as a single RequestContext using the
Multiple profile, and as described above it is the CH, in general, that
can be thought of as the entity that breaks this multi-request into the
indivduals required by the PDP.
The Handle values may have to be dynamically
revised when new Policies or predicates are dynamically added.
Yoichi
On 19/04/2010, at 2:30 PM, Rich.Levinson wrote:
Hi
Ralf, Yoichi, et al,
I have been following this discussion with interest as part of the
OpenAz open source effort is to provide a query capability. The intent
of OpenAz is to enable XACML to be brought into enterprise environments
in a seamless manner, allowing migration on an as-needed basis to
enable XACML capabilities to be introduced to the enterprise.
That aside, the technique we have been looking at is focused on
hierarchical resources and the use of regular expressions to address
scopes of those resources. This is also consistent with the notions in
the XACML Multiple and Hierarchical Profiles.
Basically, hierarchical permissions can be simply thought of as a
regular expression containing a fixed prefix and a wildcard suffix,
where any resource name that matches the prefix is within scope of the
expression.
Generally this expression can be applied to the resource store to get a
list of the concrete resources covered by the expression. Therefore if
a Policy can be defined that will return the list of applicable regular
expressions contained within the policy for the specific request, then
this list of expressions can be applied to the resource store in order
to get the full list of concrete resources covered by the query.
Therefore the trick is how to get this list of regular expressions out
of the policies. The attached zip file contains a policy that provides
this capability, along with sample requests and responses that were
obtained by running the requests against the SunXacml PDP being used in
the OpenAz project.
The trick that is used is to use a PolicySet to contain a pair of
Policys. One of the pair contains the actual regular expression used
for access control. The other of the pair returns an Obligation
containing an AttributeAssignment that contains a copy of the regular
expression. The way to get the 2nd policy of the pair invoked is to
query for the specific string "/-" which is simply a string used in all
the "2nd policies" and so all policies that contain this resource will
match the query.
Note: none of this effort is focused on performance, and is intended at
this time just to demonstrate capabilities. It is expected that
optimizations will be need to enable scalability.
Note: since SunXacml is based on XACML 1.1 there are a few 1.1
artifacts floating around, but these are rather trivial, and do not
impact the overall structure of things, at least in the current phase
of the OpenAz project.
Comments and suggestions are welcome.
Thanks,
Rich
|
|