[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 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 controlwas 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. - prateekhi 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 andin use.JSR 115/JACC is sufficient in many cases - though it is written from container viewpoint, it is equally applicable to any type ofenforcementpoints (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 toJavadevelopers who can use it without any knowledge of XACML, or othermeansthat a container may even provide. So it provides that level ofabstractionas 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,aswe 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]