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] proposal for identifying optional features



The support of profiles, e.g. RBAC and other stuff, requires not only just
mechanisms, but human judicious use of request, policy, configuration, and
administration. More than I think you can do with just mandating matching
identifiers.

Requests are formed with the policy in mind by the very fact that we
don't have one mandated attribute that must exist in a request.

Therefore, the use of all profiles should be known at configuration and
adminstration time of both the request handler, THE USE OF THE REQUEST
HANDER, and the Policy Writers, and the Adminstration of Policies.

This is much more than you can do with matching supported profiles element
in a policy and request.

What you are effectively trying to do is separate the RequestHandler and
its use, away from the Policy and its adminstration. This situation then
begs the question of matching policies?

	Q: A request that is formed with a certain profile. Should the PDP
           a) only retrieve policies with that profile?
           b) reject the request with error?
                 Q: If the request gets rejected, shouldn't it have
                    noticed this before hand?
        Q: What if the sub policies support different profiles? What do
           you do then?

There are many more questions I don't have time to enumerate.

I would agree with Anne's statement just below stating that all of this
should be handled by out-of-band agreement.

Cheers,
-Polar



On Thu, 8 Jul 2004 Anne.Anderson@Sun.COM wrote:

> More mods (I should have said "environment attribute", not "environment
> variable").  But again, I'm not positive this is something we have to
> implement.  There are other things in XACML that depend on the PDP
> implementation, such as attribute finder modules, policy finder modules,
> etc.  I don't think we want to create something new to define all of
> these.  I guess I recommend that all this be handled out-of-band.  I doubt
> that a given Request will depend on profiles anyway, although a Policy or
> PolicySet might.
>
>   Each profile, and each optional feature in a profile, SHALL be associated
>   with a URI.  [and each optional feature in XACML itself?]
>
>   There SHALL be a new, optional "SupportedProfiles" policy element, to
>   consist of a sequence of anyURI.
>
>   If an XACML implementation supports profiles, these SHALL be included
>   in the "SupportedProfiles" policy element.  This element SHALL be
>   optional, but SHALL be included if any profiles are supported.
>
>   If a Request depends on profiles, the Request SHALL include a new
>   "...:supported-profiles" Attribute, whose DataType is the schema
>   complex type defined for the new "SupportedProfiles" policy element.
>   The value of this Attribute SHALL include the URIs of all profiles
>   or profile options that are required to support the given request.
>
>   The documentation for an XACML implementation SHALL include the
>   profiles and profile options it supports.
>
>   If a PDP receives a Policy, PolicySet, or Request that requires profiles
>   or profile options that the PDP does not support, the PDP SHALL treat
>   this condition as an error.  For a request, the response SHALL include an
>   error code of "...".
>
> Anne
>
>
> >
> >Why wouldn't we use just use a URI ?
> >
> >Minor changes on your proposal:
> >
> >All compliant XACML implementations  MUST declare which profiles they
> >support  this can an optional element that can be included in a polic
> >y to
> >list the required URIs.  For a request, we could just define an envir
> >onment
> >variable to hold the list of  required URIs.  The format of the varia
> >ble
> >could be the same as the format of the optional element.  A context h
> >andler
> >could be aware of
> >that variable.  We also need to define error codes or other behavior
> >if a
> >PDP does not support required options.
> >
> >
> >
> >Anthony Nadalin | work 512.838.0085 | cell 512.289.4122
> >
> >
> >
> >
> >             Anne Anderson
> >
> >             <Anne.Anderson@Su
> >
> >             n.COM>
> >   To
> >                                       XACML TC
> >
> >             06/22/2004 09:55          <xacml@lists.oasis-open.org>
> >
> >             AM
> >   cc
> >                                       Anne.Anderson@Sun.COM
> >
> >                                                                   Su
> >bject
> >             Please respond to         [xacml] proposal for identifyi
> >ng
> >               Anne.Anderson           optional features
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >Tony suggested we have some way of identifying which optional
> >features or profiles a given implementation supports, or that a given
> >request or policy requires.
> >
> >We have survived without this through XACML 1.0 and 1.1, but if
> >we decide it is worth doing, here is a proposal.
> >
> >create a urn for each profile or separate optional feature
> >(e.g. obligations, xpath).  Create an optional element that can be
> >included in a policy to list the required urn's.  For a request, I th
> >ink
> >we could just define an environment variable to hold the list of
> >required urn's.  The format of the variable could be the same as the
> >format of the optional element.  A context handler could be aware of
> >that variable.  We also need to define error codes or other behavior
> >if
> >a PDP does not support required options.  We need to decide whether
> >supporting the "optional support" feature is itself optional!
> >
> >Anne
> >--
> >Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> >Sun Microsystems Laboratories
> >1 Network Drive,UBUR02-311     Tel: 781/442-0928
> >Burlington, MA 01803-0902 USA  Fax: 781/442-1692
> >
> >
> >To unsubscribe from this mailing list (and be removed from the roster
> > of
> >the OASIS TC), go to
> >http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_work
> >group.php
> >.
> >
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]