OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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 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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]