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] Open issue 66

I should add that pausing the PDP makes it stateful, which is a bad
thing. So perhaps Rich's proposal to submit a whole new XACML request
after the missing attribute is better.


Erik Rissanen wrote:
> Hi Rich,
> Thanks, I think I am starting to understand what you want here. And I
> agree with you on much of what "fine grained" authorization is about.
> However, what you want to do is not done well with the Request/Response
> schema. What you are talking really is the context handler. The context
> handler and the PIP are abstractions, and there is nothing in the
> standard or architecture which prevents the application metadata
> repository to act as a PIP.
> So what you really are looking for is a standard callback mechanism with
> which the context handler can request additional attributes.
> I would propose that if we pursue that work, then we define or find
> existing schema for two things:
> 1. Attribute request/response. I think SAML already defines these.
> 2. Add the attribute request/response in the XACML SAML profile
> authzquery protocol units.
> So, what about this sequence?:
> 1. The PEP generates a request with the "most used" attributes.
> 2. The PEP wraps the XACML request in a XACML SAML profile authz query.
> 3. The PDP receives the request and starts processing the policies on it.
> 4. The PDP reaches a part of the policy where it encounters an attribute
> which is not present in the request.
> 5. The context handler discovers this and generates an attribute request.
> 6. The PDP pauses evaluation and returns a XACML SAML profile response
> which asks for more attributes (this is not defined in the current
> specification).
> 7. The PEP gets the attribute from the metadata repository (or where ever)
> 8. The PEP sends an attribute query resopnse to the PDP
> 9. The PDP resumes.
> There are problems with this. Most attributes which are "missing" are
> genuinely missing, so there would be a lot of interupting and
> restarting, and this would not be useful unless there is a configuration
> somewhere in the context handler on which attributes are meaningful to
> ask for.
> Also, I am not sure if it is right to make the attribute
> request/response on the same path as the XACML request/response, but
> there is one benefit of doing so, namely that we don't need to define
> how to reference attribute callback endpoints.
> I need to go now, but I will think more about this.
> Regards,
> Erik
> Rich.Levinson wrote:
>> Hi Erik,
>> Answers inline:
>> Erik Rissanen wrote:
>>> Hi Rich,
>>> Yes, to respond to this specific "part 1" only, it is true that in
>>> this particular example it works very well. The policy is simple
>>> enough that there is a single attribute which can be returned by the
>>> PDP. If the PEP would provide the missing attribute, then the
>>> response would be a Permit.
>>> (BTW, if you prefer to discuss resource attributes, that is good with
>>> me. I agree that they are perhaps more interesting since they might
>>> be more difficult to handle in practice.)
>>> If I continue beyond "Part 1" into the discussion which you follow up
>>> with.
>>> 1. For the sake of argument, let's assume that the PDP can return one
>>> or more attributes as "missing".
>>> 2. Then let's assume that, as you say, the policy author puts an
>>> attribute in the policy, and the PEP has not provided the attribute
>>> to the PDP. Let's say that the attribute has id
>>> "http://www.tts-esss.com/pieka/UUUU/3";.
>>> 3. The PEP will get a response saying that attribute
>>> http://www.tts-esss.com/pieka/UUUU/3 is missing.
>>> So your question is what should the PEP do? (If I understand you
>>> correctly)
>> That's not really my question. As was already discussed above and in
>> my prev email, it appears we agree that 7.15.3 says what a PEP can do:
>>    either ignore it and just reject the request,
>>    or if it can get the attr, get it, and resubmit the request.
>> PEP does not "have to do" either of these in particular, but
>> also "can do" either it chooses. Possibly there is some 3rd
>> or other choice, but I don't think we need to go there.
>>> It is quite clear to me that if the PEP does not know about this
>>> attribute in some form, either directly by itself, or it can look it
>>> up in some kind of discovery service, then there is nothing it can
>>> do. One cannot expect systems integration to happen by itself. One
>>> cannot expect that a policy author can fill in any attribute in a
>>> policy and then it would work all by itself.
>> Right, if PEP does not know what to do, then it should just
>> reject the request.
>>> So my question then is, what do you think should happen in this
>>> stage? Are you looking for a form of general purpose attribute
>>> discovery service? That might be an interesting thing to work on.
>> Yes, I am looking for at least "a form of" somewhat general purpose
>> attribute
>> gathering or collecting, but not "discovery" in the sense of blindly
>> going and trying
>> to find things somewhere.
>> The "form" which I mentioned in the last sentence of the original issue
>>    "mechanisms such as vocabularies should be recommended usage here
>>     with the PEP being responsible for mapping the vocabulary item to the
>>     particular resource physical access path such as the xpath."
>> was a suggestion for xml type resources, such as the xml patient record
>> shown in the core spec.
>> Let me preface this by saying that this whole "fine grain
>> authorization" appears
>> to me to be a general attempt to abstract security logic out of
>> applications
>> and into common policy stores and engines. I mean that is the sort of
>> thing
>> I "hear" a lot and I assume that is a significant part of what this
>> whole effort
>> is all about.
>> That being said, the actual act of extracting authorization logic out
>> of appls
>> means that some of the tests that they currently do on internal
>> variables to
>> come to decisions needs to be removed from the code and made available
>> to be placed in policies that do similar types of tests to come to
>> decisions,
>> but these tests are conducted under the control of the IT Security
>> organization
>> in some central location with an admin console, etc.
>> So, and I think this is obvious, but maybe, in general people aren't
>> thinking
>> about it enough for it to be obvious, the logic that appl executed and
>> the
>> attribute values it used in that eval now must be in the policy
>> engine. It is
>> easy to see how the logic can be put there with all the xacml constructs
>> we have available, but the question remains how do the attribute "values"
>> get into the policy evaluation.
>> Again, the answer to this appears fairly obvious to me. In the process of
>> removing the authorization code from the appl, the devs will notice which
>> values from the internal resource representation are used by that logic.
>> Therefore, they must know that when the logic is put somewhere else,
>> it will need these values to do the evaluation. Therefore, one fairly
>> simple
>> solution is that the dev identify those object properties, if you
>> will, in a
>> global sense that can be extracted to a meta-data file, a fairly common
>> type thing done these days. Maybe it is done w annotations.
>> Now when the dev replaces the az logic with a simple call for az,
>> this is where the details need to emerge. (I think the OASIS SCA-*
>> activities involve quite a bit of abstraction of previously internal
>> application-based logic into general container framework services
>> and suspect that this activity I am describing fits fairly naturally
>> in that sense, except in this case the container service we are
>> looking at would be the pep-pdp service path.)
>> First, I would expect that security admins responsible for creating
>> policies
>> and such would have the list of attrs that are available for such use
>> from
>> the metadata and doc provided by the appl vendors in the case of
>> appls that are sold for use by many customers. The vendors should
>> have a good sense of what attrs might be needed for policies. For
>> example in the health record case in the core spec, at least all the
>> attrs currently used in the policies and maybe more depending on
>> on the nature of the records.
>> Generally, it would not make sense to send all the possible attrs on
>> every call, so, when a call is made and a policy evaluated, the list
>> of missing attrs can be returned, and then the appl az api would
>> somehow or other get the attrs from the object that it has locally
>> in context. The example I gave was an xml doc, where to get
>> the attrs the api might need xpaths and an attr-id. Then the appl
>> devs could change the formats of the xml docs on their next
>> release and their metadata would have new xpaths but the
>> variable id would remain the same.
>>> Maybe I don't understand the use case really. But as far as I see it
>>> right now, it's not going to work because:
>>> 1. In general it is not possible to tell which attribute is missing.
>>> 2. Even if it is possible to tell which attribute is missing, one
>>> cannot expect a PEP find the missing attribute by itself if it
>>> doesn't already know about it.
>>> There just is no way around the fact that if an attribute appears in
>>> a policy, then either the PEP or the context handler has to be aware
>>> of the attribute in some form, or it won't work. The expected
>>> requests from the PEP and the context handler configuration form a
>>> contract which defines the vocabulary available to policy authors.
>> Previous text should answer these points.
>>> But maybe you are talking about lazy fetching of attributes? I do
>>> think that there is much value in lazy fetching of attributes. Let's
>>> say that the http://www.tts-esss.com/pieka/UUUU/3 attribute is
>>> available in some external source and the PEP or context handler is
>>> aware of it, but the attribute is not needed every time and it is
>>> expensive to retrieve. In this case it may be desirable to set up the
>>> system so that the attribute is retrieved only when it is needed by
>>> the policies.
>> No, again, see above.
>> The point about the context handler, though, is that in the core spec the
>> context handler is kind of a pdp-local entity which access attrs from a
>> pip. What I am describing above is getting attrs from an instantiated
>> business object in an application context. While such data could be
>> created and made available in an auxiliary pip, this seems like in
>> general
>> an unnecessary exercise when the info is already right there in the appl
>> from which the original request was made.
>>> This use case is supported by the context handler abstraction. The
>>> context handler is something which can be used by the PDP to retrieve
>>> attributes when they are needed on a particular evaluation path, so
>>> that early fetching is avoided. But "missing attributes" to the PEP
>>> is not going to work.
>>> Anyway, I have a feeling that I don't understand what you are looking
>>> for, so I welcome more discussion. :-)
>> Ok, I provided "more discussion" above. I am interested in your reaction
>> and what, if any, alternative approaches might be better. My sense is
>> that
>> the approach I described is fairly "obvious" and I think if we look at
>> activities in the WS-SecurityPolicy arena there is all kinds of
>> information
>> being solicited for use in authentication and authorization. WS-Fed is
>> incorporating provisions for "claims", which afaict are simply attrs w
>> the
>> rubber stamp of an STS on them, or at least on the wire not a lot more
>> complicated than that.
>>    Thanks,
>>    Rich
>>> Best regards,
>>> Erik
>>> Rich.Levinson wrote:
>>>> Hi Erik,
>>>> I don't think your comments are addressing the specifics that were
>>>> raised in the issue, which I am copying below for quick reference.
>>>> To summarize the issue:
>>>>  Part 1. is basically saying that we need some context about the
>>>> example
>>>>     in order to look at the details in a consistent manner.
>>>> Basically, my reading
>>>>     of the example is that when rule 1 is evaluated, the Target
>>>> determines that
>>>>     the Rule is applicable, and presumably the Rule is evaluated and
>>>> it should
>>>>     produce an Indeterminate result because there is no Subject
>>>> "patient-number"
>>>>     as required on line 1134 when the Condition is evaluated.
>>>>     Based on this Rule I expect that the Indeterminate result causes
>>>> us to
>>>>     look at the prescribed processing in section 7.15.3, which says
>>>> that
>>>>     a missing-attribute status code could/should be returned.
>>>>     To me, this provides an excellent example of how a PEP is informed
>>>>     of what attribute needs to be supplied.
>>>> Before I go further into the details, I'd like to get your response
>>>> to that.
>>>> Also, I'd like to note that while I realize that this issue has been
>>>> floating
>>>> there for a long time, one reason is that no one has really wanted to
>>>> discuss it in detail. Prior responses were more of the nature of there
>>>> will be some other mechanism for getting the attribute. In general,
>>>> when
>>>> we are considering attributes that need to come from users or from
>>>> resource attributes, I believe there is a non-trivial issue about how
>>>> those attributes get brought into the picture. The first problem is
>>>> knowing that they are needed. The fact that they are needed is
>>>> driven by the existence of an applicable policy that needs it, which
>>>> clearly is a state that can come and go as an administrator adds or
>>>> removes a particular attribute from the policy.
>>>> So, the basic use case here is: an admin creates or changes a policy
>>>> and decides to add an attr as part of the policy eval. Given this
>>>> change, how does this attr become part of the request.
>>>>  (Note: I'd actually prefer to focus on resource attrs rather than
>>>>     subject attrs, but since this particular situation w Rule 1
>>>>     appeared obvious to me as a typical example, it happened
>>>>     that the missing attr was subject-based (there is also an
>>>>     assoc resource attr, but the req mysteriously already had
>>>>     supplied that one)
>>>> My reading of the spec is that 7.15.3 provides a general purpose
>>>> mechanism for accomplishing this by returning an identifier specifying
>>>> what attr is needed, based on which the PEP and appl can do
>>>> whatever they want to get the attr then resubmit the request with
>>>> the attribute included.
>>>> This seems to me to be pretty essential functionality. Let me know
>>>> if you think I am missing some important point here. I will be happy
>>>> to help "fix" the spec w the detail I think is needed, but before we
>>>> get to that point there needs to be some agreement that changes
>>>> are even appropriate.
>>>>     Thanks,
>>>>     Rich
>>>>       66. Missing attributes may be underspecified
>>>> I did a somewhat detailed analysis of "Example two" in the core spec
>>>> from the point of view of understanding how fine grained
>>>> authorization (fga) (applying resource attrs to az decision) was
>>>> implemented and came across a number of items that I think need to
>>>> be addressed especially in potential interoperability situations. I
>>>> will put all in one issue initially, we can decide if it needs to be
>>>> broken out later.
>>>> 1. line 1090-91 describing ResourceContent </xacml/ResourceContent>.
>>>> In both the core spec and the sample messages, the ResourceContent
>>>> </xacml/ResourceContent> contains the following:
>>>>    *
>>>>       <ResourceContent </xacml/ResourceContent>>
>>>>          o
>>>>             <md:record xmlns:md="urn:med:example:schemas:record"
>>>>                 + xsi:schemaLocation="urn:med:example:schemas:record
>>>>                   http:www.med.example.com/schemas/record.xsd">
>>>>                   <http:www.med.example.com/schemas/record.xsd%22%3E>
>>>>                +
>>>>                   <md:patient>
>>>>                      #
>>>>                         <md:patientDoB>1992-03-21</md:patientDoB>
>>>>                         <md:patient-number>555555</md:patient-number>
>>>>                   </md:patient>
>>>>             </md:record>
>>>>       </ResourceContent </xacml/IssuesList/ResourceContent>>
>>>>       <Attribute AttributeId
>>>> </xacml/AttributeId>="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
>>>>       DataType </xacml/DataType>="xs:string">
>>>>          o
>>>>             <AttributeValue </xacml/AttributeValue>>
>>>>                 + //med.example.com/records/bart-simpson.xml#
>>>>                   xmlns(md=http:www.med.example.com/schemas/record.xsd)
>>>>                   xpointer(/md:record/md:patient/md:patientDoB)
>>>>             </AttributeValue </xacml/IssuesList/AttributeValue>>
>>>>       </Attribute>
>>>> While I recognize that the example itself is not intended to be
>>>> perfect, it provides a convenient context for raising the following
>>>> questions/issues, especially wrt fga.
>>>>    1. If this is a first request from a PEP, why is the PEP supplying
>>>>       patient-number on line 1056? This looks like a required attr to
>>>>       evaluate Rule 1 (line 1141), if the requestor is the patient,
>>>>       but this example the requestor is the physician.
>>>>           * The physician-id is supplied in the request (line 1044),
>>>>             but the only rule it appears in is rule 3 (line 1522).
>>>>             This rule only allows "write" access (line 1507), so I
>>>>             expect this request would probably fail as it is currently
>>>>             set up. i.e. we would need to add a "read" action to rule
>>>>             3 or add a physician-id test to rule 1.
>>>>       b. Assuming the above request fails, let's consider what might
>>>>       be done. There was a "read" request issued (line 1072), so that
>>>>       would mean that rule 1 (line 1182), rule 2 (line 1347), or rule
>>>>       4 (line 1668) could be applied.
>>>> Rule 1 requires a Subject attribute patient-number (line 1134) to
>>>> match the patient-number in the requested resource record (line
>>>> 1141). Presumably a <MissingAttributeDetail
>>>> </xacml/MissingAttributeDetail>> could be returned, somehow
>>>> identifying these 2 attributes to the PEP.
>>>> Rule 2 requires a patientDoB resource attr (line 1297), a
>>>> parent-guardian-id subject attr (line 1363), and a parentGuardianId
>>>> resource attr (line 1371). Similarly a <MissingAttributeDetail
>>>> </xacml/MissingAttributeDetail>> could be returned requesting these.
>>>>     * Assuming this to be the case, one question I have is how does the
>>>>       <MissingAttributesDetail </xacml/MissingAttributesDetail>> tell
>>>>       the PEP whether the attributes that are missing should be
>>>>       resubmitted as part of the Subject or as part of the Resource?
>>>>       This info is provided in the Request from the xml structure,
>>>>       however, the <MissingAttributeDetail
>>>>       </xacml/MissingAttributeDetail>> does not have equivalent
>>>>       structure to make such distinctions.
>>>> The above is intended just to give an example of questions that
>>>> occur for this particular example, but it is my opinion that it is
>>>> symptomatic of a general problem of how PEPs are supposed to know
>>>> how to construct the proper RequestContext </xacml/RequestContext>
>>>> necessary, in general, for complex scenarios that require
>>>> substantive fga attrs.
>>>> In these more complex fga scenarios it is likely that
>>>> <MissingAttributeDetail </xacml/MissingAttributeDetail>> will be
>>>> typically needed to collect all the required attributes. Therefore,
>>>> I believe some more robust mechanisms, possibly using
>>>> MissingAttributeDetail </xacml/MissingAttributeDetail> as a good
>>>> starting point will be needed to adequately define operation in this
>>>> area.
>>>> In this context as well, it is likely that xpaths are probably not
>>>> the way to go since they are only applicable to certain types of
>>>> resources (xml-based) and those resource structures are likely to
>>>> change in time, and these changes should not percolate into the
>>>> enterprise Policy arena. Therefore, mechanisms such as vocabularies
>>>> should be recommended usage here with the PEP being responsible for
>>>> mapping the vocabulary item to the particular resource physical
>>>> access path such as the xpath.
>>>> Status: *OPEN*
>>>> CHAMPION: *Rich*
>>>> Erik Rissanen wrote:
>>>>> All,
>>>>> I propose that issue 66, "Missing attributes may be
>>>>> underspecified", to be closed without action. The issue has been up
>>>>> there a long time with no proposals for a solution. In addition to
>>>>> that, I believe it is technically impossible to provide a solution.
>>>>> The reason someone gets a not-applicable from the PEP is because
>>>>> "there is no policy which applies". In general there is no way to
>>>>> describe in the form of "missing attributes" what the PEP needs to
>>>>> provide for the policy to apply. Policies can be much too complex
>>>>> for this. In particular, a policy could be NotApplicable because an
>>>>> attribute is present, for example. Or it might require that three
>>>>> particular integer attributes form a pythagorean tripple. How do
>>>>> you express that as "missing attributes"?!
>>>>> And we demonstrated in the RSA interop that obligations can be used
>>>>> to handle simple use cases where some attributes can be expected to
>>>>> be missing. An obligation can be used to mark the part of the
>>>>> policy which required an attribute, and the obligation can then be
>>>>> returned by the PDP if the attribute is missing.
>>>>> Best regards,
>>>>> Erik
>>>>> ---------------------------------------------------------------------
>>>>> 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]