OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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


Subject: Re: [xacml-comment] PIP - comments/questions



Hi Benedict,

On 1/02/2018 5:30 AM, Benedict Benken wrote:
Hi,

I've a few comments/questions regarding to XACML. If this is the wrong mailing list, let me know.

This is an appropriate list for your questions.


 1. The most XACML-Implementations, that I saw, integrated the PIP's into the PDP. I think that is no good solution, but the devs had not choice:
    On the one hand the meaning of the context handler isn't really described as importent as I guess it is. On the other hand there is no XML/JSON-specification how to request a PIP. So when PDP and PEP/context handler are on two machines, then the PIP has to be on the the PDP machine and cannot be on a third machine (e.g. as microservice).

The only standardized method for a context handler to obtain attributes from a PIP
is the SAML AttributeQuery in the SAML 2.0 Profile of XACML. However, it seems this
method is not widely implemented or used. Implementations have mostly come up with
proprietary ways to get attributes from attribute stores such as SQL databases and
LDAP directories. These typical attribute stores already have standardized ways to
access them so there hasn't been an impetus to use the SAML profile or define a
JSON counterpart to the SAML AttributeQuery.

Whether the PIPs are integrated into the PDP is a matter of perspective. I think
of the SQL database or LDAP directory as being the PIP and the implementation-
specific connector that allows the context handler to fetch the attributes is
part of the context handler. The connectors are necessarily integrated, but the
attribute stores can be anywhere (subject to any limitations in the implementation
of the connector), and the protocols in use between the context handler and PIPs
are implementation defined.

    Why is there no detailed PIP definition?

In general, the XACML specs avoid being too prescriptive on the architecture to
avoid unnecessarily restricting what implementations can do. AttributeQuery defines
an interface to a PIP, but you are not required to use it.

 2. It's not really clear defined what's the recommended way to retreive missing attributes in XACML. PIP's or Response Status Detail?

There's no recommendation because either way might be the better choice depending
on the circumstances. For example, a context handler might always obtain subject
attributes from a PIP because all the users are fully described in a centralized
directory, but missing resource attributes might be reported back to the PEP
because the PEP is closer to the specific resource database and in a better
position to obtain the missing values.

If you are talking about the interaction between the PDP and context handler, then
it is just more efficient to obtain missing attributes on-the-fly from a PIP as
the PDP processes XACML expressions. The demarcation between the PDP and context
handler is rather arbitrary in this case.

 3. I think it would be usefull, if an AttributeDesignator has an optional "expression" and "expressionType" attribute, so PIP's could use them for SQL-queries or Spring Expression Language etc.

That would require the policy writers to be aware of the nature of the PIP
implementation and would make the policies they write less portable and harder
to maintain. In my experience, it is sufficient to make such expressions part of
the implementation or configuration of the relevant connectors.

 4. Why are VariableDefinitions only for policies and not policySets?

Apparently, variable definitions for policy sets just weren't considered at the
time variables were added to the spec. I for one would find the feature useful.

Regards,
Steven


thank you and best regards
Benedict



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