[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]