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