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


Rich,
You have covered it pretty well.
Adding some detail inline.
Thanks.
-Dilli

Rich.Levinson wrote:
> Hi Prateek,
>
> From my perspective the context of my comments in response to Duane's 
> email was to address how AzApi deals with a new instance of an az 
> provider. My brief look at OpenSSO found that it is an open source 
> project specified to be a basis for a web access management product:
> http://wikis.sun.com/display/OpenSSO/OpenSSO+Architecture+Overview
>
> Within that basis there is an authorization service:
> http://wikis.sun.com/display/OpenSSO/OpenSSO+Architecture+Overview#OpenSSOArchitectureOverview-2.030Second%28ElevatorPitch%29Architecture 
>
>
> I found further info on that az service here:
> http://developers.sun.com/identity/reference/techart/id-svcs2.html
This exposes REST/SOAP interface for authorization API of OpenSSO.
>
> At this point things start to get quite detailed. There is a client 
> interface to get policy decisions here:
> http://docs.sun.com/source/820-3739/index.html
>
> in the com.sun.identity.policy.client package. 
This has the class XACMLRequestProcessor.

/**
 * This class provides the public API to process XACML context Request.
 * This class accepts XACML context Request to get authorization decision,
 * posts the request to PDP using SAML2 profile, gets SAML Response back,
 * extacts XACML context Response from the XACMLAuthzDecisionStatement
 * returned in SAML Response and returns the XACML context Response.
 * XACML context Response includes the xacml context Result with
 * the XACML context authorization Decision
*/

I would check and try to fix why the javadoc for this class not publicly 
available.

> Also there is the com.sun.identity.xacml.context package which appears 
> to be the SunXACML client for accessing a PDP.
>
This is not SunXACML. This is distinct implementation that lets a 
developer build XACML schema compliant xacml context elements using JAVA 
API.
> So, I think the idea would be to look at the 
> PolicyEvaluator.isAllowed(ssoToken, resourceName, actionName, 
> envParams) api as an instance of an upper level AzApi which could be 
> used directly or further abstracted to incorporate both this and other 
> contexts, and to look at the com.sun.identity.xacml.context.Request 
> interface as an instance of a PDP access API which could be wrapped 
> within AzApi lower level to access a PDP that supports this interface.
>
> Note: while there is a link on that page to XACMLRequestProcessor that 
> Duane mentioned, it does not resolve and returns an error.
Please see above the comment on XACMLRequestProcessor.

com.sun.identity.policy.client exposes simpler authorization API that 
does not provide or need any xaml exposure.
This could be seen as Sun native API.

com.sun.identity.xacml.client.XACMLRequestProcessor API provides API 
that provides and needs XACML/SAML exposure. This could be seen as XACML 
compliant(very close to XACML/SAML2) API.

If the proposed new API would not expose or require XACML/SAML2 
exposure, I am not sure whether it would expose full flexibility and 
power of XACML. If we try to expose the full power and flexibility of 
XACML/SAML2 in the new API, it would get very close to the schema. I 
need to spend some more time to understand the new proposal.


>    Thanks,
>    Rich
>
>
>
> Prateek Mishra wrote:
>> 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
>
> ---------------------------------------------------------------------
> 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]