Thank you, Rich. I also appreciate your diligent replies.
(1)
Indeed that I was concentrating on replying some answers given to the original question. That is to do with lists of Actions and Resource in <Request>.
(2)
Going back to the original question, as you suggest, I think that it is indeed valid if the DPD returned some filter in addition to its base decision Permit, in order to further restrict the Resources to what are truly permitted.
It may be also valid if the access control is not based on the Decisions that are made from the Attribute values and Policies but rather based on the filter described in the <Obligations>. Note that <Obligations> is an additional condition, not the base Decision.
If the RegEx may be described in the Policies, as your example, it is XACML standard compliant. Although the final enforcement may not be easily audited in terms of the Decision values. I feel that it is a bit of mis-use (or a clever exploitation). Also, even if the Policy did not contain RegExs in them, it may be possible to modify the PDP to return RegExs in the <Response> (as <Obligations>). The latter is not good because such a behavour of PDP is not specified in the standard.
Not that I am saying this is a wrong way, I feel that it might be more straightforward if the Decisions rather can be used for the same purpose.
The problem is that the only way to do it with the Decision seems to be giving PDP a list of Resources, which is objected because the list would contain many items and each <Request> to PDP would be expensive.
(3)
Stepping back and re-examing the assumptions, the original question was to figure out how not to use the full list of Resources. And, that perhaps the PDP may be able to return an additional filter (presumably constructed from plain Policies, not necessarily a collection of RegExs) instead.
(4)
Honestly, we had a similar situation to implement a search engine compliant to XACML for digital repositories.
Our solution was to run RegEx or some filter BEFORE making a <Request>. Obviously the filter logic had nothing to do with what XACML will further restrict. Resources are naturally restricted by other factors, e.g. search keywords, the number of items per page, etc. Usually the <Request> will not contain a list of Resources any more than the scope of the resources the system is required to know about. Therefore, each <Request> to the Contact Handler did not contain a full list of Resources.
On top, the PEP was implemented to know about previous PDP decisions. It had its own database of [<Request>, <Response>] pairs. It did not ask the same <Request> twice. Obviously, the database had to be updated if the Policies changed and if they matched with the stored <Request>s. Incidentally, the PDP may have the [<Request>, <Response>] pairs in its own database as an alternative design for efficiency reason.
This may not be totally a satisfactory solution but without treading on modifying the intent and the specified capability of XACML architecture, this is one of the solutions.
(5)
Although we could make policies based on RegEx matches with URL handles of hierarchical Resources, in addition the XACMl Policies may express access control using Attributes that have noting to do with the URL handles. Are you presuming that the all Resource Attributes ever going to be needed will be expressed as URL Handles for Resources stored in the hierarchical Resource Store? If that is the case, that is one way to assign Attributes to Resources.
(6)
Please see inline comments below.
Yoichi
On 24/04/2010, at 12:42 PM, Rich.Levinson wrote:
Hi Yoichi,
I appreciate the time you have spent responding to my comments,
however, I think the responses are making assumptions about my proposal
that are somewhat off target. In particular, my proposal is in response
to the original email from Ralf Lorenz:
http://lists.oasis-open.org/archives/xacml-users/201004/msg00003.html
where the questions were asked:
"Being able to generate authorizations (spring-security
ACL) one of the main
use cases is answering the question: What secured resources (of a
given type) is the given subject authorized for?
...
One of the basic requirements on the access control management in my
current project is to
return a list of ids of secured resources of a certain type to get that
list from the
related resource data store. To achieve that with XACML each
request to the PDP would
include the complete list of secured resources the caller is interested
in and therefore
it is necessary to always have all secured resources around which often
might be more than
2000.
In my project I extended the PDP to have access to the domain but this
is probably not a solution
in the sense of XACML but how about being able to return a filter
which can be used to query
the domain?
"
All of my comments have been within or deriving from the context of the
above question.
In particular, the concern that appeared to be being raised that in
order in order to return desired list of resource-id's that it was
thought necessary to have ALL the resources around which could be a
large number. It was then suggested by Ralf that maybe a filter of some
sort could be returned.
My original response
http://lists.oasis-open.org/archives/xacml-users/201004/msg00019.html
was predicated on starting, at least, with a simple hierarchical model
for resources:
"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."
The use of regular expressions for scoping resource-ids is a well
established technique as part of the XACML 2.0 Hierarchical Profile
(section 4.3, lines 399-404):
"For hierarchical resources that are not represented as XML
document instances, and where the URI
representation of nodes specified in Section 2 of this Profile is used,
the following functions described in
the XACML 2.0 Specification [XACML] MAY be used to state policies
that apply to one or more nodes in that resource.
urn:oasis:names:tc:xacml:1.0:function:anyURI-equal
urn:oasis:names:tc:xacml:1.0:function:regexp-uri-match"
Therefore it is perfectly legitimate to refer to multiple nodes in a
hierarchy by a single regular expression.
Furthermore, Obligations are defined in XACML 2.0 to mean (section
1.1.1 lines 258-259):
"Obligation - An operation specified in a policy or
policy set that should be performed by the PEP
259 in conjunction with the enforcement of an authorization decision"
also this (section 2.12 lines 564-566):
"PEPs that conform with v2.0 of XACML are required to deny
access unless they understand and can discharge all of the
<Obligations> elements associated with the applicable policy."
and for the data contained within the Obligation (section 5.46, lines
2837-2841):
"The <AttributeAssignment> element is used for
including arguments in obligations. It SHALL contain an AttributeId and
the corresponding attribute value, by extending the AttributeValueType
type definition.
The <AttributeAssignment> element MAY be used in any way that is
consistent with the schema syntax, which is a sequence of
<xs:any> elements.
The value specified SHALL be understood by the PEP, but it is not
further specified by XACML."
Section 7.14 contains information on the mechanics or returning
Obligations, but does not say anything about their usage.
Based on the above, I feel that it is legitimate to conclude the
following:
- There is no reason that an AttributeAssignment cannot contain a
regular expression, and particularly the regular expression associated
with a particular ResourceMatch element.
- The PEP MUST understand the Obligation and therefore with
combination of AtrtributeAssignment attributeId equal to
"...resource-id", value containing regexp, and another
AttributeAssignment with AttributeId = "...resource-type" there is no
reason that the PEP should not conclude that it needs to use this exp
to query the resource store of that resource type and return the list
of resources to the caller.
Based on the above reasoning alone, I think it is sufficient to
consider the proposal I suggested as being legitimate within the spirit
and intent of XACML, and if that approach will solve the problems that
have been presented there is no reason not to use it. I recognize that
it is an approach that does not appear to have been previously
discussed, and that there may be some gotcha's to look for, some of
which I mentioned in earlier emails on this thread.
Finally, I will try to respond briefly to your comments inline below.
Thanks,
Rich
Yoichi Takayama wrote:
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
On 23/04/2010, at 1:43 PM, Rich.Levinson wrote:
Hi Yoichi,
A couple of quick points in response inline.
Thanks,
Rich
Yoichi Takayama wrote:
BEFEA578-CC1C-4822-8223-1AC7F394D2BB@gmail.com" type="cite">
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:
4D2560EC-5EEA-4EA5-B50A-42899BAA2AB9@gmail.com" type="cite">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.
That is not the case.
In the Figure 1 of the specification for XACML 3.0 (which has
not changed much since Version 1), the Context Handler takes a native
request from the PEP and produces a single <Request>. The Context
Handler further processes a <Request> if that contains
mult-Resource references such as a <MultiRequests>. It expands it
as a collection of multiple single <Request>s to PDP.
In the process of producing <Result>s, the PDP contacts
the Context Handler, which knows how to get necessary Attributes from
PIP to the PDP to gives actual values to the Attributes that are
specified in the Policies and <Request>s. This communication
channel (Steps 5 and 10) has nothing to do with the <Obligations>
or original <Request> or original native request from the PEP.
PDP produces a single <Response> corresponding to the
original <Request>, with multiple <Result>s, each of which
corresponds to the generated <Request> for each Resource
reference. Each <Result> contains <Obligations>.
Note that there is no such a thing as a single
<Obligations> that concatenates all the <Obligations> for
all Resources. Such a concatenation would be meaningless.
The <Response> is returned to the Context Handler, which
returns whatever appropriate native action to the PEP, that further
processes the native action to the final effect of the original user
request that triggered the while process.
What the Contact Handler and the PEP should/could do are totally
implementation-dependent.
The point is:
1) The Context Handler obtains the Resources list BEFORE going
to the PDP.
In the use case I have presented the PDP returns a set of Obligations
each of which contains one regular expression in an
AttributeAssignment, based on a request for a single resource with the
special name "/-" (which can be any name agreed on by Policy
implementors and users, but has been given this name for purpose of
demonstration with operational system).
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
2) There is no such a thing as a single <Obligations> with
a list of Resources in it.
I am not sure how to respond to this except to say: the operational
example I demonstrated showed a single <Obligations> with a set
of <Obligation> elements, which contained
<AttributeAssignment> elements, one of which in each Obligation
had AttributeId "...resource-id".
(see the zip file:
http://lists.oasis-open.org/archives/xacml-users/201004/zip00000.zip
, contained in the original msg I sent:
http://lists.oasis-open.org/archives/xacml-users/201004/msg00019.html
(Note: there was a slight bug in that example that reversed the
attributeId and attributeValue in the returned Obligations, which has
since been fixed (as if :) )
That comment was made for the case in which a list of Resources was used in the <Request>. That is not the case of your example.
In case of a single <Request> , matching with multiple Policies with <Obligations>, all <Obligations> for Permit are aggregated and returned as on <Obligations>, as that is what you expected.
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
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
("PDP" was typo - should be "PEP").
A native application action or a PEP request to the Context Handler
will normally limit the scopes of XACML Actions/Resources. However,
this is entirely an application design. Imagine that a librarian or an
administrator wants to know all about the contents of the system. It is
easy to imagine that the use of full lists is required. However,
typically such a system wide "Roles" will require the system to enable
them to bypass access control or take some short cut so as not to
trigger time-consuming actions.
(Note: the last word in my paragraph to which you are replying should
have been PEP, not PDP, but I don't think that typo has impacted the
discussion). In any event, my proposal was to address the original
questions by Ralf, whereas this reply appears to be trying to make a
case for submitting full lists, which is what I believe the original
question was explicitly trying to avoid.
Indeed that I was caught by the work, so forget about the response to the typo.
No, the argument is not to submit the FULL list avery time. I have said that there are usually many natural reasons full list is not submitted to PDP. That is where some filtering before PEP or PDP comes in. However, this is in addition to any sort of filters we have been discussing about, which may arise from what are defined in Policies.
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
BEFEA578-CC1C-4822-8223-1AC7F394D2BB@gmail.com" type="cite">
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.
You are mistakenly assuming that the Policies may contain RegExs that
can correspond to Resources. This is not the case in many situations. A
Policy and a Resource do not have a 1:1 relationship. A Policy is
called a Policy because it governs many things.
I believe this was addressed in my introductory comments referring to
the hierarchical profile and its use of regexp to correspond to
Resources.
PDP -> PEP, I presume. BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
XACML is an Attribute-based access control architecture.
For the Hierarchical Resources, we can do access control based
on the node location etc. for allowing or disallowing entire branch
etc. But even in this case, we can think about doing the access control
based on Resource Attributes on separate branches.
The user is trying to get a list of resources. It is my contention that
in the hierarchical case the access control statements themselves
determine what this list will be.
Yes, but my point is that I was not sure whether all the Attributes in the hierarchical are expressed as the URL Handle you proposed or not. My argument is, if the URL Handle is only for the hierarchical physical organisation of Resources, we can think of the existence of some other Attributes. (If the URL Handle represents all the Attributes the Resources can have, this is no the case).
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
E.g. Policy: Any Resource that has "Research" Attribute may be
accessed by any staff and research students of the University,
regardless of its location in the Resource hierarchy.
These are conditions beyond the scope of hierarchy, which my original
responses indicated could be handled by a 2 phase approach, w the first
phase paring down the list using the hierarchical regexps. and the 2nd
phase using the resulting list to make individual queries which would
activate the conditions:
http://lists.oasis-open.org/archives/xacml-users/201004/msg00028.html
"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."
2 phase processing by PEP is non-orthodox and undefined in the XACML specs. PEP is not designed to do it in two phases.
The above Policy is rather ubiquitous. Even the hierarchical resources must comply with.
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
BEFEA578-CC1C-4822-8223-1AC7F394D2BB@gmail.com" type="cite">
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.
See above.
You ought to implement Policies to build an access control, but
you ought to control the access by designing Attribute-matrices. You
give Attributes to Resources (and/or Actions) and describe the
Attributes in the Policies.
That is exactly what is being done, except have not drawn up matrices
which are more appropriate when solving complex real world problems
incorporating all the details. The demo done so far is thought to be
simple enough (2 ResourceMatch expressions based on 2 AttributeIds:
resource-id and resource-type) so that such tools are not necessary at
this stage.
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
BEFEA578-CC1C-4822-8223-1AC7F394D2BB@gmail.com" type="cite">
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.
4D2560EC-5EEA-4EA5-B50A-42899BAA2AB9@gmail.com" type="cite">
(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.
BEFEA578-CC1C-4822-8223-1AC7F394D2BB@gmail.com" type="cite">
4D2560EC-5EEA-4EA5-B50A-42899BAA2AB9@gmail.com" type="cite">
(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.
Either the application itself, PEP or Context Handler gets the
necessary lists WITHOUT talking to the PDP first.
How else does one get the list of resources that " the given subject
authorized for"? This information does not exist anywhere else but
in the Policys. My proposal uses the info in the Policys to enable the
PEP to construct the list to return to the user.
Getting a list (not a full list) is not a problem, that is what I was talking about. Getting a list of XACML Policy Permitted Resource list is a problem. For that, indeed you would need to talk to the PDP, but such is not defined in XACML, i.e. to ask such a question as "What the given subject authorised for?"
Your solution is to talk to PDP and get the answer in the <Obligations> (although you have not asked the right question)
A proper solution may be to make another type of <Request> that asks the question. Such will require an addition to the spec. or a custom interface to get to the XACML rule engine on the side. A modified PEP asks this question but not via the regular XACML <Request> or the interface, but in a proprietary way (unless it is added to the XACML spec).
The latter may be the proper way, but have been objected as "lots" of work. Of course, unless such is standardised, it is not too good for several reasons.
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
PDP is not the entity that knows about the Resources or Actions
in terms of formulating <Query> that has multiple elements in any
member of the Target. Figure 1 indicates that PDP can use only Policies
and request Attributes from PIP via Context Handler.
In my proposal the PDP only uses the Policys and the request Attributes.
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
This is how you should design the application, PEP or Context
Handler, if you are architecting the system. PDP and PIP do only the
rest of the job.
I do not understand this statement. It is the resource-type that
determines the syntax for accessing its members. The proposal uses this
syntax in the ResourceMatch elements to determine access to specific
member, and in response to query it returns the exact same syntax for
the PEP to use to identify the list of members subject to the rule.
BC134045-BC25-49E8-ACF8-0D513C74DB69@gmail.com" type="cite">
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.
BEFEA578-CC1C-4822-8223-1AC7F394D2BB@gmail.com" type="cite">
4D2560EC-5EEA-4EA5-B50A-42899BAA2AB9@gmail.com" type="cite">
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
|