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] AzApi Question


I am not sure I follow the discussion here - but we are proposing a 
standard AzApi that we hope would be widely implemented whereas OpenSSO 
is a specific (open source) product. So I dont understand the context of 
the discussion here...

- prateek

> Hi Duane,
>
> Thanks for the question. Consider this a preliminary answer to make 
> sure we are "on the same page". I have only briefly looked at OpenSSO, 
> however, what I have seen appears to be compatible with what we are 
> proposing.
>
>     In particular, which I explained at last tc mgt in first
>     abbreviated presentation and mentioned today on slide 4, bullet1,
>     sub-bullet 1, was that application to AzApi interface on slide 6,
>     checkPermission, for example, would have the Permission
>     represented by a String identifying the "resource type", which may
>     or may not be implicit in the resource name.
>
>     The basic idea is that we do not want application AzApi to be any
>     more complicated than existing APIs currently in use, i.e. an
>     application AzApi should only carry the information necessary to
>     be passed between the appl and az provider, nothing else. The idea
>     is that each container type will have its own notion of what an
>     application is expected to be able to do, and a convention for
>     accessing container-provided/supported services. As such an AzApi
>     implementation would tailor the "upper level" AzApi to be
>     consistent with how the container provider wants its applications
>     to interact, if at all, with the authorization service.
>
>     For example: existing checkPermission is how Java "container"
>     enables appl to access its az service. If one wanted to also have
>     appls access az service that was a xacml pdp for certain resource
>     types, the implementor of AzApi could provide one upper level
>     interface that had, for example, 3 params: resource-type,
>     resource-name, action, where for the xacml pdp supported types,
>     the appl AzApi impl would submit the request using the lower level
>     api, and for the existing permission-type requests the resource
>     type would be converted to a Permission object and submitted to
>     existing checkPermission capabilities. An alternative strategy
>     would be leave checkPermission as is, and pick up the XACML-PDP
>     supported permission from the Policy.implies SPI and submit, as
>     above using the lower level AzApi.
>
> That being said, wrt OpenSSO, possibly an initial project for AzApi 
> would be to adapt into this environment, which, at a glance, might 
> provide some additional reqts that have not been addressed yet, such 
> as encrypting attrs, etc. The objective is to work with all existing 
> environments where there is interest and resources available to create 
> such implementations.
>
> Again, I have only glanced at OpenSSO, so there may be things the 
> discussion above does not directly address, but I would be happy to 
> explore it in more depth if you can provide some explicit pointers to 
> references that characterize the specific use cases and classes 
> involved (i.e. I did not readily find the XACMLRequestProcessor you 
> mentioned).
>
>     Thanks,
>     Rich
>
>
> Duane DeCouteau wrote:
>> Rich,
>>
>> Could you provide a written comparison between the proposed API and 
>> Sun's XacmlRequestProcessor and use of OpenSSO.  Both have been 
>> implemented in the NHIN 2.1 release and were key to RSA2008 and XSPA 
>> demonstrations.
>>
>> Regards,
>>
>> Duane
>>
>>
>> ---------------------------------------------------------------------
>> 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]