Re: [xacml] XACML AzApi as part of F2F agenda

[Nataraj Nagaratnam <natarajn@us.ibm.com>]

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




Anil 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