Hi Yoichi and Paul,
My prev email was not intended to address the comments that had been
made on AzApi, however, I will respond to those now inline with the
relevant sections copied to the front of the message here for easier
access. I appreciate the time Yoichi spent reviewing AzApi and
hopefully the responses I provide to Yoichi's points will be helpful.
Note the response below are addressing issues wrt AzApi that Yoichi has
raised, and do not address the query filter techniques that were
covered in prev email.
Thanks,
Rich
On 4/18/2010 2:53 PM EDT, Tyson, Paul H wrote:
<Rich>
The ref Paul gave above was to the original announcement of the plan
for the AzApi project in July 2009. The actual project was started in
Sep 2009, and a report was given on it at the Dec 2009 XACML F2F:
</Rich>
On 4/19/2010 12:09 AM EDT, Yoichi Takayama wrote:
This is an implementation of how one may communicate with PDP.
How one may construct a Query, send it to a PDP and how to access the
Response is totally an implementation matter with the current XACML
standard alone.
<Rich>
It is agreed, AzApi is a proposed Java interface to enable PEP
providers to have a common reference interface to use to communicate to
PDP. In addition, OpenAz site is intended to provide a reference
implementation(s) of that interface that providers can download and use
to communicate to XACML PDPs (or any PDP that supports a XACML
interface).
</Rich>
If there is a need for having interoperability between different
PDP suppliers and software vendors (their products contain PEP), having
API standard(s) would be a must.
<Rich>
In the large enterprise it is common for several authorization
solutions to co-exist. AzApi provides a mechanism for providing
seamless integration of PEP to any PDP front-ended by AzApi. It is
expect that due to the generality and flexibility of XACML, and the
XACML req/rsp interface that the constructs there are a superset of
what is needed to interface to most existing PDPs.
</Rich>
However, the Oracle contribution proposes an API that has these
lines.
-
-
// Add resource-action pairs to the
request context
-
AzResourceActionAssociation assoc =
-
azReqCtx.createAndAddResourceActionAssociation(azResource,
azAction);
-
-
// its time to decide !
-
AzResponseContext azRspCtx =
azHandle.decide(azReqCtx);
-
AzResult azRes =
azRspCtx.getResult(assoc);
a. It exposes and contains too much proprietary details as to
how the PEP is formulating the Query. How the PEP may be formulating
the Query should be encapsulated into another module, which produces
XACML Request as an XML or an XML-representative object. How this is
done is totally application dependent and it should not be any part of
the proposal for a standard API.
<Rich>
It is agreed that the lower level AzApi is much too detailed for
typical application environments. To address that concern, in the Dec
2009 XACML F2F presentation, we demonstrated the so-called "PepApi"
(azapi.pep), which is intended to provide a general simple interface
for queries and access decisions.
The following is the code used to generate the initial request and
process the response that was provided in previous email:
- HashMap<String,String>
subject = new HashMap<String,String>();
subject.put(AzXacmlStrings.X_ATTR_SUBJECT_ID,"User1");
TestResourcePermission testResourcePermission =
new TestResourcePermission(
"http://www.example.com/A/B/C", "Read");
Date now = new Date();
PepRequest pepReq = pepReqFactory.newPepRequest(
subject, testResourcePermission, now);
PepResponse pepRspCtx = pepReq.decide();
if (pepRspCtx != null) testUtils.logObligations(pepRspCtx);
At a glance, this may not look a lot simpler than the segment you
provided but it does a lot more. In particular:
- The first 4 lines are just setting up the attributes to pass:
subject, resource, action, environment, where the resource action are
combined in a Permission, which is the typical Java application
construct for representing application resources.
- The objects that are passed in this example are not required
object types. In general, any object type can be passed for any
collection of attributes within a category. The way this is enabled is
that the PEP provider supplies "Mappers" for any objects they want
users to be able to supply. The Mapper can map any attribute data
within the object to standard XACML-form attributes and submit via
AzApi.
- The PepResponse contains easy methods for processing results,
which basically consists of a boolean allowed() method and a
getObligations() method which returns the Obligations in a
Map<String, Map<String, String>>, which is a Map of Maps of
String value pairs for the set Obligations.
Finally, on this point, neither azapi, nor azapi.pep is cast in
concrete at this point. Anyone who participates in the OpenAz project
can provide input for suggested changes that could make it easier to
use for use cases for which there appears to be sufficient demand to
warrant the effort.
</Rich>
b. The AzQueryContext should be sent separately from the XACML
Query itself. XACML does not define such an object as AzRequestContext.
The XACML Query Context is the <Query> object itself. In case the
PDP resides on a different server (A) than the PEP server (B), this
should include some kind of information about calling back from server
B to server A. Because the PDP/PIP will probably need to use it as a
part of a call-back for Attributes that only server A can resolve.
<Rich>
The only object used to construct XACML Requests is the
AzRequestContext, which is used to collect the attributes for the
different categories of AzEntity, namely the Subject, Action, Resource,
and Environment, where there are individual categories for each type of
XACML Subject.
Also, the AzRequestContext is not "sent" anywhere. It is up to the
provider to supply whatever serialization is needed. In the example in
the prev email, the "provider" was basically a wrapping of SunXacml by
AzApi. Decisions are made without ever serializing the code, however
the example did use PolicySet.encode to show the PolicySet in XML, and
similarly for the request and response objects.
For the callback, the current plan is to provide a simple callback api
that would do a getAttribute() to a registered callback, where we will
shortly demo that using the SunXacml AttributeFinder interface.
</Rich>
c. Accessing the Response for this Query should not be using
such a thing as the Resource-Action association as a "key" to obtain
the object.
<Rich>
As indicated above, the lower level AzApi is for the PEP provider to be
able to get exact details from the XACML Response, which the PEP
provider can present to its users via the PepResponse, or possibly an
enhanced PepResponse with "reverse mappers" that would move the XACML
Response constructs into any set of objects that the PEP provider wants
to supply for its users. At present we have just provided the fairly
simple Map<String, Map<String,String>> mentioned above, but
if there is the need for other constructs there is no reason why those
cannot be provided as well, for example using "reverse mappers".
</Rich>
d. The AzHandle is a service, not a PDP. So, it should be more
appropriate to "sendQuery()" than "decide()".
<Rich>
AzApi can be either embedded or remote, w the provider supplying what
ever remoting capabilities are appropriate. Right now OpenAz reference
impl only is embedded, but we will be looking at various remoting
capabilities including SAML-XACML, RMI, web service, etc.
</Rich>
e. Since a different implementation of the PEP-PDP may not use a
service paradigm, it is not appropriate to provide an API that is
limited
to use a service.
<Rich>
Not sure if I understand this comment. AzApi is primarily an
"interface" for passing objects that map to XACML constructs. If by
"service" you are referring to "remote", then prev comment should
clarify. Otherwise, I am not sure what this comment is addressing.
</Rich>
f. This hides the actual communication API between this system
and the PDP, and the need to clarify the need for that API or
interface. A PDP may have interface to external world with Web Service
Profile, Java RMI Profile, Java direct method call, etc.
<Rich>
I think we are in agreement on the requirement to provide a variety of
solutions for the communication interfaces between PEP and PDP. This
can be done with the impl strategy. The OpenAz project will be looking
at the Spring framework as a first attempt to provide configuration
capabilities for such aspects as the PEP-PDP communication links
required between different pairings.
However, the primary objective of AzApi is to provide a framework for
unifying the manner in which Policy can be represented in terms of
Attributes, which uses the XACML Attribute metadata as a starting point
for standardization of Attribute representation. The longer term
objective here is to be able to define Policy in XACML terms using
Attributes with URI identifiers, which can be mapped to specific
Application or PIP Attributes. It is hoped that in the longer term that
Application and PIP providers will be inclined to provide their own
Attribute representations in XACML terms, which will greatly enhance
the ability to provide the pathways from the Attribute sources to the
Policy Decision modules.
</Rich>
This is not at all what I expect to see in a standard.
<Rich>
Hopefully, the response above have made clear that AzApi is not
intended to be a standard in and of itself, but a reference interface
and implementation that can be used to bind XACML data to the Java
environment. As such the project is designed to be extensible, such
that no objects being passed are the "only" way bind the interface,
however, some selection of an initial set of objects is desirable to
have available so users of the AzApi and PepApi can get full
functionality with supplied objects. If those objects are insufficient
for the users, then capabilities exist thru the Mappers at the AzApi
level and the AzAttributeValue<U extends Enum<U> &
AzDataTypeId, V>, where the scary looking first parameter ("U
extends Enum<U> & AzDataTypeId") is really just a java expert
recommended technique for defining an extensible Enum, where the whole
construct is really just a wrapper for a XACML URI for a DataType,
which can be extended with new DataTypes on an as-needed basis without
requiring changes to AzApi.
</Rich>
Yoichi
4BCBDC60.6010404@oracle.com" type="cite">
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
Yoichi Takayama wrote:
25B99AD7-355F-4FE4-AA07-57A55426406C@gmail.com"
type="cite">
On 19/04/2010, at 4:53 AM, Tyson, Paul H wrote:
In XACML 3.0, the expected behavior was made truly obligatory:
"PEPs that conform to v3.0 of XACML are required to deny access unless
they understand and can discharge all of the <Obligations>
elements
associated with the applicable policy." (Section 2.12).
I think that it has been always the way, that the system that
accepts XACML control had to oblige the <Obligations> in such a
way as detailed in the standard.
3.0 adds the <Advice> element, which can be used for
communicating
name-value pairs in the XACML response. The policy-writer and the PEP
implementor must agree on what these name-value pairs mean.
Each <Advice> is also a part of a <Decision>, and
it
does not apply to the case in which Oleg/Ralf wants "a list of all
Permissions" for the user.
Query
Subject=this user
Action=Any
Resource=Any
and expect the <Advice> on what are Permitted and what
are
Denied?
It should return Indeterminate really, because there are
combinations of Actions and Resources which are Permissible and Denied.
Then, there is only one Advice with a list of Name/Value
pairs.
That is hardly enough to express multiple triplets (i.e. Decision,
Action and Resource) or to express more complex conditions that would
apply to those triplets. It is not simply a combination of Action and
Resource that will determine the outcome.
My point was that the current multi-quetion Query can achieve
what they want, although Oleg desires if one can ask XACML to give "a
list of all Permissions for the user". That is not possible where the
Permissions are written as Policies and involving dynamic Policies and
dynamic Attributes, without using some kind of lists and multiple
questions (implicit or XACML Queries).
PDP, PIP, PAP, and the Policy Store can
be
off-the-shelf.
However, I still do not see (or expect)
any
XACML library
that can be used without your providing
an
appropriate PEP.
This is because a PEP is normally very
tightly tied with what
your system does, i.e. what Actions and
Resources are dealt
with. Since these can't be generalised in
a
standard, it is
left out as implementation-dependant. I
think that this is
quite acceptable at this time.
XACML users should ask their software vendors to supply built-in PEPs,
or at least to include PEP functions in their customization kits. Since
most large enterprises have many applications that handle their
intellectual property and business processes, it is not acceptable for
each application to handle access control in its own proprietary way.
I am talking about the standard. Not the vendor products. The standard
does not define PEP, except for the query syntax between PEP and PDP
and how the Attributes would be obtained magically by the PIP and
Policies by PAP. The actual programming interface (API) between PEP and
PDP is not defined, since it is programming language- and
implementation dependent (i.e. the syntax of a statement or the name of
a function that sends the XACML Query XML statements to PDP).
What you are saying is in line with my statement. XACML PEP
should be provided by vendors of the system if that system uses XACML
Policies.
This is an implementation of how one may communicate with PDP.
How one may construct a Query, send it to a PDP and how to access the
Response is totally an implementation matter with the current XACML
standard alone.
If there is a need for having interoperability between
different
PDP suppliers and software vendors (their products contain PEP), having
API standard(s) would be a must.
However, the Oracle contribution proposes an API that has
these
lines.
-
-
// Add resource-action pairs to the
request context
-
AzResourceActionAssociation assoc =
-
azReqCtx.createAndAddResourceActionAssociation(azResource,
azAction);
-
-
// its time to decide !
-
AzResponseContext azRspCtx =
azHandle.decide(azReqCtx);
-
AzResult azRes =
azRspCtx.getResult(assoc);
a. It exposes and contains too much proprietary details as to
how the PEP is formulating the Query. How the PEP may be formulating
the Query should be encapsulated into another module, which produces
XACML Request as an XML or an XML-representative object. How this is
done is totally application dependent and it should not be any part of
the proposal for a standard API.
b. The AzQueryContext should be sent separately from the XACML
Query itself. XACML does not define such an object as AzRequestContext.
The XACML Query Context is the <Query> object itself. In case the
PDP resides on a different server (A) than the PEP server (B), this
should include some kind of information about calling back from server
B to server A. Because the PDP/PIP will probably need to use it as a
part of a call-back for Attributes that only server A can resolve.
c. Accessing the Response for this Query should not be using
such a thing as the Resource-Action association as a "key" to obtain
the object.
d. The AzHandle is a service, not a PDP. So, it should be more
appropriate to "sendQuery()" than "decide()".
e. Since a different implementation of the PEP-PDP may not use
a
service paradigm, it is not appropriate to pride an API that is limited
to use a service.
f. This hides the actual communication API between this system
and the PDP, and the need to clarify the need for that API or
interface. A PDP may have interface to external world with Web Service
Profile, Java RMI Profile, Java direct method call, etc.
This is not at all what I expect to see in a standard.
Yoichi
---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-users-help@lists.oasis-open.org