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:
4A842DEC.70507@sbcglobal.net" type="cite">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
|