Hi Craig,
In the context of OpenAz (the project) and AzApi (the interface), PDP
access is implemented by the AzApi provider. The email I sent the other
day has pointers to the relevant material:
http://lists.oasis-open.org/archives/xacml/200912/msg00023.html
One of the intents of the OpenAz project is to make implementations
available that provide access to PDPs. AzApi, itself is a client-facing
API, where the client can be applications, PEPs, containers, etc. Part
of the recent effort is to provide a framework for making PEPs easy to
implement sitting on top of AzApi.
Let me know if this helps. Also, I am available to answer any questions
about either AzApi or the OpenAz project.
Thanks,
Rich
Craig Forster wrote:
OF3E34EF37.1D58D982-ON4A257684.0083ABD6-4A257685.000001EB@au1.ibm.com"
type="cite">
Hi Hal,
I was actually trying to suggest a request / response protocol that doesn't
piggy back on other standards like SAML or WS-Trust. The main one I would
like to suggest is a simple SOAP-based web service where the message
content is the XACML <Request> and <Response> elements.
Regards,
Craig
---
craig forster | staff software engineer | ibm australia development labs
From: Harold Lockhart <hal.lockhart@oracle.com>
To: Craig Forster/Australia/IBM@IBMAU, prateek.mishra@oracle.com
Cc: Anil Saldhana <Anil.Saldhana@redhat.com>, Nataraj Nagaratnam/Raleigh/IBM@IBMUS, xacml@lists.oasis-open.org
Date: 04/12/2009 01:00 AM
Subject: RE: [xacml] XACML AzApi as part of F2F agenda
Actuaally if you look at the SAML Profile for 3.0 there is a WS-Trust
inteface which supports the same type of decision request. The SAML
Assertion Wrapper is still used, but the SAML req/resp protocol is not.
This is completely consistent with the work of WSS, WS-SX, WS-Fed, etc.
Hal
-----Original Message-----
From: Craig Forster [mailto:cforster@au1.ibm.com]
Sent: Wednesday, December 02, 2009 6:14 PM
To: Prateek Mishra
Cc: Anil Saldhana; Nataraj Nagaratnam; xacml@lists.oasis-open.org
Subject: Re: [xacml] XACML AzApi as part of F2F agenda
Hi Prateek,
The use of a XACML-centric API to provide attribute-based access control
was central to two different interop demonstrations given at RSA2008
and Burton Catalyst 2007.
The public interface to the vendors' PDPs in these interops were web
service endpoints on the SAML profile of XACML, not any "XACML-centric API"
as we're discussing in this thread.
I believe the XACML TC should at least standardize on a non-SAML web
service interface before discussing any new API -- be it Java-based,
platform-agnostic or otherwise.
Regards,
Craig
---
craig forster | staff software engineer | ibm australia development labs
From: Prateek Mishra <prateek.mishra@oracle.com>
To: Nataraj Nagaratnam/Raleigh/IBM@IBMUS
Cc: Anil Saldhana <Anil.Saldhana@redhat.com>,
xacml@lists.oasis-open.org
Date: 03/12/2009 12:03 AM
Subject: Re: [xacml] XACML AzApi as part of F2F agenda
Hi Raj,
I disagree with you that the JSR-115 models are adequate to express the
power of ABAC (attribute-based access control) as manifested in XACML.
Further, it is not possible to model obligations within JSR-115,
especially when we would like to expose these to applications.
Finally, we would like to encourage multi-language AzApi implementations
based on the XACML request-response model, so that SPRING, J2EE, POJO,
.NET, C and PHP applications could all benefit from the XACML Az model.
This is not possible with an approach that is based on JSR-115.
The use of a XACML-centric API to provide attribute-based access control
was central to two different interop demonstrations given at RSA2008
and Burton Catalyst 2007. This was followed up by two different
workshops on policy-based access control hosted by Burton/Concordia in
2008 and 2009
where this issue was discussed further and several different use-cases
analyzed. I believe IBM participated in most of these events. So there
is a lot of context and background behind this API, including
substantial input from customers and vendors.
I understand that one can give an "existence proof" that involves 10-15
complex steps and show somehow that the powerful XACML access models can
be encoded using permissions and JSR-115. I dont think this approach
furthers the broad adoption of policy-based access control - instead it
creates a barrier
and generates a lot of confusion for our customers.
I do agree that we need to align this API with JSR-115 and provide our
customers clear advice on their relationship and appropriate context of
use.
- prateek
hi Anil
Yes, I fully understand your perspective. Like you said, standardized
api is important and i fully support that. Key is to make sure
developers and all our customers don't have to choose between multiple
standards in Java APIs but use one that is consistent across vendor
community.
To your point of lack of APIs - I think one area is (potential) lack
of full understanding and appreciation of the potential of JACC. I
know that there is a perception that it is only for J2EE containers.
While it is targeted for that, in that JSR wg, we took efforts to
address even callouts from any Java applications and alignment with
J2Se security model as well. We have seen use cases where it is used
in non-container environments.
What might have to be done is to identify requirements so as to factor
that back into JACC instead of inventing another API. Like Ron
responded in another note, doing this analysis is important so that we
work towards addressing collective objective around standardized apis.
Regards,
Nataraj (raj) Nagaratnam
Inactive hide details for Anil Saldhana ---01/12/2009
11:58:36---Nataraj, While I agree to most of what you said, what the
TC cAnil Saldhana ---01/12/2009 11:58:36---Nataraj, While I agree to
most of what you said, what the TC can deliver on is a
From:
Anil Saldhana <Anil.Saldhana@redhat.com>
To:
xacml@lists.oasis-open.org
Date:
01/12/2009 11:58
Subject:
Re: [xacml] XACML AzApi as part of F2F agenda
------------------------------------------------------------------------
Nataraj,
While I agree to most of what you said, what the TC can deliver on is a
language independent API similar to what DOM1 did. Java can be one of
the bindings. I was of the feeling that AzApi is along those lines.
Lack of standardized API has been the bane of many of the xacml
implementors.
Regards,
Anil
On 11/30/2009 10:28 PM, Nataraj Nagaratnam wrote:
Wrt #3 below around Java interfaces --
I am not sure if XACML TC is the right forum to define Java APIs,
especially when there are Java standard APIs already available and
in use.
JSR 115/JACC is sufficient in many cases - though it is written from
container viewpoint, it is equally applicable to any type of
enforcement
points (even if it is apps). If there gaps that should be addressed in
JACC, I think we should work that in. Those APIs are applicable to
Java
developers who can use it without any knowledge of XACML, or other
means
that a container may even provide. So it provides that level of
abstraction
as well.
Regards,
Nataraj Nagaratnam
From: Prateek Mishra<prateek.mishra@oracle.com>
To: XACML TC<xacml@lists.oasis-open.org>
Date: 30/11/2009 22:38
Subject: [xacml] XACML AzApi as part of F2F agenda
I would like to request discussion of the XACML AzApi during the F2F,
as
we continue to work to advance this towards standard status.
The API submission we made this past summer, has a number of features
would benefit from the TCs review -
1) Use of generics and a highly factored design to allow for new
categories and types of attributes. Is this adequate
to model the new materials in XACML 3.0 and other XACML use-cases?
2) A concept called "what is allowed" - which supports a limited but
extremely valuable form of scoped query against
access rules. One question is how this can be modeled or implemented in
the XACML 2.0/3.0 context
3) Based on experience with the open source and our internal review of
the API, we are planning to submit some additional
interfaces to the XACML TC within the next couple of weeks. The main
purpose of these interfaces is to allow Java developers with little
knowledge of XACML
to utilize the API. We would like to be able to describe these
interfaces in some detail to the TC, together with
the rationale for their introduction.
I would request the Chairs to allocate an hour and half for these
discussions, which would be led by Rich Levinson (he is out today - but
I thought
it important to get this message out to the chairs and TC).
Thanks,
- prateek
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|